On Tue, 23 Jan 2024, Lucas De Marchi wrote:
> From: Yury Norov
>
> Generalize __GENMASK() to support different types, and implement
> fixed-types versions of GENMASK() based on it. The fixed-type version
> allows more strict checks to the min/max values accepted, which is
> useful for defining
Am 24.01.24 um 03:43 schrieb Zhou, Xianrong:
[AMD Official Use Only - General]
The vmf_insert_pfn_prot could cause unnecessary double faults on a
device pfn. Because currently the vmf_insert_pfn_prot does not make
the pfn writable so the pte entry is normally read-only or dirty
catching.
Am 24.01.24 um 05:14 schrieb Zeng, Oak:
Danilo,
Maybe before I give up, I should also ask, currently drm_gpuvm is designed for
BO-centric world. Is it easy to make the va range split/merge work simply for
va range, but without BO? Conceptually this should work as we are
merge/splitting
Hi Conor & All,
On 22/01/24 2:46 pm, Conor Dooley wrote:
> On Mon, Jan 22, 2024 at 03:38:41AM +,dharm...@microchip.com wrote:
>> Hi Conor,
>> On 19/01/24 5:33 pm, Conor Dooley - M52691 wrote:
>>> On Fri, Jan 19, 2024 at 03:32:49AM +,dharm...@microchip.com wrote:
On 18/01/24 9:10
Now that include/linux/bits.h implements fixed-width GENMASK_*, use them
to implement the i915/xe specific macros. Converting each driver to use
the generic macros are left for later, when/if other driver-specific
macros are also generalized.
Signed-off-by: Lucas De Marchi
---
Move the implementation of REG_GENMASK/REG_BIT to a more appropriate
place to be shared by i915, xe and possibly other parts of the kernel.
For now this re-defines the old macros. In future we may start using the
new macros directly, but that's a more intrusive search-and-replace.
Yury, I added
From: Yury Norov
Generalize __GENMASK() to support different types, and implement
fixed-types versions of GENMASK() based on it. The fixed-type version
allows more strict checks to the min/max values accepted, which is
useful for defining registers like implemented by i915 and xe drivers
with
Implement fixed-type BIT() to help drivers add stricter checks, like was
done for GENMASK.
Signed-off-by: Lucas De Marchi
---
include/linux/bits.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/bits.h b/include/linux/bits.h
index cb94128171b2..5754a1251078 100644
---
Danilo,
Maybe before I give up, I should also ask, currently drm_gpuvm is designed for
BO-centric world. Is it easy to make the va range split/merge work simply for
va range, but without BO? Conceptually this should work as we are
merge/splitting virtual address range which can be decoupled
On Tue, Jan 23, 2024 at 07:55:38PM -0800, Matt Roper wrote:
On Mon, Jan 22, 2024 at 07:12:42PM -0800, Lucas De Marchi wrote:
Since the PCI IDs for PVC were added to the xe driver, the xe_wa tests
This first line doesn't seem to be worded right. I think you meant
either "weren't added" or
Thanks a lot Danilo.
Maybe I wasn't clear enough. In the solution I proposed, each device still have
separate vm/page tables. Each device still need to manage the mapping, page
table flags etc. It is just in svm use case, all devices share one drm_gpuvm
instance. As I understand it,
On Mon, Jan 22, 2024 at 07:12:42PM -0800, Lucas De Marchi wrote:
> Since the PCI IDs for PVC were added to the xe driver, the xe_wa tests
This first line doesn't seem to be worded right. I think you meant
either "weren't added" or "were only added to topic/xe-for-CI."
Assuming you can reword
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 774551425799cb5bbac94e1768fd69eec4f78dd4 Add linux-next specific
files for 20240123
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202401231518.8q9ld8n7-...@intel.com
https
Some debug messages carried the ip name, or included "lima", or
included both the ip name and then the numbered ip name again.
Make the messages more consistent by always looking up and showing
the ip name first.
Signed-off-by: Erico Nunes
---
drivers/gpu/drm/lima/lima_gp.c | 20
There are several unexplained and unreproduced cases of rendering
timeouts with lima, for which one theory is high IRQ latency coming from
somewhere else in the system.
This kind of occurrence may cause applications to trigger unnecessary
resets of the GPU or even applications to hang if it hits
The previous 500ms default timeout was fairly optimistic and could be
hit by real world applications. Many distributions targeting devices
with a Mali-4xx already bumped this timeout to a higher limit.
We can be generous here with a high value as 10s since this should
mostly catch buggy jobs like
This is required for reliable hard resets. Otherwise, doing a hard reset
while a task is still running (such as a task which is being stopped by
the drm_sched timeout handler) may result in random mmu write timeouts
or lockups which cause the entire gpu to hang.
Signed-off-by: Erico Nunes
---
Lima gp jobs use an async reset to avoid having to wait for the soft
reset right after a job. The soft reset is done at the end of a job and
a reset_complete flag is expected to be set at the next job.
However, in case the user runs into a job timeout from any application,
a hard reset is issued
Marking the context as guilty currently only makes the application which
hits a single timeout problem to stop its rendering context entirely.
All jobs submitted later are dropped from the guilty context.
Lima runs on fairly underpowered hardware for modern standards and it is
not entirely
This is required for reliable hard resets. Otherwise, doing a hard reset
while a task is still running (such as a task which is being stopped by
the drm_sched timeout handler) may result in random mmu write timeouts
or lockups which cause the entire gpu to hang.
Signed-off-by: Erico Nunes
v1 reference:
https://patchwork.kernel.org/project/dri-devel/cover/20240117031212.1104034-1-nunes.er...@gmail.com/
Changes v1 -> v2:
- Dropped patch 1 which aimed to fix
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8415 .
That will require more testing and an actual fix to the irq/timeout
Lima pp jobs use an async reset to avoid having to wait for the soft
reset right after a job. The soft reset is done at the end of a job and
a reset_complete flag is expected to be set at the next job.
However, in case the user runs into a job timeout from any application,
a hard reset is issued
Hi, Javier and Thomas,
On Wed, Jan 24, 2024 at 5:21 AM Jaak Ristioja wrote:
>
> Hi,
>
> I apologize for not finding the time to test this earlier.
>
> On 11.12.23 05:08, Huacai Chen wrote:
> > And Jaak, could you please test with the below patch (but keep the
> > original order in Makefile) and
ZynqMP DPSUB supports 2 modes of operations in regard to video data
input.
In the first mode, DPSUB uses DMA engine to pull video data from memory
buffers. To support this the driver implements CRTC and DRM bridge
representing DP encoder.
In the second mode, DPSUB acquires video data pushed from
Clear status register as soon as we read it.
Addressing comments from
https://lore.kernel.org/dri-devel/beb551c7-bb7e-4cd0-b166-e9aad90c4...@ideasonboard.com/
Signed-off-by: Anatoliy Klymenko
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Expect external video timing in live video input mode, program
DPSUB acordingly.
Reviewed-by: Tomi Valkeinen
Signed-off-by: Anatoliy Klymenko
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
Add few missing pieces to support ZynqMP DPSUB live video in mode.
ZynqMP DPSUB supports 2 modes of operations in regard to video data
input.
In the first mode, DPSUB uses DMA engine to pull video data from memory
buffers. To support this the driver implements CRTC and DRM bridge
ZynqMP DPSUB supports 2 input modes: DMA based and live video.
In the first mode, the driver implements CRTC and DP encoder DRM bridge
to model the complete display pipeline. In this case, DRM bridge is
being directly instantiated within the driver, not using any bridge
discovery mechanisms.
In
Filter out status register against the interrupts' mask.
Some events are being reported via DP status register, even if
corresponding interrupts have been disabled. One instance of such event
leads to generation of VBLANK when the driver is in DRM bridge mode,
which in turn results in NULL
[AMD Official Use Only - General]
> >>> The vmf_insert_pfn_prot could cause unnecessary double faults on a
> >>> device pfn. Because currently the vmf_insert_pfn_prot does not make
> >>> the pfn writable so the pte entry is normally read-only or dirty
> >>> catching.
> >> What? How do you got to
On Wed, 17 Jan 2024 at 00:31, Jessica Zhang wrote:
>
> Add a driver for simulating panels. This module also supports a mode
> parameter for users to specify a custom mode. If no custom mode is set,
> it will fall back to a custom, hard-coded mode.
>
> Signed-off-by: Jessica Zhang
> ---
>
Change mediatek,gce-events property to reference mediatek,gce-props.yaml
instead of defining itself.
Signed-off-by: Jason-JH.Lin
Reviewed-by: Conor Dooley
---
.../bindings/soc/mediatek/mediatek,ccorr.yaml| 12
.../bindings/soc/mediatek/mediatek,mutex.yaml| 11
Change mediatek,gce-events property to reference mediatek,gce-props.yaml
instead of defining itself.
Signed-off-by: Jason-JH.Lin
Reviewed-by: Conor Dooley
---
.../bindings/media/mediatek,mdp3-rdma.yaml | 11 +++
.../devicetree/bindings/media/mediatek,mdp3-rsz.yaml | 12
From: Jason-jh Lin
The property "mediatek,gce-events" is used for GCE event ID corresponding
to a hardware event signal sent by the hardware or a software driver.
If the mailbox providers or consumers want to manipulate the value of
the event ID, they need to know the specific event ID.
Since
Add mediatek,gce-props.yaml for common GCE properties that is used for
both mailbox providers and consumers. We place the common property
"mediatek,gce-events" in this binding currently.
The property "mediatek,gce-events" is used for GCE event ID corresponding
to a hardware event signal sent by
On Wed, Jan 24, 2024 at 7:19 AM Erico Nunes wrote:
>
> On Fri, Jan 19, 2024 at 2:50 AM Qiang Yu wrote:
> >
> > On Thu, Jan 18, 2024 at 7:14 PM Erico Nunes wrote:
> > >
> > > On Thu, Jan 18, 2024 at 2:36 AM Qiang Yu wrote:
> > > >
> > > > So this is caused by same job trigger both done and
Hi Oak,
On 1/23/24 20:37, Zeng, Oak wrote:
Thanks Christian. I have some comment inline below.
Danilo, can you also take a look and give your feedback? Thanks.
I agree with everything Christian already wrote. Except for the KFD parts, which
I'm simply not familiar with, I had exactly the
On Fri, Jan 19, 2024 at 2:50 AM Qiang Yu wrote:
>
> On Thu, Jan 18, 2024 at 7:14 PM Erico Nunes wrote:
> >
> > On Thu, Jan 18, 2024 at 2:36 AM Qiang Yu wrote:
> > >
> > > So this is caused by same job trigger both done and timeout handling?
> > > I think a better way to solve this is to make
On Tue, Jan 23, 2024 at 03:48:01PM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 23, 2024 at 08:44:04PM +, Sakari Ailus wrote:
> > On Tue, Jan 23, 2024 at 11:24:23AM -0600, Bjorn Helgaas wrote:
> > ...
>
> > > - I don't know whether it's feasible, but it would be nice if the
> > >
On Tue, Jan 23, 2024 at 11:51:15AM +0100, Janusz Krzysztofik wrote:
> Hi Rodrigo,
>
> Thank you for review.
>
> On Monday, 22 January 2024 22:09:38 CET Rodrigo Vivi wrote:
> > On Mon, Jan 22, 2024 at 03:04:42PM +0100, Janusz Krzysztofik wrote:
> > > Object debugging tools were sporadically
On 12/25/2023 5:08 AM, Dmitry Baryshkov wrote:
dpu_encoder_phys_wb is the only user of encoder's atomic_check callback.
Move corresponding checks to drm_writeback_connector's implementation
and drop the dpu_encoder_phys_wb_atomic_check() function.
Signed-off-by: Dmitry Baryshkov
---
Currently this driver creates a SGT table using the CPU as the
target device, then performs the dma_sync operations against
that SGT. This is backwards to how DMA-BUFs are supposed to behave.
This may have worked for the case where these buffers were given
only back to the same CPU that produced
Now that we do not need to call dma_coerce_mask_and_coherent() on our
miscdevice device, use the module_misc_device() helper for registering
and module init/exit.
Signed-off-by: Andrew Davis
---
drivers/dma-buf/udmabuf.c | 30 +-
1 file changed, 1 insertion(+), 29
When a device attaches to and maps our buffer we need to keep track
of this mapping/device. This is needed for synchronization with these
devices when beginning and ending CPU access for instance. Add a list
that tracks device mappings as part of {map,unmap}_udmabuf().
Signed-off-by: Andrew Davis
On 1/22/24 18:29, Stephen Rothwell wrote:
> Hi all,
>
> News: there will be no linux-next release on Friday
>
> Changes since 20240122:
>
on ARM64, when
DRM_I915 is not set
DRM_XE=m
DEBUG_FS is not set
../drivers/gpu/drm/i915/display/intel_display_debugfs.c:1091:6: error:
redefinition of
On Tue, Jan 23, 2024 at 08:44:04PM +, Sakari Ailus wrote:
> On Tue, Jan 23, 2024 at 11:24:23AM -0600, Bjorn Helgaas wrote:
> ...
> > - I don't know whether it's feasible, but it would be nice if the
> > intel_pm_runtime_pm.c rework could be done in one shot instead of
> > being split
Vegard Nossum writes:
> This comment about DRM drivers has been there since the first git
> commit. It simply doesn't belong in kernel-parameters; remove it.
>
> Signed-off-by: Vegard Nossum
> ---
> Documentation/admin-guide/kernel-parameters.rst | 5 -
> 1 file changed, 5 deletions(-)
>
>
Hu Haowen <2023002...@link.tyut.edu.cn> writes:
> Since the mailing archive list lkml.org is obsolete, change the links into
> lore.kernel.org's ones.
>
> Signed-off-by: Hu Haowen <2023002...@link.tyut.edu.cn>
> ---
> Documentation/accel/introduction.rst | 4 ++--
> 1 file changed, 2
Hi,
I apologize for not finding the time to test this earlier.
On 11.12.23 05:08, Huacai Chen wrote:
And Jaak, could you please test with the below patch (but keep the
original order in Makefile) and then give me the dmesg output?
diff --git a/drivers/video/aperture.c
On 2024-01-23 5:21, Dan Carpenter wrote:
Hello Felix Kuehling,
The patch 1819200166ce: "drm/amdkfd: Export DMABufs from KFD using
GEM handles" from Aug 24, 2023 (linux-next), leads to the following
Smatch static checker warning:
drivers/dma-buf/dma-buf.c:729 dma_buf_get()
warn:
Hi Bjorn,
Thanks for the review.
On Tue, Jan 23, 2024 at 11:24:23AM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 23, 2024 at 11:56:42AM +0200, Sakari Ailus wrote:
> > There are two ways to opportunistically increment a device's runtime PM
> > usage count, calling either pm_runtime_get_if_active()
On 2024-01-23 13:02, Xaver Hugl wrote:
> Am Mo., 22. Jan. 2024 um 16:50 Uhr schrieb Harry Wentland
> :
>>
>>
>>
>> On 2024-01-19 13:25, Ville Syrjälä wrote:
>>> On Fri, Jan 19, 2024 at 03:12:35PM -0300, André Almeida wrote:
AMD GPUs can do async flips with changes on more properties than
On 2024-01-23 14:37, Zeng, Oak wrote:
Thanks Christian. I have some comment inline below.
Danilo, can you also take a look and give your feedback? Thanks.
Sorry, just catching up with this thread now. I'm also not familiar with
drm_gpuvm.
Some general observations based on my experience
There are no more users of the ->get_edid callback left. They've all
been converted to ->edid_read. Remove the callback, and the fallback in
drm_bridge_edid_read().
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_bridge.c | 19 ---
include/drm/drm_bridge.h | 30
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/tc358767.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index
If EDID read fails, clear the EDID property and CEC address.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index
The EDID property should be updated between reading the EDID and adding
the modes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/tc358767.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index
Prefer using the struct drm_edid based callback and functions.
v2: Fix -Wuninitialized (kernel test robot)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 43 ++-
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 47 +---
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
Remove the excess leading tabs.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/mediatek/mtk_dp.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/sii902x.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
Use the pre-parsed information instead of parsing EDID again.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/sii902x.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index
Prefer using the struct drm_edid based callback and functions.
v2: Fix -Wsometimes-uninitialized (kernel test robot)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
.../bridge/megachips-stdp-ge-b850v3-fw.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/ite-it66121.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c
b/drivers/gpu/drm/bridge/ite-it66121.c
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/ite-it6505.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c
b/drivers/gpu/drm/bridge/ite-it6505.c
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/display-connector.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
If EDID read fails, clear the EDID property.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
Prefer using the struct drm_edid based callback and functions.
Signed-off-by: Jani Nikula
---
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 26 +--
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
Prefer using the struct drm_edid based callback.
v2: Fix build (goto out;)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 30 ---
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
All users of drm_bridge_get_edid() have been converted to use
drm_bridge_edid_read(). Remove drm_bridge_get_edid().
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_bridge.c | 28 ++--
include/drm/drm_bridge.h | 2 --
2 files changed, 2 insertions(+), 28
Prefer using the struct drm_edid based functions.
Not ideal, should use source physical address from connector info.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/meson/meson_encoder_hdmi.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git
If EDID read fails, clear the EDID property.
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/ti-tfp410.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Prefer using the struct drm_edid based functions.
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/ti-tfp410.c | 16
1 file changed, 8 insertions(+), 8
If EDID read fails, clear the EDID property.
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/simple-bridge.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Prefer using the struct drm_edid based functions.
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/simple-bridge.c | 16
1 file changed, 8 insertions(+), 8
Prefer using the struct drm_edid based functions.
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 10 +-
1 file changed, 5 insertions(+), 5
Prefer using the struct drm_edid based functions.
Cc: Adrien Grassein
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 8
1 file changed, 4
If EDID read fails, clear the EDID property.
Cc: Adrien Grassein
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 2 +-
1 file changed, 1 insertion(+),
Prefer using the struct drm_edid based functions.
cc: Adrien Grassein
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 12 ++--
1 file changed,
Prefer using the struct drm_edid based functions.
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/bridge/chrontel-ch7033.c | 12 ++--
1 file changed, 6 insertions(+), 6
Add new struct drm_edid based ->edid_read hook and
drm_bridge_edid_read() function to call the hook.
v2: Include drm/drm_edid.h
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_bridge.c | 46 +++-
include/drm/drm_bridge.h | 33 ++
2
Prefer using the struct drm_edid based functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_bridge_connector.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge_connector.c
b/drivers/gpu/drm/drm_bridge_connector.c
index
v3 of [1] with a couple of patches fixed.
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/128149/
Jani Nikula (39):
drm/bridge: add ->edid_read hook and drm_bridge_edid_read()
drm/bridge: switch to drm_bridge_read_edid()
drm/bridge: chrontel-ch7033: switch to
Thanks Christian. I have some comment inline below.
Danilo, can you also take a look and give your feedback? Thanks.
> -Original Message-
> From: Christian König
> Sent: Tuesday, January 23, 2024 6:13 AM
> To: Zeng, Oak ; Danilo Krummrich ;
> Dave Airlie ; Daniel Vetter
> Cc: Welty,
On Tue, 23 Jan 2024, Jani Nikula wrote:
> On Tue, 23 Jan 2024, Thomas Zimmermann wrote:
>> This reverts commit 60aebc9559492cea6a9625f514a8041717e3a2e4.
>>
>> Commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from
>> device_initcall to subsys_initcall_sync") messes up initialization
Hej Arnd,
On Tue, Jan 23, 2024, at 08:34, Arnd Bergmann wrote:
> On Mon, Jan 22, 2024, at 21:50, Janne Grunau wrote:
>> On Wed, Jan 17, 2024, at 11:44, Arnd Bergmann wrote:
>>>
>>> -int parse_sample_rate_bit(struct dcp_parse_ctx *handle, unsigned int
>>> *ratebit)
>>> +static int
Hej,
debug dma code is not happy with virtio gpu (arm64 VM):
[ 305.881733] [ cut here ]
[ 305.883117] DMA-API: virtio-pci :07:00.0: mapping sg segment longer than
device claims to support [len=262144] [max=65536]
[ 305.885976] WARNING: CPU: 8 PID: 2002 at
Am Mo., 22. Jan. 2024 um 16:50 Uhr schrieb Harry Wentland
:
>
>
>
> On 2024-01-19 13:25, Ville Syrjälä wrote:
> > On Fri, Jan 19, 2024 at 03:12:35PM -0300, André Almeida wrote:
> >> AMD GPUs can do async flips with changes on more properties than just
> >> the FB ID, so implement a custom
On 1/22/2024 20:11, Mario Limonciello wrote:
commit f7fe64ad0f22 ("drm/sched: Split free_job into own work item")
causes graphics hangs at GDM or right after logging in on a
Framework 13 AMD laptop (containing a Phoenix APU).
This reverts commit f7fe64ad0f22ff034f8ebcfbd7299ee9cc9b57d7.
Fixes:
We're currently trying to remove page->mapping from the entire kernel.
This has me interested in fb_defio and since I made such a mess of it
with commits ccf953d8f3d6 / 0b78f8bcf495, I'd like to discuss what to
do before diving in.
Folios continue to have a mapping. So we can effectively do
1 - 100 of 188 matches
Mail list logo
