return dev_err_probe(dev, PTR_ERR(boe->panel.backlight),
---
base-commit: 41c196e567fb1ea97f68a2ffb7faab451cd90854
change-id: 20240722-bf060y8m-aj0-prepare-prev-2db87e7dd996
Best regards,
--
Dang Huynh
Elan-ekth6a12nay requires reset to pull down time greater than 10ms,
so the configuration post_power_delay_ms is 10, and the chipset
initial time is required to be greater than 300ms, so the
post_gpio_reset_on_delay_ms is set to 300.
The Elan-ekth6a12nay touch screen chip same as Elan-eKTH6915 co
The Elan ekth6a12nay touch screen chip same as Elan eKTH6915 controller
has a reset gpio. The difference is that they have different
post_power_delay_ms.
Acked-by: Rob Herring (Arm)
Signed-off-by: Zhaoxiong Lv
---
Changes between V4 and V3:
- 1. Combine the 2 const into an enum.
v3:
https://l
Elan-ekth6a12nay requires reset to pull down time greater than 10ms,
so the configuration post_power_delay_ms is 10, and the chipset
initial time is required to be greater than 300ms,
so the post_gpio_reset_on_delay_ms is set to 300.
Reviewed-by: Douglas Anderson
Signed-off-by: Zhaoxiong Lv
---
On Mon, Jul 22, 2024 at 11:42:52AM +0530, Ekansh Gupta wrote:
>
>
> On 7/22/2024 11:28 AM, Greg KH wrote:
> > On Mon, Jul 22, 2024 at 11:24:36AM +0530, Ekansh Gupta wrote:
> >> For user PD initialization, initmem is allocated and sent to DSP for
> >> initial memory requirements like shell loading
On Fri, Jul 19, 2024 at 11:55:06AM +0200, Nirmoy Das wrote:
Not a complete review, just a few comments.
> On LNL because of flat CCS, driver creates a migrate job to clear
> CCS meta data. Extend that to also clear system pages using GPU.
> Inform TTM to allocate pages without __GFP_ZERO to avoid
On 7/22/2024 1:09 PM, Greg KH wrote:
> On Mon, Jul 22, 2024 at 11:42:52AM +0530, Ekansh Gupta wrote:
>>
>> On 7/22/2024 11:28 AM, Greg KH wrote:
>>> On Mon, Jul 22, 2024 at 11:24:36AM +0530, Ekansh Gupta wrote:
For user PD initialization, initmem is allocated and sent to DSP for
initia
This patch series fixes the incorrect initmem size assumptions for
signed and unsigned user PD.
Previous single patch[v4]:
https://lore.kernel.org/all/20240719085708.1764952-1-quic_ekang...@quicinc.com/
Changes in v2:
- Modified commit text.
- Removed size check instead of updating max file s
For user PD initialization, initmem is allocated and sent to DSP for
initial memory requirements like shell loading. The size of this memory
is decided based on the shell size that is passed by the user space.
With the current implementation, a minimum of 2MB is always allocated
for initmem even if
For unsigned PD offloading requirement, additional memory is required
because of additional static heap initialization. Without this
additional memory, PD initialization would fail. Increase the initmem
size by 2MB for unsigned PD initmem buffer allocation. Any additional
memory sent to DSP during
[AMD Official Use Only - AMD Internal Distribution Only]
Sorry if I mangled the reply. AMDs mail servers seem to have a hickup this
morning and I have to use OWA.
Von: Matthew Brost
Gesendet: Freitag, 19. Juli 2024 19:39
An: Christian König
Cc: Tvrtko Ur
On Sat, Jul 20, 2024 at 09:16:11AM GMT, Ekansh Gupta wrote:
> Memory intensive applications(which requires more tha 4GB) that wants
> to offload tasks to DSP might have to split the tasks to multiple
> user PD to make the resources available.
>
> For every call to DSP, fastrpc driver passes the pr
On Mon, Jul 22, 2024 at 01:23:56PM GMT, Ekansh Gupta wrote:
>
>
> On 7/22/2024 1:09 PM, Greg KH wrote:
> > On Mon, Jul 22, 2024 at 11:42:52AM +0530, Ekansh Gupta wrote:
> >>
> >> On 7/22/2024 11:28 AM, Greg KH wrote:
> >>> On Mon, Jul 22, 2024 at 11:24:36AM +0530, Ekansh Gupta wrote:
> For u
On 21.07.2024 11:43 PM, Barnabás Czémán wrote:
> On Sat, Jun 22, 2024 at 1:36 PM Konrad Dybcio
> wrote:
>>
>> On 20.06.2024 11:52 PM, Barnabás Czémán wrote:
>>> From: Otto Pflüger
>>>
>>> Add support for Adreno 306A GPU what is found in MSM8917 SoC.
>>> This GPU marketing name is Adreno 308.
>>>
On Mon, Jul 22, 2024 at 01:31:58PM GMT, Ekansh Gupta wrote:
> This patch series fixes the incorrect initmem size assumptions for
> signed and unsigned user PD.
> Previous single patch[v4]:
> https://lore.kernel.org/all/20240719085708.1764952-1-quic_ekang...@quicinc.com/
>
> Changes in v2:
> - M
On Mon, Jul 22, 2024 at 01:31:59PM GMT, Ekansh Gupta wrote:
> For user PD initialization, initmem is allocated and sent to DSP for
> initial memory requirements like shell loading. The size of this memory
> is decided based on the shell size that is passed by the user space.
> With the current impl
On Mon, Jul 22, 2024 at 01:32:00PM GMT, Ekansh Gupta wrote:
> For unsigned PD offloading requirement, additional memory is required
> because of additional static heap initialization. Without this
> additional memory, PD initialization would fail. Increase the initmem
> size by 2MB for unsigned PD
On 7/22/2024 9:50 AM, Matthew Brost wrote:
On Fri, Jul 19, 2024 at 11:55:06AM +0200, Nirmoy Das wrote:
Not a complete review, just a few comments.
On LNL because of flat CCS, driver creates a migrate job to clear
CCS meta data. Extend that to also clear system pages using GPU.
Inform TTM to
This was basically just another one of amdgpus hacks. The parameter
allowed to restart the scheduler without turning fence signaling on
again.
That this is absolutely not a good idea should be obvious by now since
the fences will then just sit there and never signal.
While at it cleanup the code
Hi all,
just a small push on this, since I received no notifications.
On 13/06/2024 09:26, Andrea Calabrese wrote:
Code refactoring using the recent guard and scoped_guard macros
for automatic cleanup of the spinlocks. This does not change the
effective behaviour of the kernel, but guarantees a
That's a known issue and we are already working on it.
Regards,
Christian.
Am 20.07.24 um 19:08 schrieb Mikhail Gavrilov:
Hi,
I spotted "MES failed to respond to msg=MISC (WAIT_REG_MEM)" messages
in my kernel log since 6.10-rc5.
After this message, usually follow "[drm:amdgpu_mes_reg_write_reg_
On 19/07/2024 20:50, Mitchell Levy wrote:
I am trying to test this patchset on my setup, but I cannot get it
working. In case it's relevant, I'm running under HyperV. Any
troubleshooting steps/suggestions would definitely be appreciated.
First, make sure you have this in your .config:
CONFIG_R
On Wed, Jul 17, 2024 at 4:27 PM Jocelyn Falempe wrote:
>
> This patch adds a new panic screen, with a QR code and the kmsg data
> embedded.
> If DRM_PANIC_SCREEN_QR_CODE_URL is set, then the kmsg data will be
> compressed with zlib and encoded as a numerical segment, and appended
> to the URL as a
The current driver can only obtain the porch parameters
of boe-th101mb31ig002. Modify it to obtain the porch
parameters of the panel currently being used.
Also switch to the drm_connector_helper_get_modes_fixed() function
to get the porch parameters.
Changes between V3 and V2:
- PATCH 1/2: No ch
The current driver can only obtain the porch parameters
of boe-th101mb31ig002. Modify it to obtain the porch
parameters of the panel currently being used.
Reviewed-by: Douglas Anderson
Signed-off-by: Zhaoxiong Lv
---
Changes between V3 and V2:
- 1. No changes.
v2:
https://lore.kernel.org/all/2
Use public functions( drm_connector_helper_get_modes_fixed()) to
get porch parameters.
Signed-off-by: Zhaoxiong Lv
---
Changes between V3 and V2:
- 1. Keep bpc settings and drm_connector_set_panel_orientation() function..
v2:
https://lore.kernel.org/all/20240716121112.14435-3-lvzhaoxi...@huaqin
Hi Raag
On 7/12/2024 5:53 PM, Raag Jadav wrote:
Add hwmon support for fan1_input attribute, which will expose fan speed
in RPM. With this in place we can monitor fan speed using lm-sensors tool.
$ sensors
i915-pci-0300
Adapter: PCI adapter
in0: 653.00 mV
fan1:3833 RPM
power1:
Hi Matthew,
On 7/19/2024 4:01 PM, Matthew Auld wrote:
On 17/07/2024 16:02, Paneer Selvam, Arunpravin wrote:
On 7/16/2024 3:34 PM, Matthew Auld wrote:
On 16/07/2024 10:50, Paneer Selvam, Arunpravin wrote:
Hi Matthew,
On 7/10/2024 6:20 PM, Matthew Auld wrote:
On 10/07/2024 07:03, Paneer Sel
Panic_cpu is not exported, so it can't be used if fbcon is used as
a module. Use oops_in_progress in this case, but non-fatal oops won't
be printed.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202407210203.2isiic9m-...@intel.com/
Signed-off-by: Jocelyn Falempe
-
Hi Thomas,
On 7/20/24 9:31 AM, Thomas Weißschuh wrote:
> Hi Hans,
>
> On 2024-07-18 10:25:18+, Hans de Goede wrote:
>> On 6/24/24 6:15 PM, Thomas Weißschuh wrote:
>>> On 2024-06-24 11:11:40+, Hans de Goede wrote:
On 6/23/24 10:51 AM, Thomas Weißschuh wrote:
> The value of "min_in
On Tue, Jul 16, 2024 at 10:48:03AM -0400, Hamza Mahfooz wrote:
Hi Sasha,
On 7/16/24 10:24, Sasha Levin wrote:
From: Tom Chung
[ Upstream commit 6b8487cdf9fc7bae707519ac5b5daeca18d1e85b ]
[Why]
Sometimes the new_crtc_state->vrr_infopacket did not sync up with the
current state.
It will affect
Hi Easwar,
merged to drm-intel-next. Thanks!
On Thu, Jul 11, 2024 at 05:27:31AM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
> fix the terminology for
On Tue, Jun 18, 2024 at 01:42:56PM +0200, Christian König wrote:
Am 18.06.24 um 11:11 schrieb Pavel Machek:
Hi!
[ Upstream commit a0cf36546cc24ae1c95d72253c7795d4d2fc77aa ]
The pointer parent may be NULLed by the function amdgpu_vm_pt_parent.
To make the code more robust, check the pointer pa
On 19/07/2024 16:18, Christian König wrote:
Am 19.07.24 um 15:02 schrieb Christian König:
Am 19.07.24 um 11:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Long time ago in commit b3ac17667f11 ("drm/scheduler: rework entity
creation") a change was made which prevented priority changes for
Am 22.07.24 um 15:52 schrieb Tvrtko Ursulin:
On 19/07/2024 16:18, Christian König wrote:
Am 19.07.24 um 15:02 schrieb Christian König:
Am 19.07.24 um 11:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Long time ago in commit b3ac17667f11 ("drm/scheduler: rework entity
creation") a change wa
On Thu, Jul 18, 2024 at 11:30:05AM +0200, Jocelyn Falempe wrote:
>
>
> On 18/07/2024 09:04, Jocelyn Falempe wrote:
> >
> >
> > On 17/07/2024 17:08, Daniel Vetter wrote:
> > > On Wed, Jul 17, 2024 at 10:48:39AM +0200, Jocelyn Falempe wrote:
> > > > It allows to check if the drm device supports d
On Mon, Jul 22, 2024 at 01:47:51PM +0200, Jocelyn Falempe wrote:
> Panic_cpu is not exported, so it can't be used if fbcon is used as
> a module. Use oops_in_progress in this case, but non-fatal oops won't
> be printed.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kb
On 22/07/2024 15:06, Christian König wrote:
Am 22.07.24 um 15:52 schrieb Tvrtko Ursulin:
On 19/07/2024 16:18, Christian König wrote:
Am 19.07.24 um 15:02 schrieb Christian König:
Am 19.07.24 um 11:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Long time ago in commit b3ac17667f11 ("drm/
From: Otto Pflüger
Add support for Adreno 306A GPU what is found in MSM8917 SoC.
This GPU marketing name is Adreno 308.
Signed-off-by: Otto Pflüger
[use internal name of the GPU, reword the commit message]
Reviewed-by: Konrad Dybcio
Signed-off-by: Barnabás Czémán
---
Changes in v3:
- Fix issu
Hello!
Reminder - The CfP is now open for talks, workshops and demos at XDC
2024. The deadline for submissions is Monday, 12 August 2024.
https://indico.freedesktop.org/event/6/abstracts/
While any serious proposal will be gratefully considered, topics of
interest to X.Org and freedesktop.org de
Am 22.07.24 um 16:43 schrieb Tvrtko Ursulin:
On 22/07/2024 15:06, Christian König wrote:
Am 22.07.24 um 15:52 schrieb Tvrtko Ursulin:
On 19/07/2024 16:18, Christian König wrote:
Am 19.07.24 um 15:02 schrieb Christian König:
Am 19.07.24 um 11:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Don't populate the read-only array bw_gbps on the stack at run time,
instead make it static const.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/
Hi,
On Fri, Jul 19, 2024 at 10:07 AM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Jul 18, 2024 at 7:59 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, Jul 18, 2024 at 7:56 AM Conor Dooley wrote:
> > >
> > > On Thu, Jul 18, 2024 at 07:45:57AM -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> > >
Hi,
On Mon, Jul 15, 2024 at 6:51 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jul 15, 2024 at 6:02 AM Neil Armstrong
> wrote:
> >
> > On 15/07/2024 14:54, Stephan Gerhold wrote:
> > > On Mon, Jul 15, 2024 at 02:42:12PM +0200, Neil Armstrong wrote:
> > >> On 15/07/2024 14:15, Stephan Gerhold wrote
Hi,
On Mon, Jul 15, 2024 at 9:40 AM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Jun 21, 2024 at 1:46 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Fri, Jun 21, 2024 at 1:45 PM Douglas Anderson
> > wrote:
> > >
> > > At shutdown if you've got a _properly_ coded DRM modeset driver then
> > > you'l
On 7/22/2024 5:50 AM, Andi Shyti wrote:
> Hi Easwar,
>
> merged to drm-intel-next. Thanks!
>
> On Thu, Jul 11, 2024 at 05:27:31AM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by Wolfram's se
Hi Easwar,
On Mon, Jul 22, 2024 at 09:15:08AM -0700, Easwar Hariharan wrote:
> On 7/22/2024 5:50 AM, Andi Shyti wrote:
> > Hi Easwar,
> >
> > merged to drm-intel-next. Thanks!
> >
> > On Thu, Jul 11, 2024 at 05:27:31AM +, Easwar Hariharan wrote:
> >> I2C v7, SMBus 3.2, and I3C 1.1.1 specific
On 22/07/2024 17:21, Richard Weinberger wrote:
- Ursprüngliche Mail -
Betreff: [PATCH] mtd: mtdoops: Fix kmsgdump parameter renaming.
When the kmsg_dumper callback parameter changed, the reason variable
in mtdoops_do_dump() was not updated accordingly.
This breaks the build with mt
On 22/07/2024 16:15, Daniel Vetter wrote:
On Mon, Jul 22, 2024 at 01:47:51PM +0200, Jocelyn Falempe wrote:
Panic_cpu is not exported, so it can't be used if fbcon is used as
a module. Use oops_in_progress in this case, but non-fatal oops won't
be printed.
Reported-by: kernel test robot
Clos
Factor out a function to queue a work for probing the topology, also
used by the next patch.
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a
A follow up i915 patch will need to reprobe the MST topology after the
initial probing, add a helper for this.
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 27 +++
include/drm/display/drm_dp_mst_h
In the
if (old_ddps != port->ddps || !created)
if (port->ddps && !port->input)
ret = drm_dp_send_enum_path_resources();
sequence the first if's condition is true if the port exists already
(!created) or the port was created anew (hence old_ddps==0) a
On 7/20/24 03:54, Markus Elfring wrote:
… The tile columns belong to
…
which …?
…
+++ b/drivers/accel/amdxdna/aie2_ctx.c
@@ -0,0 +1,181 @@
…
+void aie2_hwctx_fini(struct amdxdna_hwctx *h
Hi,
On Fri, Jul 19, 2024 at 10:19 PM Tejas Vipin wrote:
>
> On 7/19/24 10:29 PM, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, Jul 17, 2024 at 3:07 AM Dmitry Baryshkov
> > wrote:
> >>
> However it might be better to go other way arround.
> Do we want for all the drivers to migrate to _m
On Fri, Jul 19, 2024 at 11:52:49AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> The Samsung ATNA45DC02 panel is an AMOLED eDP panel, similar to the
> existing ATNA45AF01 and ATNA33XC20 panel but with a higher resolution.
>
> Signed-off-by: Rob Clark
Acked-by: Conor Dooley
signature.asc
Des
For patches 1-3:
Reviewed-by: Lyude Paul
Thanks!
On Mon, 2024-07-22 at 19:54 +0300, Imre Deak wrote:
> Factor out a function to queue a work for probing the topology, also
> used by the next patch.
>
> Cc: Lyude Paul
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak
> ---
> d
Hi,
On Sun, Jul 21, 2024 at 4:00 AM Terry Hsiao
wrote:
>
> Hi Doug,
>
> Thank you for your reply.
> The patch has been modified and will be sent to you shortly.
For future reference, the Linux community frowns upon "top posting".
Search for "top-posting" on [1]
[1] https://www.arm.linux.org.uk/
Hi,
On Sun, Jul 21, 2024 at 3:04 AM Terry Hsiao
wrote:
>
> The raw EDIDs for each panel:
>
> AUO
> - B116XTN02.3
> 00 ff ff ff ff ff ff 00 06 af aa 73 00 00 00 00
> 00 21 01 04 95 1a 0e 78 02 6b f5 91 55 54 91 27
> 22 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 ce 1d 56 e2 50
Hi,
On Mon, Jul 22, 2024 at 2:24 AM Zhaoxiong Lv
wrote:
>
> @@ -313,29 +314,15 @@ static int boe_th101mb31ig002_get_modes(struct
> drm_panel *panel,
> struct
> boe_th101mb31ig002,
> panel
On Sat, Jul 20, 2024 at 8:13 AM Markus Elfring wrote:
>
> …
> > +++ b/drivers/dma-buf/dma-heap.c
> …
> > +static void dma_heap_release(struct kref *ref)
> > +{
> …
> > + mutex_lock(&heap_list_lock);
> > + list_del(&heap->list);
> > + mutex_unlock(&heap_list_lock);
> …
>
> Under which c
>> …
>>> +++ b/drivers/dma-buf/dma-heap.c
>> …
>>> +static void dma_heap_release(struct kref *ref)
>>> +{
>> …
>>> + mutex_lock(&heap_list_lock);
>>> + list_del(&heap->list);
>>> + mutex_unlock(&heap_list_lock);
>> …
>>
>> Under which circumstances would you become interested to apply a
From: Eugene Lepshy
According to downstream, A642L's speedbin is 129 and uses 4 as index
Signed-off-by: Eugene Lepshy
Signed-off-by: Danila Tikhonov
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
b/d
This small series fixes all known prime/dumb_buffer/buffer dirty
tracking issues. Fixing of dumb-buffers turned out to be a lot more
complex than I wanted it to be. There's not much that can be done
there because the driver has to support old userspace (our Xorg driver
expects those to not be gem b
Introduce a version of the fence ops that on release doesn't remove
the fence from the pending list, and thus doesn't require a lock to
fix poll->fence wait->fence unref deadlocks.
vmwgfx overwrites the wait callback to iterate over the list of all
fences and update their status, to do that it hol
Fix races issues in virtual crc generation by making sure the surface
the code uses for crc computation is properly ref counted.
Crc generation was trying to be too clever by allowing the surfaces
to go in and out of scope, with the hope of always having some kind
of screen present. That's not alw
Dumb buffers can be used in kms but also through prime with gallium's
resource_from_handle. In the second case the dumb buffers can be
rendered by the GPU where with the regular DRM kms interfaces they
are mapped and written to by the CPU. Because the same buffer can
be written to by the GPU and CP
This patch series adds support for the A642L GPU speedbin (0x81) to the
Adreno driver and updates the device tree for the SC7280 platform to
include this new speedbin. The A642L is used in the Qualcomm Snapdragon
SM7325 SoCs family, which is identical to the SC7280, just as the SM7125 is
identical
Make vmwgfx go through the dma-buf interface to map/unmap imported
buffers. The driver used to try to directly manipulate external
buffers, assuming that everything that was coming to it had to live
in cpu accessible memory. While technically true because what's in the
vms is controlled by us, it's
From: Eugene Lepshy
A642L (speedbin 0x81) uses index 4, so this commit
sets the fourth bit for A642L supported opps.
Signed-off-by: Eugene Lepshy
Signed-off-by: Danila Tikhonov
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
These structures are not modified in this driver.
Constifying this structure moves about 8 ko of data to a read-only section,
so increase overall security.
On a x86_64, with allmodconfig:
Before:
==
textdata bss dec hex filename
191214 134180 456 325850 4f8da drive
On 7/18/24 7:53 AM, Ben Skeggs wrote:
On 19/7/24 02:58, Danilo Krummrich wrote:
Hi Christian,
Those three patches should unblock your series to use GEM references instead of
TTM ones.
@Lyude, Dave: Can you please double check?
Hi Danilo,
These look fine to me, and appear to resolve the iss
This is intended to fix the pmu integration in i915 when the device
unbinds. I don't have the hardware to test, but I belive a similar issue
occurs with any driver using perf_pmu_unregister() if they can unbind
from the device - in drm subsystem, that would be the amd driver.
Previous attempts I c
There's no reason to hardcode checking for integrated graphics on a
specific pci slot. That information is already available per platform an
can be checked with IS_DGFX().
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_pmu.c | 17 +++--
1 file changed, 3 insertions(+),
i915 pointer is not needed in this function and all the others simply
calculate the i915_pmu container based on the event->pmu. Follow the
same logic as in other functions.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_pmu.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(
event_init is not an optional function pointer from perf events. Now
that pmu unregister happens only when freeing i915, setting it to NULL
only protects other functions in i915. Replace that by checking
pmu->closed.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_pmu.c | 8 +++-
There's no need to free the resources during unbind. Since perf events
may still access them due to open events, it's safer to free them when
dropping the last i915 reference.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_pmu.c | 21 -
1 file changed, 16 insert
When an i915 PMU counter is enabled and the driver is then unbound, the
PMU will be unregistered via perf_pmu_unregister(), however the event
will still be alive. i915 currently tries to deal with this situation
by:
a) Marking the pmu as "closed" and shortcut the calls from perf
b)
If a pmu is unregistered while there's an active event, perf will still
access the pmu via event->pmu, even after the event is destroyed. This
makes it difficult for drivers like i915 that take a reference on the
device when the event is created and put it when it's destroyed.
Currently the followi
Instead of calling perf_pmu_unregister() when unbinding, defer that to
the destruction of i915 object. Since perf itself holds a reference in
the event, this only happens when all events are gone, which guarantees
i915 is not unregistering the pmu with live events.
Previously, running the followin
On Mon, Jul 22, 2024 at 4:50 AM Christian König
wrote:
>
> That's a known issue and we are already working on it.
Do either of these patches help?
https://patchwork.freedesktop.org/patch/605437/
https://patchwork.freedesktop.org/patch/605201/
Alex
>
> Regards,
> Christian.
>
> Am 20.07.24 um 19
On Fri, Jul 12, 2024 at 05:32:28PM +0800, Liu Ying wrote:
> Freescale i.MX8qxp Display Controller is implemented as construction set of
> building blocks with unified concept and standardized interfaces.
>
> Document some processing units to support two display outputs.
>
> ConstFrame, ExtDst, Fe
On Fri, Jul 12, 2024 at 05:32:29PM +0800, Liu Ying wrote:
> i.MX8qxp Display Controller display engine consists of all processing units
> that operate in a display clock domain.
>
> Signed-off-by: Liu Ying
> ---
> v2:
> * Drop fsl,dc-*-id DT properties. (Krzysztof)
> * Drop port property. (Krzysz
On Fri, 12 Jul 2024 17:32:31 +0800, Liu Ying wrote:
> i.MX8qxp Display Controller has a built-in interrupt controller to support
> Enable/Status/Preset/Clear interrupt bit.
>
> Signed-off-by: Liu Ying
> ---
> v2:
> * Drop unneeded "|". (Krzysztof)
>
> .../fsl,imx8qxp-dc-intc.yaml
On Fri, Jul 12, 2024 at 05:32:38PM +0800, Liu Ying wrote:
> assigned-clock* properties can be used by default now, so allow them.
>
> Signed-off-by: Liu Ying
> ---
> v2:
> * New patch as needed by MIPI/LVDS subsystems device tree.
Seems like this could go on its own, but if you don't want it mer
On Mon, 22 Jul 2024 14:06:45 -0700, Lucas De Marchi wrote:
>
> There's no reason to hardcode checking for integrated graphics on a
> specific pci slot. That information is already available per platform an
> can be checked with IS_DGFX().
Reviewed-by: Ashutosh Dixit
> Signed-off-by: Lucas De Mar
On Sun, Jul 14, 2024 at 1:50 PM Dmitry Osipenko
wrote:
>
> Type of DMA fence context is u64. Fence-waiting code uses u32 for the
> context variable, fix it.
>
> Fixes: e4812ab8e6b1 ("drm/virtio: Refactor and optimize job submission code
> path")
> Cc: # v6.4+
> Signed-off-by: Dmitry Osipenko
R
On Sun, Jul 14, 2024 at 1:55 PM Dmitry Osipenko
wrote:
>
> Define DRM native context capset in the VirtIO-GPU protocol header.
>
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Rob Clark
> ---
> include/uapi/linux/virtio_gpu.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uap
https://bugzilla.kernel.org/show_bug.cgi?id=211807
getcrarea (farareja...@gmail.com) changed:
What|Removed |Added
CC||farareja...@gmail.com
On Tue, Jul 16, 2024 at 01:10:37PM -0400, Alex Deucher wrote:
> From 8aaf8da07a8b542c0a0f4da2601da07beddfdeb0 Mon Sep 17 00:00:00 2001
> From: Alex Deucher
> Date: Tue, 16 Jul 2024 12:49:25 -0400
> Subject: [PATCH] drm/amd/display: fix corruption with high refresh rates on
> DCN 3.0
>
> This rev
On 7/22/2024 2:02 PM, Dmitry Baryshkov wrote:
> On Mon, Jul 22, 2024 at 01:31:59PM GMT, Ekansh Gupta wrote:
>> For user PD initialization, initmem is allocated and sent to DSP for
>> initial memory requirements like shell loading. The size of this memory
>> is decided based on the shell size tha
@@
#define VMWGFX_DRIVER_NAME "vmwgfx"
-#define VMWGFX_DRIVER_DATE "20211206"
+#define VMWGFX_DRIVER_DATE "20240722"
#define VMWGFX_DRIVER_MAJOR 2
-#define VMWGFX_DRIVER_MINOR 20
+#define VMWGFX_DRIVER_MINOR 21
#define VMWGFX_DRIVER_PATCHLEVEL 0
#define VMWG
On 7/22/2024 2:04 PM, Dmitry Baryshkov wrote:
> On Mon, Jul 22, 2024 at 01:32:00PM GMT, Ekansh Gupta wrote:
>> For unsigned PD offloading requirement, additional memory is required
>> because of additional static heap initialization. Without this
>> additional memory, PD initialization would fai
On 7/22/2024 1:56 PM, Dmitry Baryshkov wrote:
> On Mon, Jul 22, 2024 at 01:31:58PM GMT, Ekansh Gupta wrote:
>> This patch series fixes the incorrect initmem size assumptions for
>> signed and unsigned user PD.
>> Previous single patch[v4]:
>> https://lore.kernel.org/all/20240719085708.1764952-1
On Mon, 22 Jul 2024 14:06:44 -0700, Lucas De Marchi wrote:
>
> i915 pointer is not needed in this function and all the others simply
> calculate the i915_pmu container based on the event->pmu. Follow the
> same logic as in other functions.
Reviewed-by: Ashutosh Dixit
>
> Signed-off-by: Lucas De
The current driver can only obtain the porch parameters
of boe-th101mb31ig002. Modify it to obtain the porch
parameters of the panel currently being used.
Reviewed-by: Douglas Anderson
Signed-off-by: Zhaoxiong Lv
---
Changes between V4 and V3:
- 1. No changes.
v3:
https://lore.kernel.org/all/2
The current driver can only obtain the porch parameters
of boe-th101mb31ig002. Modify it to obtain the porch
parameters of the panel currently being used.
Also switch to the drm_connector_helper_get_modes_fixed() function
to get the porch parameters.
Changes between V4 and V3:
- PATCH 1/2: No ch
Use public functions( drm_connector_helper_get_modes_fixed()) to
get porch parameters.
Signed-off-by: Zhaoxiong Lv
---
Changes between V4 and V3:
- 1.Modify the return value, return
drm_connector_helper_get_modes_fixed(connector, desc_mode).
v3:
https://lore.kernel.org/all/20240722092428.24499
Am 22.07.24 um 23:01 schrieb Danilo Krummrich:
On 7/18/24 7:53 AM, Ben Skeggs wrote:
On 19/7/24 02:58, Danilo Krummrich wrote:
Hi Christian,
Those three patches should unblock your series to use GEM references
instead of
TTM ones.
@Lyude, Dave: Can you please double check?
Hi Danilo,
Th
98 matches
Mail list logo
