From: Pin-yen Lin
These two drivers embed a i2c_client in their private driver data, but
only strict device is actually needed. Replace the i2c_client reference
with a struct device one.
Signed-off-by: Pin-yen Lin
Reviewed-by: Andy Shevchenko
Reviewed-by: AngeloGioacchino Del Regno
Signed-of
From: Pin-yen Lin
Replace the spaces with tab characters in the Kconfig file.
Signed-off-by: Pin-yen Lin
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Chen-Yu Tsai
---
Splitting this patch out of its original type-C mux patch series [1] to
get it merged. This is a cleanup that is no
The Komeda driver always expects the remote connector node to initialize
an encoder. It uses the component aggregator framework which consists
of component->bind() calls used to initialize the remote encoder and attach
it to the crtc. This makes it incompatible with connector drivers which
implemen
Am 11.07.23 um 16:49 schrieb Rob Clark:
On Tue, Jul 11, 2023 at 12:46 AM Christian König
wrote:
[SNIP]
---
drivers/gpu/drm/scheduler/sched_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_fence.c
b/drivers/gpu/drm/scheduler/sc
Am 11.07.23 um 16:47 schrieb Sam Ravnborg:
Hi Thomas,
On Tue, Jul 11, 2023 at 08:24:40AM +0200, Thomas Zimmermann wrote:
Hi Sam
Am 10.07.23 um 19:19 schrieb Sam Ravnborg:
Hi Thomas,
On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
Remove the unused flags FBINFO_DEFAULT a
Hi Liviu,
On 7/5/2023 10:44 PM, Liviu Dudau wrote:
> Hi Faiz,
>
> On Tue, Jul 04, 2023 at 10:04:54PM +0530, Faiz Abbas wrote:
>> The Komeda driver always expects the remote connector node to initialize
>> an encoder. It uses the component aggregator framework which consists
>> of component->bind(
Hi Sam,
On 7/4/2023 10:26 PM, Sam Ravnborg wrote:
> Hi Mohammed,
>
> On Tue, Jul 04, 2023 at 07:19:04PM +0530, Mohammad Faiz Abbas Rizvi wrote:
>> Hi Liviu,
>>
>> On 6/29/2023 3:21 PM, Liviu Dudau wrote:
>>> Hi Faiz,
>>>
>>> Thanks for the patch and for addressing what was at some moment on my "n
On 11.07.2023 14:45, Christian König wrote:
Am 11.07.23 um 12:34 schrieb Karolina Stolarek:
Test initialization and cleanup of the ttm_device struct, including
some error paths. Verify the creation of page pools if use_dma_alloc
param is true.
Signed-off-by: Karolina Stolarek
---
drivers/g
On Tue, Jul 11, 2023 at 11:33:25AM -0600, Jeffrey Hugo wrote:
> On 7/11/2023 2:20 AM, Dan Carpenter wrote:
> > Fixed in v4: Send the correct [PATCH 1/5] patch.
> >
> > Fixed in v3: Redo messed up threading
> >
> > Fixed two things in v2: Include the file. Change
> > the >= in encode and decode
Em Tue, 11 Jul 2023 20:45:18 -0700
Randy Dunlap escreveu:
> On 7/11/23 20:32, Akira Yokosawa wrote:
> > Hi Randy,
> >
> >> [just documenting this for posterity or in case someone wants to fix it.]
> >>
> >> In drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c, one can find both
> >>
> >> struct amdgpu_vm
On 12/07/2023 04:40, Manikandan Muralidharan wrote:
> Add new compatible string for the XLCD controller on sam9x75 variant
> of the SAM9X7 SoC family.
> The XLCD controller in sam9x75 variant supports interfacing with
> LVDS and MIPI-DSI and parallel port RGB.
Acked-by: Krzysztof Kozlowski
Best
On 11/07/2023 17:36, Alexandre Mergnat wrote:
> The Startek KD070FHFID015 is a 7-inch TFT LCD display with a resolution
> of 1024 x 600 pixels.
>
> Signed-off-by: Alexandre Mergnat
> ---
> .../display/panel/startek,kd070fhfid015.yaml | 51
> ++
> 1 file changed, 51 ins
On 7/11/23 20:32, Akira Yokosawa wrote:
> Hi Randy,
>
>> [just documenting this for posterity or in case someone wants to fix it.]
>>
>> In drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c, one can find both
>>
>> struct amdgpu_vm_tlb_seq_cb {...};
>>
>> and
>> static void amdgpu_vm_tlb_seq_cb(...)
>>
>>
Hi Randy,
> [just documenting this for posterity or in case someone wants to fix it.]
>
> In drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c, one can find both
>
> struct amdgpu_vm_tlb_seq_cb {...};
>
> and
> static void amdgpu_vm_tlb_seq_cb(...)
>
> Of course C has no problem with this, but kernel-doc
Hi Randy,
On Tue, 11 Jul 2023 19:26:33 -0700 Randy Dunlap wrote:
>
> On 7/11/23 16:15, Stephen Rothwell wrote:
> >
> > On Fri, 18 Nov 2022 17:55:45 +1100 Stephen Rothwell
> > wrote:
> >>
> >> After merging the amdgpu tree, today's linux-next build (htmldocs)
> >> produced these warnings:
> >
Add support for the following DPI mode if the encoder type
is DSI as per the XLCDC IP datasheet:
- 16BPPCFG1
- 16BPPCFG2
- 16BPPCFG3
- 18BPPCFG1
- 18BPPCFG2
- 24BPP
Signed-off-by: Manikandan Muralidharan
[durai.manicka...@microchip.com: update output format using is_xlcdc flag]
Signed-off-by: Dur
update the LCDC_HEOCFG30 and LCDC_HEOCFG31 registers of XLCDC IP which
supports vertical and horizontal scaling with Bilinear and Bicubic
co-efficients taps for Chroma and Luma componenets of the Pixel.
Signed-off-by: Manikandan Muralidharan
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2
Add support for Display Pixel Interface (DPI) Compatible Mode
support in atmel-hlcdc driver for XLCDC IP along with legacy
pixel mapping.DPI mode BIT is configured in LCDC_CFG5 register.
Signed-off-by: Manikandan Muralidharan
[durai.manicka...@microchip.com: update DPI mode bit using is_xlcdc fla
- XLCDC in SAM9X7 has different sets of registers and additional
configuration bits when compared to previous HLCDC IP. Read/write
operation on the controller registers is now separated using the
XLCDC status flag.
- HEO scaling, window resampling, Alpha blending, YUV-to-RGB
conversion in X
From: Durai Manickam KR
The register address of the XLCDC IP used in SAM9X7 SoC family
are different from the previous HLCDC.Defining those address
space with valid macros.
Signed-off-by: Durai Manickam KR
[manikanda...@microchip.com: Remove unused macro definitions]
Signed-off-by: Manikandan M
Add the LCD controller layer definition and descriptor structure for
sam9x75 for the following layers,
- Base Layer
- Overlay1 Layer
- Overlay2 Layer
- High End Overlay
Signed-off-by: Manikandan Muralidharan
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 97
1 file chang
Add new compatible string for the XLCD controller on sam9x75 variant
of the SAM9X7 SoC family.
The XLCD controller in sam9x75 variant supports interfacing with
LVDS and MIPI-DSI and parallel port RGB.
Signed-off-by: Manikandan Muralidharan
---
Documentation/devicetree/bindings/mfd/atmel-hlcdc.tx
Add is_xlcdc flag in driver data to differentiate XLCDC and HLCDC code
within the atmel-hlcdc driver files.
Signed-off-by: Manikandan Muralidharan
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
Add compatible for sam9x75 XLCD controller.
Signed-off-by: Manikandan Muralidharan
---
drivers/mfd/atmel-hlcdc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/atmel-hlcdc.c b/drivers/mfd/atmel-hlcdc.c
index 3c2414ba4b01..1daa7410468a 100644
--- a/drivers/mfd/atmel-hlcdc.c
+++ b
This patch series aims to add support for XLCDC IP of sam9x7 SoC family
to the DRM subsystem.XLCDC IP has additional registers and new
configuration bits compared to the existing register set of HLCDC IP.
The new compatible string "microchip,sam9x75-xlcdc" is defined for sam9x75
variant of the sam9
[just documenting this for posterity or in case someone wants to fix it.]
In drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c, one can find both
struct amdgpu_vm_tlb_seq_cb {...};
and
static void amdgpu_vm_tlb_seq_cb(...)
Of course C has no problem with this, but kernel-doc reports:
drivers/gpu/drm/amd/
On 7/11/23 16:15, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 18 Nov 2022 17:55:45 +1100 Stephen Rothwell
> wrote:
>>
>> After merging the amdgpu tree, today's linux-next build (htmldocs)
>> produced these warnings:
>>
>> drivers/gpu/drm/amd/display/dc/dc.h:548: warning: Function parameter
Quash 175 kernel-doc warnings in dc.h by unmarking 2 struct
comments as containing kernel-doc notation and by spelling one
struct field correctly in a kernel-doc comment.
Fixes: 1682bd1a6b5f ("drm/amd/display: Expand kernel doc for DC")
Fixes: ea76895ffab1 ("drm/amd/display: Document pipe split po
On 2023/7/11 17:33, Markus Elfring wrote:
virtio_gpu_get_vbuf always be successful,
so remove the error judgment.
How do you think about to improve this change description any more?
Hi,
virtio_gpu_get_vbuf use "__GFP_NOFAIL" flag to allocate memory, this
make sure
it won't fail, and virtio
Rename the intf's enable_compression() op to program_intf_cmd_cfg()
and allow it to accept a struct intf_cmd_mode_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.
changes in v5:
- rename struct intf_cmd_mode_cfg to dpu_hw
dpu_hw_intf has a few instances of structs which do not have
the dpu_hw prefix. Lets fix this by renaming those structs
and updating the usage of those accordingly.
Signed-off-by: Abhinav Kumar
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 18 +-
drivers/gpu/drm/msm/disp/d
Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced
with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS
from the catalog completely.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
drivers/gpu/drm
Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:
if (dpu_core_revision > x && dpu_core_re
Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version
instead by assigning the enable_compression op based on the
dpu core's major version.
To make this possible pass the struct dpu_mdss_version to
dpu_hw_intf_init().
This
With commit dac76a0144d31 ("fetch DPU configuration from match data"),
dpu core revision was dropped in favor of using the compatible string
from the device tree to select the dpu catalog being used in the device.
This approach works well however also necessitates adding catalog
entries for small
On 2023/7/11 19:13, Dan Carpenter wrote:
On Tue, Jul 11, 2023 at 05:00:31PM +0800, Su Hui wrote:
virtio_gpu_get_vbuf always be successful,
so remove the error judgment.
No, just ignore the static checker false positive in this case. The
intent of the code is clear that if it did have an error
On 7/11/23 10:31, Christian König wrote:
Exercise at least all driver facing functions of this new component.
v2: add array test as well
v3: some kunit cleanups
v4: more tests and cleanups
Signed-off-by: Christian König
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/test
On 7/11/2023 5:42 PM, Dmitry Baryshkov wrote:
On 12/07/2023 03:33, Abhinav Kumar wrote:
Rename the intf's enable_compression() op to program_intf_cmd_cfg()
and allow it to accept a struct intf_cmd_mode_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it
On 12/07/2023 03:33, Abhinav Kumar wrote:
Rename the intf's enable_compression() op to program_intf_cmd_cfg()
and allow it to accept a struct intf_cmd_mode_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.
Signed-off-by: Abhinav
On 7/4/2023 12:01 PM, Abhinav Kumar wrote:
On 7/4/2023 10:28 AM, Dmitry Baryshkov wrote:
On Tue, 4 Jul 2023 at 19:10, Abhinav Kumar
wrote:
On 7/4/2023 4:52 AM, Dmitry Baryshkov wrote:
On Tue, 4 Jul 2023 at 13:06, Dmitry Baryshkov
wrote:
On Tue, 4 Jul 2023 at 07:04, Abhinav Kumar
On 12/07/2023 03:33, Abhinav Kumar wrote:
Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version
instead by assigning the enable_compression op based on the
dpu core's major version.
To make this possible pass the struct dp
On 12/07/2023 03:33, Abhinav Kumar wrote:
Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:
Rename the intf's enable_compression() op to program_intf_cmd_cfg()
and allow it to accept a struct intf_cmd_mode_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/d
Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced
with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS
from the catalog completely.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
drivers/gpu/drm
Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version
instead by assigning the enable_compression op based on the
dpu core's major version.
To make this possible pass the struct dpu_mdss_version to
dpu_hw_intf_init().
This
Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:
if (dpu_core_revision > x && dpu_core_re
With commit dac76a0144d31 ("fetch DPU configuration from match data"),
dpu core revision was dropped in favor of using the compatible string
from the device tree to select the dpu catalog being used in the device.
This approach works well however also necessitates adding catalog
entries for small
On Tue, Jul 11, 2023 at 11:39:17AM -1000, Tejun Heo wrote:
> On Tue, Jul 11, 2023 at 04:06:22PM +0200, Geert Uytterhoeven wrote:
> > On Tue, Jul 11, 2023 at 3:55 PM Geert Uytterhoeven
> > wrote:
...
> > workqueue: neigh_managed_work hogged CPU for >1us 4 times,
> > consider switching to WQ_UN
On 7/3/2023 12:42 AM, Pekka Paalanen wrote:
On Fri, 30 Jun 2023 11:26:49 +0300
Pekka Paalanen wrote:
On Thu, 29 Jun 2023 17:25:06 -0700
Jessica Zhang wrote:
Drop DPU_PLANE_COLOR_FILL_FLAG and check the DRM solid_fill property to
determine if the plane is solid fill. In addition drop the
On 12/07/2023 02:04, Konrad Dybcio wrote:
On 12.07.2023 01:01, Dmitry Baryshkov wrote:
On Wed, 12 Jul 2023 at 01:59, Konrad Dybcio wrote:
On 12.07.2023 00:39, Dmitry Baryshkov wrote:
On 12/07/2023 00:36, Konrad Dybcio wrote:
On 9.07.2023 06:19, Dmitry Baryshkov wrote:
Add the nb7vpq904m, o
Hi all,
On Thu, 30 Mar 2023 07:28:26 -0700 Rob Clark wrote:
>
> On Wed, Mar 29, 2023 at 8:28 PM Stephen Rothwell
> wrote:
> >
> > After merging the drm tree, today's linux-next build (htmldocs) produced
> > this warning:
> >
> > include/uapi/linux/sync_file.h:77: warning: Function parameter or
On 11/07/2023 15:22, Aurabindo Pillai wrote:
> [...]
> Hi,
>
> Sorry for the delayed response, this patch went unnoticed. This revert would
> break asics. Could you try the attached patch without reverting this one ?
Hi Aurabindo, thanks for your response!
I've tried kernel 6.5-rc1, and it seem
Hi all,
On Fri, 18 Nov 2022 17:55:45 +1100 Stephen Rothwell
wrote:
>
> After merging the amdgpu tree, today's linux-next build (htmldocs)
> produced these warnings:
>
> drivers/gpu/drm/amd/display/dc/dc.h:548: warning: Function parameter or
> member 'dispclk_khz' not described in 'dc_clocks'
>
Hi all,
On Wed, 26 Oct 2022 12:14:28 +1100 Stephen Rothwell
wrote:
>
> After merging the amdgpu tree, today's linux-next build (htmldocs)
> produced this warning:
>
> drivers/gpu/drm/amd/display/dc/dc.h:1289: warning: Function parameter or
> member 'plane_states' not described in 'dc_validatio
Hi all,
[This consolidates a while lot of warnings I have reported over the past
year ... these are now produced whe building Linus' tree]
After merging the amdgpu tree, today's linux-next build (htmldocs)
produced these warnings:
drivers/gpu/drm/amd/display/dc/dc.h:905: warning: Function parame
On 12.07.2023 01:01, Dmitry Baryshkov wrote:
> On Wed, 12 Jul 2023 at 01:59, Konrad Dybcio wrote:
>>
>> On 12.07.2023 00:39, Dmitry Baryshkov wrote:
>>> On 12/07/2023 00:36, Konrad Dybcio wrote:
On 9.07.2023 06:19, Dmitry Baryshkov wrote:
> Add the nb7vpq904m, onboard USB-C redriver / ret
On Wed, 12 Jul 2023 at 01:59, Konrad Dybcio wrote:
>
> On 12.07.2023 00:39, Dmitry Baryshkov wrote:
> > On 12/07/2023 00:36, Konrad Dybcio wrote:
> >> On 9.07.2023 06:19, Dmitry Baryshkov wrote:
> >>> Add the nb7vpq904m, onboard USB-C redriver / retimer.
> >>>
> >>> Signed-off-by: Dmitry Baryshkov
On Wed, 12 Jul 2023 at 01:42, Abhinav Kumar wrote:
>
>
>
> On 7/11/2023 3:19 PM, Dmitry Baryshkov wrote:
> > On 12/07/2023 01:07, Jessica Zhang wrote:
> >>
> >>
> >> On 7/10/2023 1:11 PM, Dmitry Baryshkov wrote:
> >>> On 10/07/2023 22:51, Jessica Zhang wrote:
>
>
> On 6/30/2023 1:27
On 12.07.2023 00:39, Dmitry Baryshkov wrote:
> On 12/07/2023 00:36, Konrad Dybcio wrote:
>> On 9.07.2023 06:19, Dmitry Baryshkov wrote:
>>> Add the nb7vpq904m, onboard USB-C redriver / retimer.
>>>
>>> Signed-off-by: Dmitry Baryshkov
>>> ---
>> [...]
>>
>>> + port@1 {
>>> +
On 7/11/2023 3:19 PM, Dmitry Baryshkov wrote:
On 12/07/2023 01:07, Jessica Zhang wrote:
On 7/10/2023 1:11 PM, Dmitry Baryshkov wrote:
On 10/07/2023 22:51, Jessica Zhang wrote:
On 6/30/2023 1:27 AM, Pekka Paalanen wrote:
On Fri, 30 Jun 2023 03:42:28 +0300
Dmitry Baryshkov wrote:
On 3
On 12/07/2023 00:36, Konrad Dybcio wrote:
On 9.07.2023 06:19, Dmitry Baryshkov wrote:
Add the nb7vpq904m, onboard USB-C redriver / retimer.
Signed-off-by: Dmitry Baryshkov
---
[...]
+ port@1 {
+ reg = <1>;
+
+
On 12/07/2023 00:34, Konrad Dybcio wrote:
On 9.07.2023 06:19, Dmitry Baryshkov wrote:
Declare the displayport controller present on the Qualcomm SM8250 SoC.
Signed-off-by: Dmitry Baryshkov
---
[...]
+ dp_opp_table: opp-table {
+
On 12/07/2023 01:07, Jessica Zhang wrote:
On 7/10/2023 1:11 PM, Dmitry Baryshkov wrote:
On 10/07/2023 22:51, Jessica Zhang wrote:
On 6/30/2023 1:27 AM, Pekka Paalanen wrote:
On Fri, 30 Jun 2023 03:42:28 +0300
Dmitry Baryshkov wrote:
On 30/06/2023 03:25, Jessica Zhang wrote:
Add support
On 7/10/2023 1:11 PM, Dmitry Baryshkov wrote:
On 10/07/2023 22:51, Jessica Zhang wrote:
On 6/30/2023 1:27 AM, Pekka Paalanen wrote:
On Fri, 30 Jun 2023 03:42:28 +0300
Dmitry Baryshkov wrote:
On 30/06/2023 03:25, Jessica Zhang wrote:
Add support for pixel_source property to drm_plane an
On Tue, 2023-07-11 at 11:49 -0700, Ceraolo Spurio, Daniele wrote:
>
> > > > @@ -134,6 +193,8 @@ static int __run_selftests(const char *name,
> > > >{
> > > > int err = 0;
> > > >
> > > > + __wait_on_all_system_dependencies(data);
> > > Why does this need to be top level selft
On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.
That said, all subsytems th
On 7/11/2023 12:42 AM, Pekka Paalanen wrote:
On Mon, 10 Jul 2023 16:12:06 -0700
Jessica Zhang wrote:
On 6/30/2023 1:27 AM, Pekka Paalanen wrote:
On Thu, 29 Jun 2023 17:25:00 -0700
Jessica Zhang wrote:
Document and add support for solid_fill property to drm_plane. In
addition, add sup
Hello,
On Tue, Jul 11, 2023 at 04:06:22PM +0200, Geert Uytterhoeven wrote:
> On Tue, Jul 11, 2023 at 3:55 PM Geert Uytterhoeven
> wrote:
> >
> > Hi Tejun,
> >
> > On Fri, May 12, 2023 at 9:54 PM Tejun Heo wrote:
> > > Workqueue now automatically marks per-cpu work items that hog CPU for too
> >
On 9.07.2023 06:19, Dmitry Baryshkov wrote:
> Add the nb7vpq904m, onboard USB-C redriver / retimer.
>
> Signed-off-by: Dmitry Baryshkov
> ---
[...]
> + port@1 {
> + reg = <1>;
> +
> + redriver_phy_con_ss: endpoint {
> +
Even if there's nothing currently parsing amdgpu's coredump files, if
we eventually have such tools they will be glad to find a version field
to properly read the file.
Create a version number to be displayed on top of coredump file, to be
incremented when the file format or content get changed.
If a kernel thread caused the reset, the information available to be
logged will be limited, so return early in the dump function.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
Log the IB addresses used by the hung job along with the stuck ring
name. Note that due to nested IBs, the one that caused the reset itself
may be in not listed address.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_device
Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it dynamically. This
will make it easier to further expand the logged information.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 +++--
driver
Hi,
The goal of this patchset is to improve debugging device resets on amdgpu.
The first patch creates a new module parameter to disable soft recoveries,
ensuring every recovery go through the full device reset, making easier to
generate resets from userspace tools like [0] and [1]. This is impor
If a DRM fence is set to -ENODATA, that means that this context was a
cause of a soft reset, but is never marked as guilty. Flag it as guilty
and log to user that this context won't accept more submissions.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 6 ++
1 fi
Create a module parameter to disable soft recoveries on amdgpu, making
every recovery go through the device reset path. This option makes
easier to force device resets for testing and debugging purposes.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu
On 9.07.2023 06:19, Dmitry Baryshkov wrote:
> Declare the displayport controller present on the Qualcomm SM8250 SoC.
>
> Signed-off-by: Dmitry Baryshkov
> ---
[...]
> + dp_opp_table: opp-table {
> + compatible = "operating-points-v2
Due to a change in the auth flow on MTL, GuC 70.7.0 and newer will only
be able to authenticate HuC 8.5.1 and newer. The plan is to update the 2
binaries sinchronously in linux-firmware so that the fw repo always has
a matching pair that works; still, it's better to check in the kernel so
we can pr
@@ -134,6 +193,8 @@ static int __run_selftests(const char *name,
{
int err = 0;
+ __wait_on_all_system_dependencies(data);
Why does this need to be top level selftests and not just a wait for
intel_gsc_uc_fw_proxy_init_done in the tests where it is relevant, via
some helper or so
On Tue, Jul 11, 2023 at 05:36:27PM +0200, Alexandre Mergnat wrote:
> The Startek KD070FHFID015 is a 7-inch TFT LCD display with a resolution
> of 1024 x 600 pixels.
>
> Signed-off-by: Alexandre Mergnat
> ---
> .../display/panel/startek,kd070fhfid015.yaml | 51
> ++
> 1
On 7/2/23 12:44, Guilherme G. Piccoli wrote:
> This reverts commit 06c3a652a787efc960af7c8816036d25c4227c6c.
>
> After this commit, the Steam Deck cannot boot with graphics anymore;
> the following message is observed on dmesg:
>
> "[drm] ERROR [CRTC:67:crtc-0] flip_done timed out"
>
> No othe
Thanks fore reviewing Tvrtko, below are my responses.
I'll rerev without generalized func ptr and only for the subtests that need it.
...alan
On Thu, 2023-06-29 at 22:44 +0100, Tvrtko Ursulin wrote:
> On 29/06/2023 21:42, Alan Previn wrote:
> > On MTL, if the GSC Proxy init flows haven't completed
From: Rob Clark
The incorrect size was causing "CP | AHB bus error" when snapshotting
the GPU state on a6xx gen4 (a660 family).
Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/26
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 2 +-
1 file changed, 1 insertio
On 7/11/2023 2:20 AM, Dan Carpenter wrote:
Fixed in v4: Send the correct [PATCH 1/5] patch.
Fixed in v3: Redo messed up threading
Fixed two things in v2: Include the file. Change
the >= in encode and decode to >.
regards,
dan carpenter
Did you intentionally drop tags from previous version
On 7/10/2023 2:10 AM, Thomas Zimmermann wrote:
Generate a hotplug event after registering a client to allow the
client to configure its display. Remove the hotplug calls from the
existing clients for fbdev emulation. This change fixes a concurrency
bug between registering a client and receivin
On Tue, Jul 11, 2023 at 9:31 AM Christian König
wrote:
>
> Hi Alex,
>
> so apart from some RADV semaphore issue which seems to be unrelated to
> this changes our CI systems are happy with the changes.
>
> Can I get some ack to push them through drm-misc-next?
For the series:
Acked-by: Alex Deuche
On Tue, Jul 11, 2023 at 9:46 AM Helge Deller wrote:
>
> On 7/11/23 08:00, Thomas Zimmermann wrote:
> >
> >
> > Am 10.07.23 um 19:40 schrieb Rob Herring:
> >> Since commit 241d2fb56a18 ("of: Make OF framebuffer device names unique"),
> >> as spotted by Frédéric Bonnard, the historical "of-display"
From: Sui Jingfeng
This patch add a function to identify if a device is the default boot
selected by the firmware, it require the GPU has firmware framebuffer
driver support (such as efifb). If a specific hardware doesn't have
firmware framebuffer support, then the introduced function will just
r
From: Sui Jingfeng
[why]
The vga_is_firmware_default() function defined in drivers/pci/vgaarb.c is
arch-dependent, it's no-op on non-x86 architectures. The arbitration is
not usabe on non-x86 platform.
[how]
The device that owns the firmware framebuffer should be the default boot
device. This
From: Sui Jingfeng
[why]
The vga_is_firmware_default() function defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures. This made VGAARB
lost an important condition for the arbitration on non-x86 platform. The
rules about which GPU is (or should be) the primary
From: Sui Jingfeng
Becasuse the VGA Display Controller in the ASpeed BMC chip is also a PCIe
device, the Software Programming guide of AST2400 say that it is Fully
IBM VGA compliant, thus, it should also particiate in the arbitration.
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Cc: David Airlie
From: Sui Jingfeng
The observation behind this is that we should avoid accessing the global
screen_info directly. Call the aperture_contain_firmware_fb_nonreloc()
function to implement the detection of whether an aperture contains the
firmware FB.
This patch helps to decouple the determination f
From: Sui Jingfeng
Currently, the strategy of selecting the default boot on a multiple video
card coexistence system is not perfect. Potential problems are:
1) This function is a no-op on non-x86 architectures.
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not ef
From: Sui Jingfeng
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/loongson/lsdc_drv.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/loongson/lsdc_drv.c
b/drivers/gpu/drm/loongson/lsdc_drv.c
index d10a28c2c494..92ef07d6a534 100644
--- a/drivers/g
From: Sui Jingfeng
This patch is intended to form a uniform approach to determining if an
unmoved aperture contains the firmware FB. I believe that the global
screen_info is more about video-specific things.
Putting it in video/aperture.c helps form a uniform approach.
Cc: Thomas Zimmermann
Cc
From: Sui Jingfeng
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately, due to the fact that the apertures list
will be freed dynamically, the location and size information of the
firmware FB will be lost after dedicated drivers call
aperture_remove_
From: Sui Jingfeng
Currently, the default VGA device selection is not perfect. Potential
problems are:
1) This function is a no-op on non-x86 architectures.
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not effective for the PCI device without a dedicated VRAM Ba
On Tue, 27 Jun 2023 16:43:15 +0200, Julia Lawall wrote:
> The functions vmalloc_array and vcalloc were introduced in
>
> commit a8749a35c399 ("mm: vmalloc: introduce array allocation functions")
>
> but are not used much yet. This series introduces uses of
> these functions, to protect against
From: Sui Jingfeng
[why]
The vga_is_firmware_default() function defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures. This made VGAARB
lost an important condition for the arbitration on non-x86 platform. The
rules about which GPU is (or should be) the primary
From: Sui Jingfeng
Currently, the strategy of selecting the default boot on a multiple video
card coexistence system is not perfect. Potential problems are:
1) This function is a no-op on non-x86 architectures.
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not ef
1 - 100 of 222 matches
Mail list logo
