Flush mechanism for DSPP blocks has changed in sc7280 family, it
allows individual sub blocks to be flushed in coordination with
master flush control.
Representation: master_flush && (PCC_flush | IGC_flush .. etc )
This change adds necessary support for the above design.
Changes in v1:
- Few
On Thu, Sep 22, 2022 at 07:18:51AM +0300, Kalle Valo wrote:
> Kees Cook writes:
>
> > In preparation for reducing the use of ksize(), explicitly track the
> > size of scan_cmd allocations. This also allows for noticing if the scan
> > size changes unexpectedly. Note that using ksize() was
On 9/22/2022 8:47 AM, Dixit, Ashutosh wrote:
On Wed, 21 Sep 2022 08:07:15 -0700, Gupta, Anshuman wrote:
Hi Anshuman,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 55c35903adca..956e5298ef1e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++
> From: Jason Gunthorpe
> Sent: Thursday, September 22, 2022 12:10 AM
>
> On Tue, Sep 20, 2022 at 10:55:40PM +, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Wednesday, September 21, 2022 4:27 AM
> > >
> > > On Fri, 9 Sep 2022 18:22:47 +0800
> > > Kevin Tian wrote:
> > >
> >
The function parameter 'exclude' in funciton
i915_sw_fence_await_reservation() is not used.
Remove it.
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 5 ++---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 +-
[AMD Official Use Only - General]
Reviewed-by: Evan Quan
> -Original Message-
> From: Li Zhong
> Sent: Thursday, September 22, 2022 12:18 PM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: jiapeng.ch...@linux.alibaba.com; Powell, Darren
> ; Chen, Guchun ;
>
Kees Cook writes:
> In preparation for reducing the use of ksize(), explicitly track the
> size of scan_cmd allocations. This also allows for noticing if the scan
> size changes unexpectedly. Note that using ksize() was already incorrect
> here, in the sense that ksize() would not match the
On Wed, 21 Sep 2022 08:07:15 -0700, Gupta, Anshuman wrote:
>
Hi Anshuman,
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 55c35903adca..956e5298ef1e 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@
Instead of having a mismatch between the requested allocation size and
the actual kmalloc bucket size, which is examined later via ksize(),
round up proactively so the allocation is explicitly made for the full
size, allowing the compiler to correctly reason about the resulting size
of the buffer
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc:
With skbuff's post-allocation use of ksize() rearranged to use
kmalloc_size_round() prior to allocation, the compiler can correctly
reason about the size of these allocations. The prior mismatch had caused
buffer overflow mitigations to erroneously fire under CONFIG_UBSAN_BOUNDS,
requiring a
Instead of having a mismatch between the requested allocation size and
the actual kmalloc bucket size, which is examined later via ksize(),
round up proactively so the allocation is explicitly made for the full
size, allowing the compiler to correctly reason about the resulting size
of the buffer
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc:
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc: Alex Elder
Cc: "David S.
In preparation for reducing the use of ksize(), record the actual
allocation size for later memcpy(). This avoids copying extra
(uninitialized!) bytes into the patch buffer when the requested allocation
size isn't exactly the size of a kmalloc bucket. Additionally fixes
potential future issues
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
This will allow for kernels
The __malloc attribute should not be applied to "realloc" functions, as
the returned pointer may alias the storage of the prior pointer. Instead
of splitting __malloc from __alloc_size, which would be a huge amount of
churn, just create __realloc_size for the few cases where it is needed.
In the effort to help the compiler reason about buffer sizes, the
__alloc_size attribute was added to allocators. This improves the scope
of the compiler's ability to apply CONFIG_UBSAN_BOUNDS and (in the near
future) CONFIG_FORTIFY_SOURCE. For most allocations, this works well,
as the vast
In preparation for reducing the use of ksize(), explicitly track the
size of scan_cmd allocations. This also allows for noticing if the scan
size changes unexpectedly. Note that using ksize() was already incorrect
here, in the sense that ksize() would not match the actual allocation
size, which
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.
Cc:
Hi,
This series fixes up the cases where callers of ksize() use it to
opportunistically grow their buffer sizes, which can run afoul of the
__alloc_size hinting that CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE
use to perform dynamic buffer bounds checking. Quoting the first patch:
In the
On Wed, 2022-09-21 at 10:15 +0200, AngeloGioacchino Del Regno wrote:
> Il 20/09/22 11:00, Chunfeng Yun ha scritto:
> > Due to FIELD_PREP() macro can be used to prepare a bitfield value,
> > local ones can be remove; add the new helper to make bitfield
> > update
> > easier.
> >
> > Signed-off-by:
Perhaps you need to update the prefix of patch subject to 'drm/amd/pm: check
return value ...'.
With above addressed, it's: Acked-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Li Zhong
Sent: Thursday, September 22, 2022 9:27 AM
To: dri-devel@lists.freedesktop.org;
Clean the redundant assignment of ttm->caching in ttm_tt_init_fields().
Signed-off-by: Chuansheng Liu
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index d505603930a7..e110db86c870 100644
---
Currently there is no protection against a user trying to set
an unsupported mode on DSI. Implement a check based on the opp
table whether the byte clock for the mode can be supported by
validating whether an opp table entry exists.
For devices which have not added opp table support yet, skip
Re-arrange the dsi_calc_pclk method to two helpers, one to
compute the DSI byte clk and the other to compute the pclk.
This makes the separation of the two clean and also allows
clients to compute and use the dsi byte clk separately.
Signed-off-by: Abhinav Kumar
---
On Tue, Sep 20, 2022 at 09:09:13AM +0200, Krzysztof Kozlowski wrote:
> On 19/09/2022 23:18, Bjorn Andersson wrote:
> > On Sat, Sep 17, 2022 at 06:03:27PM +0100, Krzysztof Kozlowski wrote:
> >> On 16/09/2022 21:00, Bjorn Andersson wrote:
> >>> From: Bjorn Andersson
> >>>
> >>> Add compatibles for
Hi, Dave & Daniel:
This includes:
1. dsi: Add atomic {destroy,duplicate}_state, reset callbacks
2. drm/mediatek: Fix wrong dither settings
3. dsi: Move mtk_dsi_stop() call back to mtk_dsi_poweroff()
Regards,
Chun-Kuang.
The following changes since commit
On Fri, Sep 16, 2022 at 12:53:42AM +0300, Dmitry Baryshkov wrote:
> On Fri, 16 Sept 2022 at 00:25, Bjorn Andersson wrote:
> >
> > On Tue, Sep 13, 2022 at 12:45:45PM +0200, Sebastian Reichel wrote:
> > > Hi,
> > >
> > > [+Cc Lee Jones, DRI devel]
> > >
> > > On Tue, Aug 09, 2022 at 10:05:00PM
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 483fed3b5dc8ce3644c83d24240cf5756fb0993e Add linux-next specific
files for 20220921
Error/Warning reports:
https://lore.kernel.org/linux-mm/202209042337.fqi69rlv-...@intel.com
https
Hi Dave, Daniel,
Fixes for 6.0. Mainly fixes for new IPs. The big change here is the DML
clean up from Nathan to fix the Clang stack usage warnings on the DCN 3.1.4
code which was recently enabled.
The following changes since commit a8671493d2074950553da3cf07d1be43185ef6c6:
drm/amdgpu: make
Hi Dave and Daniel,
Here goes drm-intel-fixes-2022-09-21:
2 gem context related fixes:
- to avoid a general protection failure when using perf/OA (Chris)
- to avoid kernel warnings on driver release (Janusz)
Thanks,
Rodrigo.
The following changes since commit
Randy Dunlap writes:
> Clean up punctuation, spelling, and formatting for command line usage
> and modprobe config file usage in udlfb.rst.
>
> Signed-off-by: Randy Dunlap
> Cc: Bernie Thompson
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Helge Deller
> Cc:
On Wed, Sep 21, 2022 at 12:26:17PM -0700, Matt Roper wrote:
> On Wed, Sep 21, 2022 at 12:58:08PM -0400, Kumar Valsan, Prathap wrote:
> > On Fri, Sep 16, 2022 at 07:53:40AM -0700, Matt Roper wrote:
> > > On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
> > > >
> > > > On 16/09/2022
On Wed, Sep 21, 2022 at 12:58:08PM -0400, Kumar Valsan, Prathap wrote:
> On Fri, Sep 16, 2022 at 07:53:40AM -0700, Matt Roper wrote:
> > On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 16/09/2022 02:43, Matt Roper wrote:
> > > > Although the bspec lists several MMIO
On 9/21/22 21:37, Krzysztof Kozlowski wrote:
On 20/09/2022 10:11, Mikko Perttunen wrote:
From: Mikko Perttunen
On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
has been loaded by a bootloader. When booting NVDEC, we need to tell it
the address of this firmware, which we
On 20/09/2022 10:11, Mikko Perttunen wrote:
> From: Mikko Perttunen
>
> On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
> has been loaded by a bootloader. When booting NVDEC, we need to tell it
> the address of this firmware, which we can determine by checking the
>
When many entities competing for same run queue on
the same scheduler When many entities have unacceptably long wait
time for some jobs waiting stuck in the run queue before being picked
up are observed (seen using GPUVis).
The issue is due to the Round Robin policy used by schedulers
to pick up
On Wed, Sep 21, 2022 at 11:18:53AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
The new execbuf3 ioctl path and the legacy execbuf ioctl
paths have many common functionalities.
Share code between these two paths by abstracting out the
common
On Wed, Sep 21, 2022 at 10:13:12AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
On Wed, Sep 21, 2022 at 10:06:48AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
Add function __i915_sw_fence_await_reservation() for
asynchronous wait on a dma-resv object with specified
dma_resv_usage. This is required for async vma unbind
with vm_bind.
This patch includes changes below:
1) pin_user_pages() is unsafe without protection of mmap_lock,
fix it by calling mmap_read_lock() & mmap_read_unlock().
2) fix & refactor the incorrect exception handling procedure in
vmw_mksstat_add_ioctl().
based-on branch: vmwgfx/drm-misc-fixes
based
On Fri, Sep 16, 2022 at 07:53:40AM -0700, Matt Roper wrote:
> On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
> >
> > On 16/09/2022 02:43, Matt Roper wrote:
> > > Although the bspec lists several MMIO ranges as "MSLICE," it turns out
> > > that a subset of these are of a "GAM"
Hi Thomas,
On Wed, Sep 21, 2022 at 2:55 PM Thomas Zimmermann wrote:
> Am 05.08.22 um 02:19 schrieb Benjamin Herrenschmidt:
> > On Wed, 2022-07-20 at 16:27 +0200, Thomas Zimmermann wrote:
> >> +#if !defined(CONFIG_PPC)
> >> +static inline void out_8(void __iomem *addr, int val)
> >> +{ }
> >>
On Wed, 2022-09-21 at 08:28 +0200, Krzysztof Kozlowski wrote:
> On 21/09/2022 06:16, Jason-JH Lin wrote:
> > Hi Krzysztof,
> >
> > Thanks for the reviews.
> >
> > On Tue, 2022-09-20 at 17:25 +0200, Krzysztof Kozlowski wrote:
> > > On 20/09/2022 16:01, Jason-JH.Lin wrote:
> > > > For previous
On Wed, Sep 21, 2022 at 05:57:55PM +0200, Krzysztof Kozlowski wrote:
> On 21/09/2022 17:50, Chris Morgan wrote:
> > On Wed, Sep 21, 2022 at 05:21:19PM +0200, Krzysztof Kozlowski wrote:
> >> On 21/09/2022 16:38, Chris Morgan wrote:
> > + compatible:
> > +items:
> > + - enum:
>
On Tue, Sep 20, 2022 at 10:55:40PM +, Tian, Kevin wrote:
> > From: Alex Williamson
> > Sent: Wednesday, September 21, 2022 4:27 AM
> >
> > On Fri, 9 Sep 2022 18:22:47 +0800
> > Kevin Tian wrote:
> >
> > > From: Yi Liu
> > >
> > > and replace kref. With it a 'vfio-dev/vfioX' node is
On 21/09/2022 17:50, Chris Morgan wrote:
> On Wed, Sep 21, 2022 at 05:21:19PM +0200, Krzysztof Kozlowski wrote:
>> On 21/09/2022 16:38, Chris Morgan wrote:
> + compatible:
> +items:
> + - enum:
> + - anbernic,rg353p-panel
Are these vendor prefixs
From: Nathan Huckleberry
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of
type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
struct drm_display_mode
From: Nathan Huckleberry
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of
type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
struct drm_display_mode
From: Yao Wang1
[ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ]
[Why]
For HDR mode, we get total 512 tf_point and after switching to SDR mode
we actually get 400 tf_point and the rest of points(401~512) still use
dirty value from HDR mode. We should limit the rest of the points to
From: Nathan Chancellor
[ Upstream commit 41012d715d5d7b9751ae84b8fb255e404ac9c5d0 ]
This function consumes a lot of stack space and it blows up the size of
dml30_ModeSupportAndSystemConfigurationFull() with clang:
From: Nathan Chancellor
[ Upstream commit 41012d715d5d7b9751ae84b8fb255e404ac9c5d0 ]
This function consumes a lot of stack space and it blows up the size of
dml30_ModeSupportAndSystemConfigurationFull() with clang:
From: Hans de Goede
[ Upstream commit 63e37a79f7bd939314997e29c2f5a9f0ef184281 ]
gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event
on mode_set_base()
From: Nathan Chancellor
[ Upstream commit 37934d4118e22bceb80141804391975078f31734 ]
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
From: Yao Wang1
[ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ]
[Why]
For HDR mode, we get total 512 tf_point and after switching to SDR mode
we actually get 400 tf_point and the rest of points(401~512) still use
dirty value from HDR mode. We should limit the rest of the points to
From: Nathan Huckleberry
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of
type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
struct drm_display_mode
From: Hamza Mahfooz
[ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
Signed-off-by:
From: Nathan Chancellor
[ Upstream commit 21485d3da659b66c37d99071623af83ee1c6733d ]
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
From: Yao Wang1
[ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ]
[Why]
For HDR mode, we get total 512 tf_point and after switching to SDR mode
we actually get 400 tf_point and the rest of points(401~512) still use
dirty value from HDR mode. We should limit the rest of the points to
From: Hamza Mahfooz
[ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
Signed-off-by:
From: Guchun Chen
[ Upstream commit 7c6fb61a400bf3218c6504cb2d48858f98822c9d ]
To avoid hardware intermittent failures.
Signed-off-by: Guchun Chen
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 11
From: Nathan Huckleberry
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of
type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
struct drm_display_mode
From: Hans de Goede
[ Upstream commit 63e37a79f7bd939314997e29c2f5a9f0ef184281 ]
gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event
on mode_set_base()
From: Yao Wang1
[ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ]
[Why]
For HDR mode, we get total 512 tf_point and after switching to SDR mode
we actually get 400 tf_point and the rest of points(401~512) still use
dirty value from HDR mode. We should limit the rest of the points to
From: Yao Wang1
[ Upstream commit 3601d620f22e37740cf73f8278eabf9f2aa19eb7 ]
[Why]
For HDR mode, we get total 512 tf_point and after switching to SDR mode
we actually get 400 tf_point and the rest of points(401~512) still use
dirty value from HDR mode. We should limit the rest of the points to
From: Candice Li
[ Upstream commit 86875d558b91cb46f43be112799c06ecce60ec1e ]
No need to reset error status since only umc ras supported on psp v13_0_0.
Signed-off-by: Candice Li
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
From: Nathan Chancellor
[ Upstream commit 41012d715d5d7b9751ae84b8fb255e404ac9c5d0 ]
This function consumes a lot of stack space and it blows up the size of
dml30_ModeSupportAndSystemConfigurationFull() with clang:
From: Nathan Chancellor
[ Upstream commit 21485d3da659b66c37d99071623af83ee1c6733d ]
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
From: Nathan Huckleberry
[ Upstream commit b0b9408f132623dc88e78adb5282f74e4b64bb57 ]
The mode_valid field in drm_connector_helper_funcs is expected to be of
type:
enum drm_mode_status (* mode_valid) (struct drm_connector *connector,
struct drm_display_mode
From: Alex Deucher
[ Upstream commit 8c5708d3da37b8c7c3c22c7e945b9a76a7c9539b ]
Was missing before and would have resulted in a write to
a non-existant register. Normally APUs don't use HDP, but
other asics could use this code and APUs do use the HDP
when used in passthrough.
Reviewed-by: Lijo
From: Nathan Chancellor
[ Upstream commit 37934d4118e22bceb80141804391975078f31734 ]
Most of the arguments are identical between the two call sites and they
can be accessed through the 'struct vba_vars_st' pointer. This reduces
the total amount of stack space that
From: Hamza Mahfooz
[ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
Signed-off-by:
From: Hans de Goede
[ Upstream commit b6f25c3b94f2aadbf5cbef954db4073614943d74 ]
psb_gem_unpin() calls dma_resv_lock() but the underlying ww_mutex
gets destroyed by drm_gem_object_release() move the
drm_gem_object_release() call in psb_gem_free_object() to after
the unpin to fix the below
From: Hamza Mahfooz
[ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
struct.
Signed-off-by: Hamza Mahfooz
Acked-by: Alex Deucher
Signed-off-by:
From: Guchun Chen
[ Upstream commit 7c6fb61a400bf3218c6504cb2d48858f98822c9d ]
To avoid hardware intermittent failures.
Signed-off-by: Guchun Chen
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 11
From: Yang Wang
[ Upstream commit 36de13fdb04abef3ee03ade5129ab146de63983b ]
align TMR BO size TO tmr size is not necessary,
modify the size to 1M to avoid re-create BO fail
when serious VRAM fragmentation.
v2:
add new macro PSP_TMR_ALIGNMENT for TMR BO alignment size
Signed-off-by: Yang Wang
From: Hans de Goede
[ Upstream commit 235fdbc32d559db21e580f85035c59372704f09e ]
Fix gnome-shell (and other page-flip users) hanging after suspend/resume
because of the gma500's IRQs not working.
This fixes 2 problems with the IRQ handling:
1. gma_power_off() calls gma_irq_uninstall() which
From: Hans de Goede
[ Upstream commit 63e37a79f7bd939314997e29c2f5a9f0ef184281 ]
gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event
on mode_set_base()
On Wed, Sep 21, 2022 at 05:21:19PM +0200, Krzysztof Kozlowski wrote:
> On 21/09/2022 16:38, Chris Morgan wrote:
> >>> + compatible:
> >>> +items:
> >>> + - enum:
> >>> + - anbernic,rg353p-panel
> >>
> >> Are these vendor prefixs documented?
> >
> > Yes, they are in another
Hi Badal,
> > > +struct hwm_reg {
> > > +};
> > > +
> > > +struct hwm_drvdata {
> > > + struct i915_hwmon *hwmon;
> > > + struct intel_uncore *uncore;
> > > + struct device *hwmon_dev;
> > > + char name[12];
> > > +};
> > > +
> > > +struct i915_hwmon {
> > > + struct hwm_drvdata ddat;
> > > +
On 21/09/2022 16:38, Chris Morgan wrote:
>>> + compatible:
>>> +items:
>>> + - enum:
>>> + - anbernic,rg353p-panel
>>
>> Are these vendor prefixs documented?
>
> Yes, they are in another patch series referenced in the cover letter.
> They were added for the Anbernic devicetrees
On 21-09-2022 18:14, Andi Shyti wrote:
Hi Badal,
+struct hwm_reg {
+};
+
+struct hwm_drvdata {
+ struct i915_hwmon *hwmon;
+ struct intel_uncore *uncore;
+ struct device *hwmon_dev;
+ char name[12];
+};
+
+struct i915_hwmon {
+ struct hwm_drvdata ddat;
+
On 9/16/2022 8:30 PM, Badal Nilawar wrote:
From: Ashutosh Dixit
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3:
Hi,
On Sun, Sep 11, 2022 at 06:48:50AM +0200, Mateusz Kwiatkowski wrote:
> >> Those extra vbp lines will be treated as a black bar at the top of the
> >> frame,
> >> and extra vfp lines will be at the bottom of the frame.
> >>
> >> However if someone specifies e.g. 720x604, there's nothing more
On 21-09-2022 17:15, Gupta, Anshuman wrote:
On 9/16/2022 8:30 PM, Badal Nilawar wrote:
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
On Wed, Sep 21, 2022 at 08:51:34AM +0200, Krzysztof Kozlowski wrote:
> On 20/09/2022 16:59, Chris Morgan wrote:
> > From: Chris Morgan
> >
> > Add documentation for the NewVision NV3051D panel bindings.
> > Note that for the two expected consumers of this panel binding
> > the underlying LCD
Hi,
Thanks again for your help
On Sun, Sep 11, 2022 at 06:30:39AM +0200, kFYatek wrote:
> W dniu 9.09.2022 o 16:00, Maxime Ripard pisze:
> > On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote:
> >> The "canonical" modelines (at least for vc4's VEC, see the notes below):
> >>
>
On 9/13/22 3:01 PM, Kees Cook wrote:
On Fri, Sep 09, 2022 at 07:59:07PM +0900, Gwan-gyeong Mun wrote:
It adds assert_type and assert_typable macros to catch type mis-match while
compiling. The existing typecheck() macro outputs build warnings, but the
newly added assert_type() macro uses the
On Wed, Sep 07, 2022 at 06:44:53PM +0200, Noralf Trønnes wrote:
>
>
> Den 07.09.2022 12.36, skrev Stefan Wahren:
> > Hi Maxime,
> >
> > Am 05.09.22 um 16:57 schrieb Maxime Ripard:
> >> On Fri, Sep 02, 2022 at 01:28:16PM +0200, Noralf Trønnes wrote:
> >>>
> >>> Den 01.09.2022 21.35, skrev Noralf
On Wed, 2022-09-21 at 09:42 +0800, CK Hu wrote:
> Hi, Xinlei:
>
> On Wed, 2022-09-14 at 21:21 +0800, xinlei@mediatek.com wrote:
> > From: Xinlei Lee
> >
> > Add the compatible because use edge_cfg_in_mmsys in mt8186.
> >
> > Signed-off-by: Xinlei Lee
> > ---
> >
On Wed, 2022-09-21 at 09:35 +0800, CK Hu wrote:
> Hi, Xinlei:
>
> On Wed, 2022-09-14 at 21:21 +0800, xinlei@mediatek.com wrote:
> > From: Xinlei Lee
> >
> > Dpi output needs to adjust the output format to dual edge for
> > MT8186.
> > The bridge ic on MT8186 uses the output format of
> >
Hi
Am 05.08.22 um 02:19 schrieb Benjamin Herrenschmidt:
On Wed, 2022-07-20 at 16:27 +0200, Thomas Zimmermann wrote:
+#if !defined(CONFIG_PPC)
+static inline void out_8(void __iomem *addr, int val)
+{ }
+static inline void out_le32(void __iomem *addr, int val)
+{ }
+static inline unsigned int
Hi Badal,
> +struct hwm_reg {
> +};
> +
> +struct hwm_drvdata {
> + struct i915_hwmon *hwmon;
> + struct intel_uncore *uncore;
> + struct device *hwmon_dev;
> + char name[12];
> +};
> +
> +struct i915_hwmon {
> + struct hwm_drvdata ddat;
> + struct mutex hwmon_lock;
Hi
Am 05.08.22 um 02:22 schrieb Benjamin Herrenschmidt:
On Tue, 2022-07-26 at 16:40 +0200, Michal Suchánek wrote:
Hello,
On Tue, Jul 26, 2022 at 03:38:37PM +0200, Javier Martinez Canillas wrote:
On 7/20/22 16:27, Thomas Zimmermann wrote:
Add a per-model device-function structure in
> > Or of course we could just actually use native endian and detect from
> > the magic which endian is in use. That would require ripping out the
> > cpu_to_lexx() calls in Linux and making the user space tool more
> > intelligent. I'm happy with that, but it's pushing the complexity onto Mesa.
>
Hi Daniel,
Thank you for this info, we will fix this issue.
Almost miss this mail, sorry!
-Yonghua
> -Original Message-
> From: Daniel Vetter
> Sent: Wednesday, August 10, 2022 20:20
> To: Huang, Yonghua
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
>
On 9/16/2022 8:30 PM, Badal Nilawar wrote:
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2:
- Updated the date and kernel version in feature description
v3:
- Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get
On Wed, Sep 21, 2022 at 4:48 AM ChiaEn Wu wrote:
> On Sun, Sep 18, 2022 at 3:22 AM Han Jingoo wrote:
> > On Mon, Aug 29, 2022 ChiaEn Wu wrote:
> > > +#define MT6370_ITORCH_MIN_uA 25000
> > > +#define MT6370_ITORCH_STEP_uA 12500
> > > +#define MT6370_ITORCH_MAX_uA
On 9/16/2022 8:30 PM, Badal Nilawar wrote:
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are
1 - 100 of 171 matches
Mail list logo
