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
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
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
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
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
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 is focusing on uAPI changes,
1. end support for set caching ioctl
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
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
This patch set was posted at
https://patchwork.freedesktop.org/series/116868/
Change title since the PTE patch was merged separately.
These patches are extracted from series
https://patchwork.freedesktop.org/series/115980/
This series refactor the cache policy programming so
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,
Hi,
> -Original Message-
> From: Intel-gfx On Behalf Of Ye,
> Tony
> Sent: perjantai 28. huhtikuuta 2023 6.11
> To: Ceraolo Spurio, Daniele ; intel-
> g...@lists.freedesktop.org
> Cc: Teres Alexis, Alan Previn ; dri-
> de...@lists.freedesktop.org; Zhang, Carl
> Subject: Re:
Acked-by: Tony Ye
Thanks,
Tony
On 4/27/2023 7:34 PM, Daniele Ceraolo Spurio wrote:
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
On Thu, Apr 27, 2023 at 7:02 PM Daniel Vetter wrote:
>
> On Tue, Apr 25, 2023 at 08:02:40AM +, Brandon Pollack wrote:
> > added documentation to drm_dev_unregister clarifying that devres managed
> > devices allocated with devm_drm_dev_alloc do not require calls to
> > drm_dev_put.
> >
> >
I'm adding the original offer of those changes. We talked recently
and they have the intent to push forward and merge them. I'm still
getting up to speed a bit, but I will probably have a stronger opinion
by early next week.
On Wed, Apr 26, 2023 at 9:54 PM Marius Vlad wrote:
>
> Hi Brandon,
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
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
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:
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
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
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
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
On Wed, 2023-04-26 at 16:10 +0300, Dmitry Baryshkov wrote:
> On Wed, 26 Apr 2023 at 12:09, zongmin zhou
> wrote:
> >
> > On Sun, 2023-04-23 at 22:51 +0200, Janne Grunau wrote:
> > > On 2023-04-20 23:07:01 +0300, Dmitry Baryshkov wrote:
> > > > On Thu, 20 Apr 2023 at 23:01, Janne Grunau
> > > >
On April 27, 2023 3:50:06 PM PDT, Karol Herbst wrote:
>On Fri, Apr 28, 2023 at 12:46 AM Lyude Paul wrote:
>>
>> Hey Linus, Kees. Responses below
>>
>> On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
>> > On April 23, 2023 10:36:24 AM PDT, Linus Torvalds
>> > wrote:
>> > > Kees,
>> > > I
On Thu, 2023-04-27 at 16:48 -0700, Teres Alexis, 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.
>
>
alan: I accidentally
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
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
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:
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
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 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
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
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
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
On Fri, Apr 28, 2023 at 1:27 AM Lyude Paul wrote:
>
> On Fri, 2023-04-28 at 00:50 +0200, Karol Herbst wrote:
> > On Fri, Apr 28, 2023 at 12:46 AM Lyude Paul wrote:
> > >
> > > Hey Linus, Kees. Responses below
> > >
> > > On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
> > > > On April 23,
On sc7280 where eDP is the primary display, PSR is causing
IGT breakage even for basic test cases like kms_atomic and
kms_atomic_transition. Most often the issue starts with below
stack so providing that as reference
Call trace:
dpu_encoder_assign_crtc+0x64/0x6c
dpu_crtc_enable+0x188/0x204
On Fri, 2023-04-28 at 00:50 +0200, Karol Herbst wrote:
> On Fri, Apr 28, 2023 at 12:46 AM Lyude Paul wrote:
> >
> > Hey Linus, Kees. Responses below
> >
> > On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
> > > On April 23, 2023 10:36:24 AM PDT, Linus Torvalds
> > > wrote:
> > > > Kees,
>
On Fri, Apr 28, 2023 at 12:46 AM Lyude Paul wrote:
>
> Hey Linus, Kees. Responses below
>
> On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
> > On April 23, 2023 10:36:24 AM PDT, Linus Torvalds
> > wrote:
> > > Kees,
> > > I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
Hey Linus, Kees. Responses below
On Sun, 2023-04-23 at 13:23 -0700, Kees Cook wrote:
> On April 23, 2023 10:36:24 AM PDT, Linus Torvalds
> wrote:
> > Kees,
> > I made the mistake of upgrading my M2 Macbook Air to Fedora-38, and
> > in the process I got gcc-13 which is not WERROR-clean because
On 2023-04-21 00:31:19, Konrad Dybcio wrote:
> Add support for MDSS on SM6375.
>
> Signed-off-by: Konrad Dybcio
Reviewed-by: Marijn Suijten
(After reusing sm6350 data, as suggested by Dmitry)
> ---
> drivers/gpu/drm/msm/msm_mdss.c | 10 ++
> 1 file changed, 10 insertions(+)
>
>
On 2023-04-21 00:31:17, Konrad Dybcio wrote:
> Add support for MDSS on SM6350.
>
> Signed-off-by: Konrad Dybcio
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/msm_mdss.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c
On 2023-04-14 16:51:52, Abhinav Kumar wrote:
> On 4/14/2023 4:11 PM, Marijn Suijten wrote:
> > On 2023-04-14 10:57:45, Abhinav Kumar wrote:
> >> On 4/14/2023 10:34 AM, Marijn Suijten wrote:
> >>> On 2023-04-14 08:48:43, Abhinav Kumar wrote:
> On 4/14/2023 12:35 AM, Marijn Suijten wrote:
>
On 2023-04-27 13:20:28, Abhinav Kumar wrote:
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> @@ -127,12 +127,10 @@ enum {
> >> /**
> >> * DSPP sub-blocks
> >> * @DPU_DSPP_PCC Panel color correction block
On 2023-04-26 12:22:46, Abhinav Kumar wrote:
> 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
Fair enough, I'd use the oldest SoC
DSPP*
On 2023-04-26 12:22:44, Abhinav Kumar wrote:
> 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
DSPP*
> to remove IGC from the catalog.
>
> We can add this back when IGC is properly supported in DPU
On 2023-04-26 12:22:43, 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
On 4/27/2023 8:57 AM, Dmitry Baryshkov wrote:
On 26/04/2023 22:22, 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
> Fix the email Sign-off email != Sender email issue, resubmit and I'll
> be able to apply this.
You can pick the email from my tag “Signed-off-by” up also directly
as an ordinary patch author email, can't you?
Regards,
Markus
The pull request you sent on Wed, 26 Apr 2023 20:40:07 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
> tags/fbdev-for-6.4-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/725a345b2ee3c24f9ac2078eb73667e22a1b7214
Thank you!
--
Hi Maxime,
On 4/25/23 09:48, Maxime Ripard wrote:
Hi Dinh,
On Mon, Apr 24, 2023 at 01:32:28PM -0500, Dinh Nguyen wrote:
On 4/4/23 05:11, Maxime Ripard wrote:
The SoCFGPA gate clock implements a mux with a set_parent hook, but
doesn't provide a determine_rate implementation.
This is a bit
Applied. Thanks!
Alex
On Wed, Apr 26, 2023 at 6:55 PM Chia-I Wu wrote:
>
> mgr->ctx_handles should be protected by mgr->lock.
>
> v2: improve commit message
> v3: add a Fixes tag
>
> Signed-off-by: Chia-I Wu
> Reviewed-by: Christian König
> Fixes: 52c6a62c64fac ("drm/amdgpu: add interface
On Thu, Apr 27, 2023 at 10:16 AM Rob Herring wrote:
>
> On Wed, Apr 26, 2023 at 11:54:28AM -0700, 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
On 27/04/2023 21:19, Teres Alexis, Alan Previn wrote:
(fixed email addresses again - why is my Evolution client deteorating??)
On Thu, 2023-04-27 at 17:18 +, Teres Alexis, Alan Previn wrote:
On Wed, 2023-04-26 at 15:35 -0700, Justen, Jordan L wrote:
On 2023-04-26 11:17:16, Teres Alexis,
(fixed email addresses again - why is my Evolution client deteorating??)
On Thu, 2023-04-27 at 17:18 +, Teres Alexis, Alan Previn wrote:
> On Wed, 2023-04-26 at 15:35 -0700, Justen, Jordan L wrote:
> > On 2023-04-26 11:17:16, Teres Alexis, Alan Previn wrote:
> alan:snip
> > Can you tell that
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct
From: Rob Clark
Also store the override strings in drm_file so that fdinfo can display
them. We still need to keep our original copy as we could need these
override strings after the device file has been closed and drm_file
freed.
Signed-off-by: Rob Clark
---
From: Rob Clark
The restriction about no whitespace, etc, really only applies to the
usage of strings in keys. Values can contain anything (other than
newline).
Signed-off-by: Rob Clark
Acked-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 27 ++-
1
From: Rob Clark
These are useful in particular for VM scenarios where the process which
has opened to drm device file is just a proxy for the real user in a VM
guest.
Signed-off-by: Rob Clark
---
Documentation/gpu/drm-usage-stats.rst | 18 ++
drivers/gpu/drm/drm_file.c
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
Signed-off-by: Rob Clark
Reviewed-by: Emil Velikov
Reviewed-by: Daniel Vetter
---
Documentation/gpu/drm-usage-stats.rst | 54
From: Rob Clark
Now that we have a common helper, use it.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 11 +--
drivers/gpu/drm/msm/msm_gpu.c | 2 --
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git
From: Rob Clark
Signed-off-by: Rob Clark
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12
From: Rob Clark
Use the new helper to export stats about memory usage.
v2: Drop unintended hunk
v3: Rebase
Signed-off-by: Rob Clark
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/msm/msm_drv.c | 2 ++
drivers/gpu/drm/msm/msm_gem.c | 15 +++
2 files changed, 17 insertions(+)
From: Rob Clark
Handle a bit of the boiler-plate in a single case, and make it easier to
add some core tracked stats. This also ensures consistent behavior
across drivers for standardised fields.
v2: Update drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo
Reviewed-by: Daniel Vetter
From: Rob Clark
Fix a couple missing ':'s.
Signed-off-by: Rob Clark
Reviewed-by: Rodrigo Vivi
---
Documentation/gpu/drm-usage-stats.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start.
On 27/04/2023 01:37, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. Wire up the IRQ register
masks in the interrupt table for enabling, reading and clearing them.
Signed-off-by: Marijn Suijten
---
On 27/04/2023 01:37, Marijn Suijten wrote:
Despite downstream DTS stating otherwise, the PINGPONG block has no
registers starting with DPU revision 7.0.0. TEAR registers are gone
since DPU 5.0.0 after being moved to the INTF block, and DSC registers
are gone since 7.0.0, leaving only the dither
Hi Thomas,
On Thu, Apr 27, 2023 at 09:22:47AM +0200, Thomas Zimmermann wrote:
> Hi Sam
>
> Am 26.04.23 um 21:21 schrieb Sam Ravnborg:
> > Hi Thomas.
> >
> > On Wed, Apr 26, 2023 at 03:04:15PM +0200, Thomas Zimmermann wrote:
> > > Fbdev provides helpers for framebuffer I/O, such as fb_readl(),
>
On Wed, Apr 26, 2023 at 11:54:28AM -0700, 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 | 145
On 4/27/23 10:03, Rob Herring wrote:
On Wed, Apr 26, 2023 at 11:54:27AM -0700, Justin Chen wrote:
The ASP 2.0 Ethernet controller uses a brcm unimac.
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
---
Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml | 2 ++
1 file
On Wed, Apr 26, 2023 at 11:54:27AM -0700, Justin Chen wrote:
> The ASP 2.0 Ethernet controller uses a brcm unimac.
>
> Signed-off-by: Florian Fainelli
> Signed-off-by: Justin Chen
> ---
> Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
>
On Fri, 2023-04-14 at 17:27 -0700, john.c.harri...@intel.com wrote:
> 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]
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 the connection beween the two connectors.
Currently, even if a display uses a USB Type-C port, there is no way for
the userspace to find
> 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 patches are included here because the last patch
has
On Wed, 2023-04-19 at 16:54 -0400, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
>
> Thanks!
>
> On Wed, 2023-04-19 at 07:24 -0400, Jeff Layton wrote:
> > I've been experiencing some intermittent crashes down in the display
> > driver code. The symptoms are ususally a line like this in dmesg:
> >
On 27/04/2023 00:37, Marijn Suijten wrote:
SM8550 exclusively has a DITHER sub-block inside the PINGPONG block and
no other registers, hence the DITHER name of the macro and a
corresponding PINGPONG block length of zero. However, the PP_BLK_ macro
name was typo'd to DIPHER rather than DITHER.
On 26/04/2023 22:22, 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
Reviewed-by: Dmitry Baryshkov
Link:
On 26/04/2023 22:22, Abhinav Kumar wrote:
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
---
On 26/04/2023 22:22, Abhinav Kumar wrote:
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
On 26/04/2023 19:29, Doug Anderson wrote:
Hi,
On Wed, Apr 19, 2023 at 8:43 AM Mark Yacoub wrote:
Hi all,
This is v10 of the HDCP patches. The patches are authored by Sean Paul.
I rebased and addressed the review comments in v6-v10.
Main change in v10 is handling the kernel test bot
On 27/04/2023 13:50, Neil Armstrong wrote:
> On 14/04/2023 12:42, Krzysztof Kozlowski wrote:
>> Lists (items) with one item should be just const or enum because it is
>> shorter and simpler.
>>
>> Signed-off-by: Krzysztof Kozlowski
>>
>> ---
>>
>> Rebased on next-20230406. I hope it applies
On 2023-04-27 17:37:42, Marijn Suijten wrote:
> On 2023-04-21 00:31:16, Konrad Dybcio wrote:
> > Add SM6350 support to the DPU1 driver to enable display output.
> >
> > Signed-off-by: Konrad Dybcio
> > Signed-off-by: Konrad Dybcio
>
> After addressing the comments from Dmitry (CURSOR0->DMA1
On 2023-04-21 00:31:18, Konrad Dybcio wrote:
> Add basic SM6375 support to the DPU1 driver to enable display output.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h | 5 -
> .../gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h | 152
>
The pull request you sent on Thu, 27 Apr 2023 11:43:17 +1000:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/32f7ad0fbe7521de2a5e8f79c33d46110247fd7c
Thank you!
--
Deet-doot-dot, I am a bot.
On Thu, Apr 27, 2023 at 5:59 AM Daniel Vetter wrote:
>
> On Fri, Apr 21, 2023 at 12:27:47PM -0400, Mark Yacoub wrote:
> > 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
On 2023-04-21 00:31:16, Konrad Dybcio wrote:
> Add SM6350 support to the DPU1 driver to enable display output.
>
> Signed-off-by: Konrad Dybcio
> Signed-off-by: Konrad Dybcio
After addressing the comments from Dmitry (CURSOR0->DMA1 and
CURSOR1->DMA2), this is:
Reviewed-by: Marijn Suijten
Il 26/04/23 13:43, AngeloGioacchino Del Regno ha scritto:
Il 12/09/22 03:29, Jason-JH.Lin ha scritto:
Since the gamma_set_common() function for previous SoC,
such as mt8173 and mt8183, is designed for 9bit-to-10bit
conversion.
mt8195 is using 10bit-to-12bit conversion, which is
not compatible
On Tue, Apr 25, 2023 at 4:16 PM Markus Elfring wrote:
>
> > This patch seems to be a part of a series without being marked as such,
>
> The mentioned patch affects only a single function implementation.
>
>
> > this causes issues when importing this patch with maintainer tools
> > like b4 which
Hi Christian,
Patch is,
Reviewed-by: Luben Tuikov
Regards,
Luben
On 2023-04-27 08:27, Christian König wrote:
> When no hw fence is provided for a job that means that the job didn't
> executed.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 2 +-
> 1
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 patches are included here because the last patch
>> has
On Thu, Apr 27, 2023 at 2:39 AM Daniel Vetter wrote:
>
> On Fri, Apr 21, 2023 at 07:47:26AM -0700, 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
From: Francesco Dolcini
Correct computation of THS_TRAILCNT register.
This register must be set to a value that ensure that
THS_TRAIL > 60 ns + 4 x UI
and
THS_TRAIL > 8 x UI
and
THS_TRAIL < TEOT
with
TEOT = 105 ns + (12 x UI)
with the actual value of THS_TRAIL being
(1 + THS_TRAILCNT) x
From: Francesco Dolcini
Correct computation of TCLK_TRAILCNT register.
The driver does not implement non-continuous clock mode, so the actual
value doesn't make a practical difference yet. However this change also
ensures that the value does not write to reserved registers bits in case
of
From: Francesco Dolcini
Correct computation of TXTAGOCNT register.
This register must be set to a value that ensure that the
TTA-GO period = (4 x TLPX)
with the actual value of TTA-GO being
4 x (TXTAGOCNT + 1) x (HSByteClk cycle)
Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
From: Francesco Dolcini
Remove the unused phy_delay_nsk variable, before it was wrongly used
to compute some register value, the fixed computation is no longer using
it and therefore can be removed.
Signed-off-by: Francesco Dolcini
---
drivers/gpu/drm/bridge/tc358768.c | 4 +---
1 file
From: Francesco Dolcini
Correct computation of THS_ZEROCNT register.
This register must be set to a value that ensure that
THS_PREPARE + THS_ZERO > 145ns + 10*UI
with the actual value of (THS_PREPARE + THS_ZERO) being
((1 to 2) + 1 + (TCLK_ZEROCNT + 1) + (3 to 4)) x ByteClk cycle +
+
From: Francesco Dolcini
According to Toshiba documentation the PLL input clock after the divider
should be not less than 4MHz, fix the PLL parameters computation
accordingly.
Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Signed-off-by: Francesco Dolcini
---
From: Francesco Dolcini
Always enable HS video mode setting the TXMD bit, without this change no
video output is present with DSI sinks that are setting
MIPI_DSI_MODE_LPM flag (tested with LT8912B DSI-HDMI bridge).
Previously the driver was enabling HS mode only when the DSI sink was
not
From: Francesco Dolcini
Correctly compute the PLL target frequency, the current formula works
correctly only when the input bus width is 24bit, actually to properly
compute the PLL target frequency what is relevant is the bits-per-pixel
on the DSI link.
No regression expected since the DSI
1 - 100 of 149 matches
Mail list logo
