On Thu, Apr 27, 2023 at 11:56:22AM +1000, Dave Airlie wrote:
> On Thu, 20 Apr 2023 at 05:19, Rodrigo Vivi wrote:
> >
> > Let’s establish a merge plan for Xe, by writing down clear pre-merge goals,
> > in
> > order to avoid unnecessary delays.
>
> LGTM,
>
> Acked-by: Dave Airlie
Thanks,
Hi Dave, Daniel,
Fixes for 6.4. A bit bigger than usual since it's two weeks worth. Mostly
display fixes.
The following changes since commit e82c98f2ca439356d5595ba8c9cd782f993f6f8c:
Merge tag 'amd-drm-next-6.4-2023-04-14' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next
A use-after-free bug may occur if init_imstt invokes framebuffer_release
and free the info ptr. The caller, imsttfb_probe didn't notice that and
still keep the ptr as private data in pdev.
If we remove the driver which will call imsttfb_remove to make cleanup,
UAF happens.
Fix it by return error
A use-after-free bug may occur if init_imstt invokes framebuffer_release
and free the info ptr. The caller, imsttfb_probe didn't notice that and
still keeps the ptr as private data in pdev.
If we remove the driver which will call imsttfb_remove to make cleanup,
UAF happens.
Fix it by return
On Thu, 20 Apr 2023 at 05:19, Rodrigo Vivi wrote:
>
> Let’s establish a merge plan for Xe, by writing down clear pre-merge goals, in
> order to avoid unnecessary delays.
LGTM,
Acked-by: Dave Airlie
>
> This initial document starts with a TODO list containing items with clear and
> measurable
Hi Linus,
A bit out of routine fixes pull for rc1, there's a build breakage on
some platforms due to ttm, this has that fix + qaic uapi removal +
minor panel fixes.
Dave.
drm-next-2023-04-27:
drm-next fixes for 6.4-rc1
ttm:
- Fix TTM build on archs where PMD_SHIFT is not constant.
qaic:
-
Thorsten Leemhuis writes:
> Lo!
>
> Sometimes the regression tracker runs into regressions himself... :-D
>
> On 11.04.23 08:47, Stephen Rothwell wrote:
>>
>> After merging the drm tree, today's linux-next build (powerpc
>> allyesconfig) failed like this:
>>
>>
On Wed, Apr 26, 2023 at 4:05 AM Christian König
wrote:
>
> Am 26.04.23 um 08:17 schrieb Chia-I Wu:
> > mgr->ctx_handles should be protected by mgr->lock.
> >
> > v2: improve commit message
> >
> > Signed-off-by: Chia-I Wu
> > Cc: sta...@vger.kernel.org
>
> Please don't manually CC
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 for editing a foreign
process's priority v3")
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
Linus Torvalds writes:
> On Wed, Apr 26, 2023 at 10:44 AM Sudip Mukherjee (Codethink)
> wrote:
>>
>> drivers/gpu/drm/ttm/ttm_pool.c:73:29: error: variably modified
>> 'global_write_combined' at file scope
>>73 | static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
>> |
On 4/26/2023 3:37 PM, 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
On 4/26/2023 3:37 PM, Marijn Suijten wrote:
According to downstream sources this DITHER sub-block sits at an offset
of 0xe0 with version 0x2. The PP_BLK_DITHER macro is _not_ used as
downstream still says the size of the PINGPONG block is 0xd4 and not 0.
Fixes: 4a352c2fc15a
On 4/26/2023 3:37 PM, Marijn Suijten wrote:
No hardware beyond kona (sm8250, DPU 6.0.0) defines the TE2 PINGPONG
sub-block offset downstream, and according to insiders no DPU >= 5.0.0
hardware has support for it either. Especially since neither downstream
nor upstream utilize these registers
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block, including vsync source selection
that was previously part of MDP top. Writing to the MDP_VSYNC_SEL
register has no effect anymore and is omitted downstream via the
DPU/SDE_MDP_VSYNC_SEL feature
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block. Writing these registers has no
effect, and is omitted downstream via the DPU/SDE_PINGPONG_TE feature
flag. This flag is only added to PINGPONG blocks used by hardware prior
to 5.0.0.
The
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
---
Now that newer DPU platforms use a readpointer-done interrupt on the
INTF block, stop providing the unused interrupt on the PINGPONG block.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 8
From: Konrad Dybcio
Now that newer SoCs since DPU 5.0.0 manage tearcheck in the INTF instead
of PINGPONG block, move the struct definition to a common file. Also,
bring in documentation from msm-4.19 techpack while at it.
Signed-off-by: Konrad Dybcio
[Marijn: Also move dpu_hw_pp_vsync_info]
These functions are always called consecutively and are best bundled
together for simplicity, especially when the same structure of callbacks
will be replicated later on the interface block for INTF TE support.
The enable_tearcheck(false) case is now replaced with a more obvious
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.
Fixes: efcd0107727c ("drm/msm/dpu: add
According to downstream sources this DITHER sub-block sits at an offset
of 0xe0 with version 0x2. The PP_BLK_DITHER macro is _not_ used as
downstream still says the size of the PINGPONG block is 0xd4 and not 0.
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
Fixes: 0e91bcbb0016
The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT
registers are already defined higher up, in the right place when sorted
numerically.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
A bunch of registers were appended at the end in e.g. commit
91143873a05d ("drm/msm/dpu: Add MISR register support for interface")
rather than being inserted in a place that maintains numerical sorting:
restore said numerical sorting.
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybcio
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. The new interrupts are
described in dpu_hw_interrupts.c, now wire them up in individual SoC
catalog files by setting the intr_tear_rd_ptr to the IRQ index spcified
in the offset
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 sub-block.
A future patch, part of the DSC
This autorefresh disable logic in the physical command-mode encoder
consumes three callbacks to the pingpong block, and will explode in
unnecessary complexity when the same callbacks need to be called on the
interface block instead to accommodate INTF TE support. To clean this
up, move the logic
As the INTF block is going to attain more interrupts that don't share
the same MDP_SSPP_TOP0_INTR register, factor out the _reg argument for
the caller to construct the right interrupt index (register and bit
index) to not make the interrupt bit arguments depend on one of multiple
interrupt
Instead of hardcoding many register defines for every INTF and AD4 index
with a fixed stride, turn the defines into singular chunks of math that
compute the address using the base and this fixed stride multiplied by
the index given as argument to the definitions.
MDP_SSPP_TOP0_OFF is dropped as
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
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
This callback was migrated from downstream when DPU1 was first
introduced to mainline, but never used by any component. Drop it to
save some lines and unnecessary confusion.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
A bunch of registers are indented with two extra spaces, looking as if
these are values corresponding to the previous register which is not the
case, rather these are simply also register offsets and should only have
a single space separating them and the #define keyword.
Signed-off-by: Marijn
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts. Additionally, disable previous register writes and remove
unused
Neither of these SoCs has INTF0, they only have a DSI interface on index
1. Stop enabling an interrupt that can't fire.
Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
Fixes: 5334087ee743 ("drm/msm: add support for QCM2290 MDSS")
Signed-off-by: Marijn Suijten
Use tabs for consistency with the other interrupt register definitions,
rather than spaces.
Fixes: ed6154a136e4 ("drm/msm/disp/dpu1: add intf offsets for SC7280 target")
Fixes: 89688e2119b2 ("drm/msm/dpu: Add more of the INTF interrupt regions")
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce
No hardware beyond kona (sm8250, DPU 6.0.0) defines the TE2 PINGPONG
sub-block offset downstream, and according to insiders no DPU >= 5.0.0
hardware has support for it either. Especially since neither downstream
nor upstream utilize these registers in any way, remove the erroneous
specification
These offsets do not fall under the MDP TOP block and do not fit the
comment right above. Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x_OFF interrupt block offsets.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad
On 2023-04-26 11:17:16, Teres Alexis, Alan Previn wrote:
> alan: Hi Jordan, Tvrtko, Daniel Vetter and Lionel,...
> how to proceed on this series (which have required Rb/Ack's) in light of
> the recent discussion on the other series here:
>
On Wed, Apr 26, 2023 at 02:40:18PM -0700, Lucas De Marchi wrote:
> On Wed, Apr 26, 2023 at 04:57:00PM -0400, Rodrigo Vivi wrote:
> > On xe_hw_engine_print_state we were printing:
> > value_of(0x510) + 4 instead of
> > value_of(0x514) as desired.
> >
> > So, let's properly define a
On Wed, Apr 26, 2023 at 04:57:00PM -0400, Rodrigo Vivi wrote:
On xe_hw_engine_print_state we were printing:
value_of(0x510) + 4 instead of
value_of(0x514) as desired.
So, let's properly define a RING_EXECLIST_SQ_CONTENTS_HI
register to fix the issue and also to avoid other issues
like that.
On Wed, 2023-04-26 at 11:24 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Rename the 'default_' register list prefix to 'gen8_' as that is the
> more accurate name.
>
> Signed-off-by: John Harrison
Reviewed-by: Alan Previn
The goal is to allow for a snapshot capture to be taken at the time
of the crash, while the print out can happen at a later time through
the exposed devcoredump virtual device.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/xe/xe_guc_submit.c | 2 +-
drivers/gpu/drm/xe/xe_vm.c | 137
With this patch, we now have some parity between xe_devcoredump
and the simple_error_capture. The only difference is that
xe_devcoredump will only stash the 'first' hang, which is the one
that we care most and should analyze first, while
simple_error_capture will dump them all the kernel log.
But
On 4/26/23 15:24, Harshit Mogalapalli wrote:
We have a NULL check for 'dc_dmub_srv' in dc_dmub_srv_cmd_run_list()
but we are dereferencing it before checking.
Fix this moving the dereference next to NULL check.
This issue is found with Smatch(static analysis tool).
Fixes: e97cc04fe0fb
Let's continue to add our existent simple logs to devcoredump one
by one. Any format change should come on follow-up work.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/xe/xe_devcoredump.c | 45 +++
drivers/gpu/drm/xe/xe_devcoredump_types.h | 4 ++
2 files changed,
There are multiple kind of config prints and with the upcoming
devcoredump there will be another layer. Let's limit the config
to the top level functions and leave the clean-up work for the
compilers so we don't create a spider-web of configs.
No functional change. Just a preparation for the
The goal is to allow for a snapshot capture to be taken at the time
of the crash, while the print out can happen at a later time through
the exposed devcoredump virtual device.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/xe/xe_guc_submit.c | 212 +++
Let's start to move our existent logs to devcoredump one by
one. Any format change should come on follow-up work.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/xe/xe_devcoredump.c | 7 ++-
drivers/gpu/drm/xe/xe_devcoredump_types.h | 2 ++
2 files changed, 8 insertions(+), 1
The goal is to allow for a snapshot capture to be taken at the time
of the crash, while the print out can happen at a later time through
the exposed devcoredump virtual device.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/xe/xe_gt_debugfs.c | 2 +-
drivers/gpu/drm/xe/xe_guc_submit.c
These structs and definitions are only used for the guc_submit
and they were added specifically for the parallel submission.
While doing that also delete the unused struct guc_wq_item.
Cc: Matthew Brost
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/xe/xe_guc_fwif.h | 29 ---
Let's start to move our existent logs to devcoredump one by
one. Any format change should come on follow-up work.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/xe/xe_devcoredump.c | 14 ++
drivers/gpu/drm/xe/xe_devcoredump_types.h | 4
2 files changed, 18 insertions(+)
The goal is to allow for a snapshot capture to be taken at the time
of the crash, while the print out can happen at a later time through
the exposed devcoredump virtual device.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/xe/xe_guc_ct.c | 132 +++
No functional change here. The goal is to have a clear split between
the mapped portions of the CTB and the static information, so we can
easily capture snapshots that will be used for later read out with
the devcoredump infrastructure.
Signed-off-by: Rodrigo Vivi
---
Unfortunately devcoredump infrastructure does not provide and
interface for us to force the device removal upon the pci_remove
time of our device.
The devcoredump is linked at the device level, so when in use
it will prevent the module removal, but it doesn't prevent the
call of the pci_remove
The goal is to use devcoredump infrastructure to report error states
captured at the crash time.
The error state will contain useful information for GPU hang debug, such
as INSTDONE registers and the current buffers getting executed, as well
as any other information that helps user space and
On xe_hw_engine_print_state we were printing:
value_of(0x510) + 4 instead of
value_of(0x514) as desired.
So, let's properly define a RING_EXECLIST_SQ_CONTENTS_HI
register to fix the issue and also to avoid other issues
like that.
Signed-off-by: Rodrigo Vivi
---
Xe needs to align with other drivers on the way that the error states are
dumped, avoiding a Xe only error_state solution. The goal is to use devcoredump
infrastructure to report error states, since it produces a standardized way
by exposing a virtual and temporary /sys/class/devcoredump device.
On 4/20/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 4/20/23 09:59, Tom Rix wrote:
gcc with W=1 reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:
In function ‘dc_dmub_srv_optimized_init_done’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:184:26:
error: variable ‘dmub’ set but not used
On 2023-04-26 12:11:39, Abhinav Kumar wrote:
>
>
> On 4/26/2023 12:08 PM, Marijn Suijten wrote:
> > On 2023-04-26 09:24:19, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/25/2023 4:05 PM, Marijn Suijten wrote:
> >>> According to downstream sources this DITHER sub-block sits at an offset
> >>> of 0xe0
On 2023-04-26 04:52:43, Daniel Vetter wrote:
>
> Joonas asked me to put my thoughts here:
>
> - in general the "feature discovery by trying it out" approach is most
> robust and hence preferred, but it's also not something that's required
> when there's good reasons against it
More robust
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(),
> fb_writel() or fb_memcpy_to_fb(). The implementation of each helper
> depends on the architecture. It's still all located in fbdev's main
> header file
Sorry for the spam, this should have been v2, I have fixed that and
resent this series.
On 4/26/2023 12:20 PM, 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
We have a NULL check for 'dc_dmub_srv' in dc_dmub_srv_cmd_run_list()
but we are dereferencing it before checking.
Fix this moving the dereference next to NULL check.
This issue is found with Smatch(static analysis tool).
Fixes: e97cc04fe0fb ("drm/amd/display: refactor dmub commands into single
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
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4 ++--
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.
Signed-off-by: Abhinav Kumar
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:
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
Reviewed-by:
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
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 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
Reviewed-by:
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:
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.
Signed-off-by: Abhinav Kumar
On 4/26/2023 12:08 PM, Marijn Suijten wrote:
On 2023-04-26 09:24:19, Abhinav Kumar wrote:
On 4/25/2023 4:05 PM, Marijn Suijten wrote:
According to downstream sources this DITHER sub-block sits at an offset
of 0xe0 with version 0x2. The PP_BLK_DITHER macro is _not_ used as
downstream
On 2023-04-26 09:24:19, Abhinav Kumar wrote:
>
>
> On 4/25/2023 4:05 PM, Marijn Suijten wrote:
> > According to downstream sources this DITHER sub-block sits at an offset
> > of 0xe0 with version 0x2. The PP_BLK_DITHER macro is _not_ used as
> > downstream still says the size of the
Am 26.04.23 um 20:30 schrieb Linus Torvalds:
On Wed, Apr 26, 2023 at 10:44 AM Sudip Mukherjee (Codethink)
wrote:
drivers/gpu/drm/ttm/ttm_pool.c:73:29: error: variably modified
'global_write_combined' at file scope
73 | static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
Add maintainers entry for ASP 2.0 Ethernet driver.
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4fc57dfd5fd0..24cbe1c0fc06 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@
Add support for the Broadcom ASP 2.0 Ethernet controller which is first
introduced with 72165. This controller features two distinct Ethernet
ports that can be independently operated.
This patch supports:
- Wake-on-LAN using magic packets
- basic ethtool operations (link, counters, message
Add mdio compat string for ASP 2.0 ethernet driver.
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
Reviewed-by: Andrew Lunn
---
drivers/net/mdio/mdio-bcm-unimac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/mdio/mdio-bcm-unimac.c
From: Florian Fainelli
74165 is a 16nm process SoC with a 10/100 integrated Ethernet PHY,
utilize the recently defined 16nm EPHY macro to configure that PHY.
Signed-off-by: Florian Fainelli
Signed-off-by: Justin Chen
Reviewed-by: Andrew Lunn
---
drivers/net/phy/bcm7xxx.c | 1 +
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 +
1 file changed, 145 insertions(+)
create mode 100644
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(+)
diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml
v2
- Updates to yaml dt documentation
- Replace a couple functions with helper functions
- Minor formatting fixes
- Fix a few WoL issues
Add support for the Broadcom ASP 2.0 Ethernet controller which is first
introduced with 72165.
Add support for 74165 10/100
From: Rob Clark
Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits. This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can addjust GPU frequency accordingly. An immediate deadline can be
Hi Linus,
please pull the fbdev updates for v6.4-rc1.
Nothing really exiting in here. The majority of lines changed is
due to Uwe's preparation patches to change the return value of the
.remove() callback to void.
Thanks!
Helge
The following changes since commit
On Wed, Apr 26, 2023 at 10:44 AM Sudip Mukherjee (Codethink)
wrote:
>
> drivers/gpu/drm/ttm/ttm_pool.c:73:29: error: variably modified
> 'global_write_combined' at file scope
>73 | static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
> |
From: John Harrison
Rename the 'default_' register list prefix to 'gen8_' as that is the
more accurate name.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
On Thu, 2023-04-20 at 22:34 -0700, Teres Alexis, Alan Previn wrote:
> 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
On 4/26/2023 9:48 AM, Teres Alexis, Alan Previn wrote:
On Wed, 2023-04-26 at 13:52 +0200, Daniel Vetter wrote:
On Tue, Apr 25, 2023 at 04:41:54PM +0300, Joonas Lahtinen wrote:
(+ Faith and Daniel as they have been involved in previous discussions)
Quoting Jordan Justen (2023-04-24 20:13:00)
On 4/25/2023 11:54, Teres Alexis, Alan Previn wrote:
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
From: John Harrison
Don't use 'xe_lp*' prefixes for register lists that are common with
Gen8.
alan:snip
@@ -177,32 +177,32 @@ static const struct
Hi All,
The latest mainline kernel branch fails to build powerpc allmodconfig
with the error:
drivers/gpu/drm/ttm/ttm_pool.c:73:29: error: variably modified
'global_write_combined' at file scope
73 | static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
|
On 4/26/2023 10:29, John Harrison wrote:
On 4/25/2023 12:05, Teres Alexis, Alan Previn wrote:
On Thu, 2023-04-06 at 15:26 -0700,john.c.harri...@intel.com wrote:
From: John Harrison
Fix Xe_LP name.
Signed-off-by: John Harrison
alan:snip
-/* GEN9/XE_LPD - Render / Compute
On 4/25/2023 12:05, Teres Alexis, Alan Previn wrote:
On Thu, 2023-04-06 at 15:26 -0700,john.c.harri...@intel.com wrote:
From: John Harrison
Fix Xe_LP name.
Signed-off-by: John Harrison
alan:snip
-/* GEN9/XE_LPD - Render / Compute Per-Engine-Instance */
+/* GEN8+ Render / Compute
On 4/25/23 03:53, Christophe JAILLET wrote:
The intent here is to clear the 'available_slices' buffer before setting
some values in it.
This is an array of int, so in order to fully initialize it, we must clear
MIN_AVAILABLE_SLICES_SIZE * sizeof(int) bytes.
Compute the right length of the
On 4/25/2023 10:55, Teres Alexis, Alan Previn wrote:
On Thu, 2023-04-06 at 15:26 -0700, Harrison, John C wrote:
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.
On 4/26/23 07:18, Tom Rix wrote:
smatch reports
drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c:119:31:
warning: symbol 'custom_backlight_curve0' was not declared. Should it be
static?
This variable is only used in its defining file, so it should be static
Signed-off-by:
On Wed, 2023-04-26 at 13:52 +0200, Daniel Vetter wrote:
> On Tue, Apr 25, 2023 at 04:41:54PM +0300, Joonas Lahtinen wrote:
> > (+ Faith and Daniel as they have been involved in previous discussions)
> > Quoting Jordan Justen (2023-04-24 20:13:00)
> > > On 2023-04-24 02:08:43, Tvrtko Ursulin 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 warnings.
>
> Patches 1-4 focus on moving
Add err code check for enable_communication on resume path. When resume failed,
we can no longer use the GPU, marking the GPU as wedged.
Signed-off-by: Zhanjun Dong
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 7 ++-
drivers/gpu/drm/i915/gt/intel_reset.c | 19 ---
On 4/25/2023 4:05 PM, Marijn Suijten wrote:
According to downstream sources this DITHER sub-block sits at an offset
of 0xe0 with version 0x2. The PP_BLK_DITHER macro is _not_ used as
downstream still says the size of the PINGPONG block is 0xd4 and not 0.
the PINGPONG block size is 0x0
Use the helper function in TTM to get TTM mem limit and
set GTT size to be equal to TTL mem limit.
Signed-off-by: Mukul Joshi
Reviewed-by: Christian König
---
v1->v2:
- Remove AMDGPU_DEFAULT_GTT_SIZE_MB as well as it is
unused.
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
[AMD Official Use Only - General]
> -Original Message-
> From: Chen, Guchun
> Sent: Wednesday, April 26, 2023 2:00 AM
> To: Joshi, Mukul ; amd-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org
> Cc: Joshi, Mukul ; Kuehling, Felix
> ; Koenig, Christian
> Subject: RE: [PATCH
1 - 100 of 185 matches
Mail list logo
