Hi Maíra,
Thanks a lot for taking a look!
On Thu, Apr 20, 2023 at 01:47:59PM -0300, Maíra Canal wrote:
> Hi Marius,
>
> Thanks for the changing the commit message! Just a few nits:
>
> On 4/20/23 05:41, Marius Vlad wrote:
> > This adds support for creating multiple virtual pipes, in case one wo
On 18/04/2023 23:41, Rob Herring wrote:
> On Sat, Apr 15, 2023 at 12:46:11PM +0200, Jernej Skrabec wrote:
>> Even though some DW-HDMI controllers have perfectly usable HDMI-CEC
>> implementation, some boards might prefer not to use it or even use
>> software implementation instead.
>>
>> Add proper
Le jeu. 20 avr. 2023 à 02:20, Dmitry Baryshkov
a écrit :
>
> On 18/04/2023 21:10, Arnaud Vrac wrote:
> > Some Qualcomm SoCs that support HDMI also support CEC, including MSM8996
> > and MSM8998. The hardware block can handle a single CEC logical address
> > and broadcast messages.
> >
> > Port the
On 4/19/2023 7:41 AM, Arnaud Vrac wrote:
Do not override the hsync/vsync polarity passed by the encoder when
setting up intf timings. The same logic was used in both the encoder and
intf code to set the DP and DSI polarities, so those interfaces are not
impacted. However for HDMI, the polariti
On 4/19/2023 3:23 PM, Dmitry Baryshkov wrote:
On 19/04/2023 17:41, Arnaud Vrac wrote:
This avoids using two LMs instead of one when the display width is lower
than the maximum supported value. For example on MSM8996/MSM8998, the
actual maxwidth is 2560, so we would use two LMs for 1280x720 or
Le jeu. 20 avr. 2023 à 00:43, Dmitry Baryshkov
a écrit :
>
> On 19/04/2023 17:41, Arnaud Vrac wrote:
> > The dpu backend already handles applying alpha to the base stage, so we
> > can use it to render the bottom plane in all cases. This allows mixing
> > one additional plane with the hardware mix
On 19/04/2023 02:10, Justin Chen wrote:
> From: Florian Fainelli
>
> Add a binding document for the Broadcom ASP 2.0 Ethernet
> controller.
>
> Signed-off-by: Florian Fainelli
> Signed-off-by: Justin Chen
> ---
> .../devicetree/bindings/net/brcm,asp-v2.0.yaml | 146
>
On 19/04/2023 02:10, Justin Chen wrote:
> From: Justin Chen
>
> The ASP 2.0 Ethernet controller uses a brcm unimac.
>
> Signed-off-by: Justin Chen
> Signed-off-by: Florian Fainelli
> ---
> Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
On 2023-04-21 01:25:57, 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
> ---
> .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 -
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 files)
Regardless, the patch itself is:
R
On 4/20/2023 11:30 PM, Matt Roper wrote:
On Thu, Apr 20, 2023 at 01:38:59PM +0200, Nirmoy Das wrote:
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by Media tile update the whole
cache line even for partial writes. This creates a coherency
problem for c
Hi
Am 21.04.23 um 02:33 schrieb Jammy Huang:
ARM architecture only has 'memory', so all devices are accessed by
MMIO if possible.
Merged into drm-misc-fixes. Thanks for the patch.
Best regards
Thomas
Signed-off-by: Jammy Huang
Reviewed-by: Thomas Zimmermann
---
v2 changes:
- Use MMI
Hi
Am 20.04.23 um 05:05 schrieb Sui Jingfeng:
The fbdev test of IGT may write after EOF, which lead to out-of-bound
access for drm drivers hire fbdev-generic. For example, run fbdev test
on a x86+ast2400 platform, with 1680x1050 resolution, will cause the
linux kernel hang with the following cal
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Yang Li
---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
d
Hi
On 2023/4/21 16:09, Thomas Zimmermann wrote:
Hi
Am 20.04.23 um 05:05 schrieb Sui Jingfeng:
The fbdev test of IGT may write after EOF, which lead to out-of-bound
access for drm drivers hire fbdev-generic. For example, run fbdev test
on a x86+ast2400 platform, with 1680x1050 resolution, will
Convert platform_get_resource(),devm_ioremap_resource() to a single call
to devm_platform_ioremap_resource(), as this is exactly what this function
does.
Signed-off-by: Yang Li
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/driver
Am Donnerstag, dem 20.04.2023 um 16:51 -0500 schrieb Adam Ford:
> On Thu, Apr 20, 2023 at 8:43 AM Lucas Stach wrote:
> >
> > Am Donnerstag, dem 20.04.2023 um 08:24 -0500 schrieb Adam Ford:
> > > On Thu, Apr 20, 2023 at 8:06 AM Lucas Stach
> > > wrote:
> > > >
> > > > Hi Adam,
> > > >
> > > >
On 20/04/2023 00:00, 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 in PTE has far more levels than what's defined in the
enum. I
Convert platform_get_resource(),devm_ioremap_resource() to a single
call to devm_platform_ioremap_resource(), as this is exactly what this
function does.
Signed-off-by: Yang Li
---
drivers/gpu/drm/tegra/dpaux.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/dr
Convert platform_get_resource(),devm_ioremap_resource() to a single
call to devm_platform_ioremap_resource(), as this is exactly what this
function does.
Signed-off-by: Yang Li
---
drivers/gpu/drm/tiny/arcpgu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/dr
Convert platform_get_resource(),devm_ioremap_resource() to a single
call to devm_platform_ioremap_resource(), as this is exactly what this
function does.
Signed-off-by: Yang Li
---
drivers/gpu/drm/tve200/tve200_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/
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 09:27:49AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 17/04/2023 21:12, Rob Cl
On 20/04/2023 00:00, 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 in PTE has far more levels than what's defined in the
enum.
On Wed, 12 Apr 2023 at 23:43, Rob Clark wrote:
> +/**
> + * enum drm_gem_object_status - bitmask of object state for fdinfo reporting
> + * @DRM_GEM_OBJECT_RESIDENT: object is resident in memory (ie. not unpinned)
> + * @DRM_GEM_OBJECT_PURGEABLE: object marked as purgeable by userspace
> + *
> +
On Tue, 4 Apr 2023 03:27:30 +0200
Danilo Krummrich wrote:
> +/**
> + * drm_gpuva_prealloc_create - creates a preallocated node to store a
> + * &drm_gpuva entry.
> + *
> + * Returns: the &drm_gpuva_prealloc object on success, NULL on failure
> + */
> +struct drm_gpuva_prealloc *
> +drm_gpuva_pre
On 21/04/2023 11:26, Emil Velikov wrote:
On Wed, 12 Apr 2023 at 23:43, Rob Clark wrote:
+/**
+ * enum drm_gem_object_status - bitmask of object state for fdinfo reporting
+ * @DRM_GEM_OBJECT_RESIDENT: object is resident in memory (ie. not unpinned)
+ * @DRM_GEM_OBJECT_PURGEABLE: object marke
On 15.04.2023 12:41, Adam Ford wrote:
> Fetch the clock rate of "sclk_mipi" (or "pll_clk") instead of
> having an entry in the device tree for samsung,pll-clock-frequency.
>
> Signed-off-by: Adam Ford
This one breaks DSI panel operation on my Exynos-based Trats, Trats2 and
TM2e boards. I've didn
On 21.04.2023 10:40, Lucas Stach wrote:
> Am Donnerstag, dem 20.04.2023 um 16:51 -0500 schrieb Adam Ford:
>> On Thu, Apr 20, 2023 at 8:43 AM Lucas Stach wrote:
>>> Am Donnerstag, dem 20.04.2023 um 08:24 -0500 schrieb Adam Ford:
On Thu, Apr 20, 2023 at 8:06 AM Lucas Stach wrote:
> Hi Adam
On 20.04.23 17:57, Pierre Asselin wrote:
> Some legacy BIOSes report no reserved bits in their 32-bit rgb mode,
> breaking the calculation of bits_per_pixel in commit f35cd3fa7729
> ("firmware/sysfb: Fix EFI/VESA format selection"). However they report
> lfb_depth correctly for those modes. Keep
Gently ping for network developers, could you look at ref_tracker patches,
as the ref_tracker library was developed for network.
This is revived patchset improving ref_tracker library and converting
i915 internal tracker to ref_tracker.
The old thread ended without consensus about small kernel all
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.
As a bonus we can reuse this helper in ref_tracker_dir_exit.
Signed-o
Similar to stack_(depot|trace)_snprint the patch
adds helper to printing stats to memory buffer.
It will be helpful in case of debugfs.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
include/linux/ref_tracker.h | 8 +++
lib/ref_tracker.c | 56 +++
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 printed per stack_handle - log is more compact,
- added display name
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: Andrzej Hajda
Reviewed-by: Andi Shyti
---
lib/ref_tracker.c | 5 +++
Beside reusing existing code, the main advantage of ref_tracker is
tracking per instance of wakeref. It allows also to catch double
put.
On the other side we lose information about the first acquire and
the last release, but the advantages outweigh it.
Signed-off-by: Andrzej Hajda
---
drivers/gp
Wakeref has dedicated type. Assumption it will be int
compatible forever is incorrect.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_
Hi
Am 21.04.23 um 13:32 schrieb Linux regression tracking (Thorsten Leemhuis):
On 20.04.23 17:57, Pierre Asselin wrote:
Some legacy BIOSes report no reserved bits in their 32-bit rgb mode,
breaking the calculation of bits_per_pixel in commit f35cd3fa7729
("firmware/sysfb: Fix EFI/VESA format se
Track every intel_gt_pm_get() until its corresponding release in
intel_gt_pm_put() by returning a cookie to the caller for acquire that
must be passed by on released. When there is an imbalance, we can see who
either tried to free a stale wakeref, or who forgot to free theirs.
Signed-off-by: Andrz
On 20/04/23 20:22, Maíra Canal wrote:
> Before commit bc0d7fdefec6 ("drm: vkms: Supports to the case where
> primary plane doesn't match the CRTC"), the composition was executed on
> top of the primary plane. Therefore, the primary plane was not able to
> support the alpha channel. After commit
On 20/04/2023 00:00, 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 in PTE has far more levels than what's defined in the
enum. I
On Fri, Apr 21, 2023 at 6:28 AM Marek Szyprowski
wrote:
>
> On 21.04.2023 10:40, Lucas Stach wrote:
> > Am Donnerstag, dem 20.04.2023 um 16:51 -0500 schrieb Adam Ford:
> >> On Thu, Apr 20, 2023 at 8:43 AM Lucas Stach wrote:
> >>> Am Donnerstag, dem 20.04.2023 um 08:24 -0500 schrieb Adam Ford:
> >
On Fri, Apr 21, 2023 at 6:25 AM Marek Szyprowski
wrote:
>
> On 15.04.2023 12:41, Adam Ford wrote:
> > Fetch the clock rate of "sclk_mipi" (or "pll_clk") instead of
> > having an entry in the device tree for samsung,pll-clock-frequency.
> >
> > Signed-off-by: Adam Ford
>
> This one breaks DSI pane
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:
> >
> >> +/**
> >> + * enum drm_gem_object_status - bitmask of object state for fdinfo
> >> reporting
> >> + * @DRM_GEM_OBJECT_RESIDENT: object is re
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:
+/**
+ * enum drm_gem_object_status - bitmask of object state for fdinfo reporting
+ * @DRM_GEM_OBJECT_RESI
Greetings everyone,
Above all - hell yeah. Thank you Tvrtko, this has been annoying the
hell out of me for ages.
On Tue, 14 Mar 2023 at 14:19, Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> With the typical model where the display server opends the file descriptor
> and then hands it over t
Hi
Am 20.04.23 um 17:57 schrieb Pierre Asselin:
Some legacy BIOSes report no reserved bits in their 32-bit rgb mode,
breaking the calculation of bits_per_pixel in commit f35cd3fa7729
("firmware/sysfb: Fix EFI/VESA format selection"). However they report
lfb_depth correctly for those modes. Kee
On 4/21/23 04:05, Marius Vlad wrote:
Hi Maíra,
Thanks a lot for taking a look!
On Thu, Apr 20, 2023 at 01:47:59PM -0300, Maíra Canal wrote:
Hi Marius,
Thanks for the changing the commit message! Just a few nits:
On 4/20/23 05:41, Marius Vlad wrote:
This adds support for creating multiple vi
On Fri, 21 Apr 2023 00:31:13 +0200, Konrad Dybcio wrote:
> Document the SM6350 MDSS.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6350-mdss.yaml | 214
> +
> 1 file changed, 214 insertions(+)
>
My bot found errors running 'make DT_CHECKER_
On Fri, 21 Apr 2023 00:31:15 +0200, Konrad Dybcio wrote:
> Document the SM6375 MDSS.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6375-mdss.yaml | 216
> +
> 1 file changed, 216 insertions(+)
>
My bot found errors running 'make DT_CHECKER_
[Public]
Much appreciated, Ville and Jani!
To tackle this MST message ack event now, probably I could just pull out the
drm_dp_mst_kick_tx() out of drm_dp_mst_hpd_irq() and make it the second
step function to handle mst hpd irq? Would like to know your thoughts : )
Again, thanks for your time!
Hi Arnaud,
Some review comments below...
On 4/18/23 20:10, Arnaud Vrac wrote:
> Some Qualcomm SoCs that support HDMI also support CEC, including MSM8996
> and MSM8998. The hardware block can handle a single CEC logical address
> and broadcast messages.
>
> Port the CEC driver from downstream msm
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 Revisi
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
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 b
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 --git
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
> ---
> driv
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 Vi
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 mas
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 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 pri
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: And
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 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 change
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 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 09:27:49
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:
> >>>
> +/**
> + * enu
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 co
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 a
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 accord
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
---
drivers/gpu/
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 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 heci-packet-submission
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
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. Ve
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 +
include
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
chronol
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
> ---
> drivers/gpu/drm/panel/p
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 lin
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 under
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
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 DRM_
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 +
include
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. Ve
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.
> >>
> >
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 (800
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: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 b
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.
[Wh
> 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
>>
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 i
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 insertion
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: 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
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: F
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 H
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 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, ha
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 def
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 PTE
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 Yan
1 - 100 of 151 matches
Mail list logo
