From: Guangming Cao
Add a refcount for kernel to prevent UAF(Use After Free) issue.
We can assume a case like below:
1. kernel space alloc dma_buf(file count = 1)
2. kernel use dma_buf to get fd(file count = 1)
3. userspace use fd to do mapping (file count = 2)
4. kernel call dma
Hi
Am 14.07.21 um 06:14 schrieb Zack Rusin:
From: Martin Krastev
* Add support for CursorMob
* Add support for CursorBypass 4
Reviewed-by: Zack Rusin
Signed-off-by: Martin Krastev
Signed-off-by: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 45 +++-
drivers/gpu/drm/vm
On Tue, 13 Jul 2021 09:54:35 -0400
Harry Wentland wrote:
> On 2021-07-13 3:52 a.m., Pekka Paalanen wrote:
> > On Mon, 12 Jul 2021 12:15:59 -0400
> > Harry Wentland wrote:
> >
> >> On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:
> >>> On Fri, 9 Jul 2021 18:23:26 +0200
> >>> Raphael Gallais-Po
Hello,
syzbot found the following issue on:
HEAD commit:3dbdb38e Merge branch 'for-5.14' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1323c40230
kernel config: https://syzkaller.appspot.com/x/.config?x=a1fcf15a09815757
das
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
arch/arm/boot/dts/mt2701.dtsi | 2 --
arch/arm/boot/dts/mt7623n.dtsi | 5 -
2 files changed, 7 deletions(-)
diff --gi
..snip..
> > > I think the main question I have is how would you like to see patches for
> > > 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else?
> >
> > Yes that would be perfect. If there are any dependencies on the rc1, I
> > can rebase it on top of that.
>
> Yes, please,
From: Yongqiang Niu
Prepare for smi cleaning up "mediatek,larb".
Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device whose nodes has
"iommus" property, then display could help pm_runtime_get for smi via
ovl or rdma device.
CC:
When CONFIG_PROVE_LOCKING is defined, the kernel randomly injects
-EDEADLK errors for all the ww_mutex. This results in
drm_atomic_get_private_obj_state randomly returning -EDEADLK.
However, the mode_fixup functions do not propagate these error
codes and return false, causing the atomic commit to f
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Chun-
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Krzysztof Kozlowski
Acked-b
MediaTek IOMMU block diagram always like below:
M4U
|
smi-common
|
-
| | ...
| |
larb1 larb2
| |
vdec venc
All the consumer connect with smi-larb, then connect with smi-common.
When the consumer works, it should
Prepare for adding device_link.
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is
ready, then all the iommu consumer always is after the smi driver.
When
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should enab
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the property.
And IOMMU also know which larb this consumer connec
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
After removing the larb_get operations, then mtk_jpeg_clk_init is
also unnecessary. Remove it too.
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by:
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 --
2 fil
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Reviewed-
The user can pass in any value to the driver through the 'ioctl'
interface. The driver dost not check, which may cause DoS bugs.
The following log reveals it:
divide error: [#1] PREEMPT SMP KASAN PTI
RIP: 0010:SetOverlayViewPort+0x133/0x5f0
drivers/video/fbdev/kyro/STG4000OverlayDevice.c:47
Hi,
thanks for the patch
On 14.07.21 04:56, Yong Wu wrote:
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the
Commit 72a7cf0aec0c ("drm/amd/display: Keep linebuffer pixel depth at
30bpp for DCE-11.0.") doesn't seems to have fixed 10bit 4K rendering over
DisplayPort for CIK GPUs. On my machine with a HAWAII GPU I get a broken
image that looks like it has an effective resolution of 1920x1080 but
scaled up in
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec
On Sat, Jul 10, 2021 at 12:16:28AM +0300, Dmitry Osipenko wrote:
> Hello Thierry,
>
> 09.07.2021 22:31, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > Hi all,
> >
> > Mikko has been away for a few weeks, so I've been testing and revising
> > the new UABI patches in the meantime. There a
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
After removing the larb_get operations, then mtk_jpeg_clk_i
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
R
On 14.07.21 04:56, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong
On 14.07.21 04:56, Yong Wu wrote:
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Hi Xin,
On Wed, Jul 07, 2021 at 03:30:51PM +0800, Xin Ji wrote:
> On Thu, Jun 24, 2021 at 01:57:22PM +0200, Robert Foss wrote:
> > Hey Xin,
> >
> > I would like to merge this series now, but this patch needs a review
> > first. Maybe Laurent/Rob Herring are good candidates.
>
> Hi Rob, I get Laur
Hi Steven,
On Tue, Jul 13, 2021 at 05:16:16PM +0100, Steven Price wrote:
> On 12/07/2021 22:55, Laurent Pinchart wrote:
> > On Mon, Jul 12, 2021 at 10:31:52PM +0100, Steven Price wrote:
> >> On 12/07/2021 17:50, Laurent Pinchart wrote:
> >>> On Mon, Jul 12, 2021 at 04:57:58PM +0100, Steven Price w
Fix the missing pci_disable_device() before return
from bochs_pci_probe() in the error handling case.
Reported-by: Hulk Robot
Signed-off-by: Yang Yingliang
---
drivers/gpu/drm/tiny/bochs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bo
On 14.07.21 04:56, Yong Wu wrote:
From: Yongqiang Niu
Prepare for smi cleaning up "mediatek,larb".
Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device whose nodes has
"iommus" property, then display could help pm_runtime_g
Hi Sam,
Thank you for the patch.
On Tue, Jul 13, 2021 at 09:32:57PM +0200, Sam Ravnborg wrote:
> Make it obvious that mode_fixup is deprecated and new drivers shall use
> atomic_check.
Could you also mark drm_bridge_chain_mode_fixup() as deprecated ?
Regarding usage of .atomic_check(), while I
Am 14.07.21 um 09:11 schrieb guangming@mediatek.com:
From: Guangming Cao
Add a refcount for kernel to prevent UAF(Use After Free) issue.
Well NAK on so many levels.
We can assume a case like below:
1. kernel space alloc dma_buf(file count = 1)
2. kernel use dma_buf to get fd(
On 14.07.21 10:13, Dafna Hirschfeld wrote:
Hi,
thanks for the patch
On 14.07.21 04:56, Yong Wu wrote:
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
au
Am 13.07.21 um 17:28 schrieb Alex Deucher:
On Tue, Jul 13, 2021 at 2:57 AM Christian König
wrote:
Am 13.07.21 um 00:06 schrieb Felix Kuehling:
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings. Add a check for
vm_flags & VM_WRITE
Hi
Thanks for the patchset.
I tested it on mt8173 (elm) with chromeos userspace.
Before that patchset, the test:
tast -verbose run -build=false 10.42.0.175 video.DecodeAccel.h264
sometimes passed and sometimes failed with 'context deadline exceeded'.
With this patchset it seems that the test a
Hi,
sorry this (or the 2 depency-series) cause a NULL Pointer deref in
iommu_group_remove_device on mt7623/bpi-r2
i wonder why on bootup a cleanup is run, but have no hint about this.
since "dts: mtk-mdp: remove mediatek, vpu property from primary MDP device" all
is good, i guess problem comes
Hello Heiko,
On 7/13/21 10:49 AM, Heiko Stübner wrote:
> Hi Michael,
>
> Am Dienstag, 13. Juli 2021, 10:44:00 CEST schrieb Michael Riesch:
>> The HDMI TX block in the RK3568 requires two power supplies, which have
>> to be enabled in some cases (at least on the RK3568 EVB1 the voltages
>> VDDA0V9
Hi
Am 14.07.21 um 10:39 schrieb Yang Yingliang:
Fix the missing pci_disable_device() before return
from bochs_pci_probe() in the error handling case.
It's maybe better to replace pci_enable_device() with
pcim_enable_device(), [1] so that the release happens automatically.
Does this work?
B
On Wed, 2021-07-14 at 10:46 +0200, Christian König wrote:
> Am 14.07.21 um 09:11 schrieb guangming@mediatek.com:
> > From: Guangming Cao
> >
> > Add a refcount for kernel to prevent UAF(Use After Free) issue.
>
> Well NAK on so many levels.
>
> >
> > We can assume a case like below:
> >
On 07/12, Daniel Vetter wrote:
> Prep work for using the scheduler dependency handling. We need to call
> drm_sched_job_init earlier so we can use the new drm_sched_job_await*
> functions for dependency handling here.
>
> v2: Slightly better commit message and rebase to include the
> drm_sched_job
On 07/12, Daniel Vetter wrote:
> With the prep work out of the way this isn't tricky anymore.
>
> Aside: The chaining of the various jobs is a bit awkward, with the
> possibility of failure in bad places. I think with the
> drm_sched_job_init/arm split and maybe preloading the
> job->dependencies
As nwl_dsi.lanes is u32, and NSEC_PER_SEC is 10L, the second
multiplication in
dsi->lanes * 8 * NSEC_PER_SEC
will overflow on a 32-bit platform. Fix this by making the constant
unsigned long long, forcing 64-bit arithmetic.
As iMX8 is arm64, this driver is currently used on 64-bit p
Dear all,
The following patchset is a reimplementation of the patch sent by Jitao
Shi [1] some time ago. As suggested by Chun-Kuang Hu, this time the
reset is done using the reset API, where the mmsys driver is the reset
controller and the mtk_dsi driver is the reset consumer.
Note that the first
Update device tree binding documentation for the dsi to add the optional
property to reset the dsi controller.
Signed-off-by: Enric Balletbo i Serra
---
Changes in v2:
- Added a new patch to describe the dsi reset optional property.
.../devicetree/bindings/display/mediatek/mediatek,dsi.txt |
Reset dsi0 HW to default when power on. This prevents to have different
settingbetween the bootloader and the kernel.
As not all Mediatek boards have the reset consumer configured in their
board description, also is not needed on all of them, the reset is optional,
so the change is compatible with
The "resets" property is not present on R-Car Gen1 SoCs.
Supporting it would require migrating from renesas,cpg-clocks to
renesas,cpg-mssr.
Reflect this in the DT bindings by removing the global "required:
resets". All SoCs that do have "resets" properties already have
SoC-specific rules making i
On Wed, Jul 14, 2021 at 02:01:59PM +0800, Pi-Hsun Shih wrote:
> Use pm_runtime_force_suspend and pm_runtime_force_resume to ensure that
> anx7625 would always be powered off when suspended. Also update the
> bridge enable hook to always ensure that the anx7625 is powered on
> before starting DP ope
On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
> KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
> is_cow_mapping returns true for these mappings. Add a check for
> vm_flags & VM_WRITE to avoid mmap failures on private read-only or
> PROT_NONE mappings.
>
> v2: prot
On Wed, Jul 14, 2021 at 12:44:00PM +0200, Daniel Vetter wrote:
> On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
> > KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
> > is_cow_mapping returns true for these mappings. Add a check for
> > vm_flags & VM_WRITE to avoid mm
Am 14.07.21 um 12:44 schrieb Daniel Vetter:
On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings. Add a check for
vm_flags & VM_WRITE to avoid mmap failures on private read-on
On Wed, Jul 14, 2021 at 12:51:15PM +0200, Christian König wrote:
> Am 14.07.21 um 12:44 schrieb Daniel Vetter:
> > On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
> > > KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
> > > is_cow_mapping returns true for these mapping
On Tue, Jul 13, 2021 at 09:46:30PM +0300, Ville Syrjälä wrote:
> On Tue, Jul 13, 2021 at 07:24:23PM +0100, Matthew Auld wrote:
> > On Tue, 13 Jul 2021 at 18:47, Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Jul 13, 2021 at 05:13:37PM +0100, Matthew Auld wrote:
> > > > On Tue, 13 Jul 2021 at 16:55,
On Tue, Jul 13, 2021 at 11:45:54AM +0100, Matthew Auld wrote:
> EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
> possible for userspace to bypass the GTT caching bits set by the kernel,
> as per the given object cache_level. This is troublesome since the heavy
> flush we apply wh
> Gesendet: Mittwoch, 14. Juli 2021 um 13:18 Uhr
> Von: "Yong Wu"
> Hi Frank,
>
> Thanks for your report. mt7623 use mtk_iommu_v1.c.
>
> I will try to reproduce this locally.
Hi,
as far as i have debugged it dev->iommu_group is NULL, so it crashes on first
access (dev_info)
drivers/iommu/iommu
On Wed, 2021-07-14 at 12:43 +0200, Christian König wrote:
> Am 14.07.21 um 11:44 schrieb guangming@mediatek.com:
> > From: Guangming Cao
> >
> > On Wed, 2021-07-14 at 10:46 +0200, Christian König wrote:
> > > Am 14.07.21 um 09:11 schrieb guangming@mediatek.com:
> > > > From: Guangming Cao
On Wed, Jul 14, 2021 at 01:16:57PM +0200, Daniel Vetter wrote:
> On Tue, Jul 13, 2021 at 09:46:30PM +0300, Ville Syrjälä wrote:
> > On Tue, Jul 13, 2021 at 07:24:23PM +0100, Matthew Auld wrote:
> > > On Tue, 13 Jul 2021 at 18:47, Ville Syrjälä
> > > wrote:
> > > >
> > > > On Tue, Jul 13, 2021 at 0
Am 13.07.21 um 22:51 schrieb Daniel Vetter:
intel-gfx-ci realized that something is not quite coherent anymore on
some platforms for our i915+vgem tests, when I tried to switch vgem
over to shmem helpers.
After lots of head-scratching I realized that I've removed calls to
drm_clflush. And we nee
On 2021-07-14 10:19, Michael Riesch wrote:
Hello Heiko,
On 7/13/21 10:49 AM, Heiko Stübner wrote:
Hi Michael,
Am Dienstag, 13. Juli 2021, 10:44:00 CEST schrieb Michael Riesch:
The HDMI TX block in the RK3568 requires two power supplies, which have
to be enabled in some cases (at least on the
From: Guangming.Cao
On Wed, 2021-07-14 at 12:43 +0200, Christian K鰊ig wrote:
> Am 14.07.21 um 11:44 schrieb guangming@mediatek.com:
> > From: Guangming Cao
> >
> > On Wed, 2021-07-14 at 10:46 +0200, Christian K鰊ig wrote:
> > > Am 14.07.21 um 09:11 schrieb guangming@mediatek.com:
> > > >
On Wed, Jul 14, 2021 at 02:42:53PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 14, 2021 at 01:16:57PM +0200, Daniel Vetter wrote:
> > On Tue, Jul 13, 2021 at 09:46:30PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jul 13, 2021 at 07:24:23PM +0100, Matthew Auld wrote:
> > > > On Tue, 13 Jul 2021 at 18:47
Am 14.07.21 um 14:03 schrieb guangming@mediatek.com:
From: Guangming.Cao
On Wed, 2021-07-14 at 12:43 +0200, Christian K鰊ig wrote:
Am 14.07.21 um 11:44 schrieb guangming@mediatek.com:
From: Guangming Cao
On Wed, 2021-07-14 at 10:46 +0200, Christian K鰊ig wrote:
Am 14.07.21 um 09:11 s
The FIXED mapping is only used for ttm, and tells userspace that the
mapping type is pre-defined. This disables the other type of mmap
offsets when discrete memory is used, so fix the selftests as well.
Document the struct as well, so it shows up in docbook.
Cc: Jason Ekstrand
Reviewed-by: Danie
From: Guangming Cao
User space user can call DMA_BUF_SET_NAME to set dma_buf.name,
also add a kernel api for users to do same thing at kernel side.
Signed-off-by: Guangming Cao
---
drivers/dma-buf/dma-buf.c | 28 ++--
include/linux/dma-buf.h | 1 +
2 files changed, 2
Am 14.07.21 um 14:29 schrieb guangming@mediatek.com:
From: Guangming Cao
User space user can call DMA_BUF_SET_NAME to set dma_buf.name,
also add a kernel api for users to do same thing at kernel side.
Well if you want to add a kernel API to set the name you also need to
provide an user f
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking a
On Wed, Jul 14, 2021 at 01:54:50PM +0200, Christian König wrote:
> Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > intel-gfx-ci realized that something is not quite coherent anymore on
> > some platforms for our i915+vgem tests, when I tried to switch vgem
> > over to shmem helpers.
> >
> > After
On Tue, Jul 06, 2021 at 08:58:37AM +0200, Christian König wrote:
> Hi guys,
>
> yes nouveau was using the same functionality for internal BOs without
> noticing it. This is fixes by the following commit:
>
> commit d098775ed44021293b1962dea61efb19297b8d02
> Author: Christian König
> Date: Wed
On Wed, Jul 14, 2021 at 02:42:53PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 14, 2021 at 01:16:57PM +0200, Daniel Vetter wrote:
> > On Tue, Jul 13, 2021 at 09:46:30PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jul 13, 2021 at 07:24:23PM +0100, Matthew Auld wrote:
> > > > On Tue, 13 Jul 2021 at 18:47
Am 14.07.21 um 14:48 schrieb Daniel Vetter:
On Wed, Jul 14, 2021 at 01:54:50PM +0200, Christian König wrote:
Am 13.07.21 um 22:51 schrieb Daniel Vetter:
intel-gfx-ci realized that something is not quite coherent anymore on
some platforms for our i915+vgem tests, when I tried to switch vgem
over
Am 14.07.21 um 14:56 schrieb Kirill A. Shutemov:
On Tue, Jul 06, 2021 at 08:58:37AM +0200, Christian König wrote:
Hi guys,
yes nouveau was using the same functionality for internal BOs without
noticing it. This is fixes by the following commit:
commit d098775ed44021293b1962dea61efb19297b8d02
A
Am 14.07.21 um 13:15 schrieb Daniel Vetter:
On Wed, Jul 14, 2021 at 12:51:15PM +0200, Christian König wrote:
Am 14.07.21 um 12:44 schrieb Daniel Vetter:
On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping
Just a gentle ping. Or have I missed your reply?
Thanks,
Christian.
Am 09.07.21 um 14:07 schrieb Christian König:
Daniel pointed me towards this function and there are multiple obvious problems
in the implementation.
First of all the retry loop is not working as intended. In general the retry
Am 13.07.21 um 16:06 schrieb Rodrigo Siqueira:
The display core files rely on FPU operation, which requires to be
compiled with special flags. Ideally, we don't want these FPU operations
spread around the DC code; nevertheless, it happens in the current
source. This commit introduces a new direct
Am 13.07.21 um 16:06 schrieb Rodrigo Siqueira:
We don't have any mechanism for tracing FPU operations inside the
display core, making the debug work a little bit tricky. This commit
introduces a trace mechanism inside our DC_FP_START/END macros for
trying to alleviate this problem.
Signed-off-by
Am 13.07.21 um 16:06 schrieb Rodrigo Siqueira:
DC invokes DC_FPU_START/END in multiple parts of the code; this can
create a situation where we invoke this FPU operation in a nested way or
exit too early. For avoiding this situation, this commit adds a
mechanism where dc_fpu_begin/end manages the
Am 13.07.21 um 16:06 schrieb Rodrigo Siqueira:
To fully isolate FPU operations in a single place, we must avoid
situations where compilers spill FP values to registers due to FP enable
in a specific C file. Note that even if we isolate all FPU functions in
a single file and call its interface fro
Put the clock-selection code into each of the PLL-update functions to
make them select the correct pixel clock. Instead of copying the code,
introduce a new helper WREG_MISC_MASKED, which does masked writes into
. Use it from each individual PLL update function.
The pixel clock for video output wa
Am Donnerstag, dem 01.07.2021 um 00:50 +0200 schrieb Marek Vasut:
> On 6/29/21 10:02 AM, Lucas Stach wrote:
> > Am Dienstag, dem 29.06.2021 um 05:04 +0200 schrieb Marek Vasut:
> > > On 6/28/21 10:09 AM, Lucas Stach wrote:
> > > > Am Samstag, dem 26.06.2021 um 20:15 +0200 schrieb Marek Vasut:
> > >
When bailing out due to the sanity check the iterator value needs to be
freed because the early return prevents for_each_child_of_node() from
doing the dereference itself.
Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
Signed-off-by: Steven Price
---
drivers/gpu/drm/d
14.07.2021 11:30, Thierry Reding пишет:
> On Sat, Jul 10, 2021 at 12:16:28AM +0300, Dmitry Osipenko wrote:
>> Hello Thierry,
>>
>> 09.07.2021 22:31, Thierry Reding пишет:
>>> From: Thierry Reding
>>>
>>> Hi all,
>>>
>>> Mikko has been away for a few weeks, so I've been testing and revising
>>> the
https://bugzilla.kernel.org/show_bug.cgi?id=209457
--- Comment #34 from Leandro Jacques (ls...@yahoo.com) ---
Created attachment 297851
--> https://bugzilla.kernel.org/attachment.cgi?id=297851&action=edit
Linux Firmware version info 20210511.7685cf4
--
You may reply to this email to add a comm
https://bugzilla.kernel.org/show_bug.cgi?id=209457
Leandro Jacques (ls...@yahoo.com) changed:
What|Removed |Added
Attachment #297851|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=209457
--- Comment #36 from Leandro Jacques (ls...@yahoo.com) ---
Created attachment 297855
--> https://bugzilla.kernel.org/attachment.cgi?id=297855&action=edit
Kernel crash log for linux firmware version 20210511.7685cf4
Kernel log when crashed.
--
Convert the Solomon SSD1307 Framebuffer Device Tree binding
documentation to json-schema.
Fix the spelling of the "pwms" property.
Document default values.
Make properties with default values not required.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Rob Herring
---
v2:
- Add Reviewed-by,
Make ssd1307fb_update_display() return an error code, so callers that
can handle failures can propagate it.
Signed-off-by: Geert Uytterhoeven
---
drivers/video/fbdev/ssd1307fb.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.
Extract the code to set the column and page ranges into a helper
function.
Signed-off-by: Geert Uytterhoeven
---
drivers/video/fbdev/ssd1307fb.c | 61 +++--
1 file changed, 36 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video
Currently, each screen update triggers an I2C transfer of all screen
data, up to 1 KiB of data for a 128x64 display, which takes at least 20
ms in Fast mode.
Reduce the amount of transferred data by only updating the rectangle
that changed. Remove the call to ssd1307fb_set_address_range() during
Hi all,
This patch series optimizes console operations on ssd1307fb, after the
customary fixes and cleanups.
Currently, each screen update triggers an I2C transfer of all screen
data, up to 1 KiB of data for a 128x64 display, which takes at least 20
ms in Fast mode. While many displays a
Cache the column and page ranges, to avoid doing unneeded I2C transfers
when the values haven't changed.
Signed-off-by: Geert Uytterhoeven
---
drivers/video/fbdev/ssd1307fb.c | 52 +++--
1 file changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/video/fbd
Simplify the nested loops to handle conversion from linear frame buffer
to ssd1307 page layout:
1. Move last page handling one level up, as the value of "m" is the
same inside a page,
2. array->data[] is filled linearly, so there is no need to
recalculate array_idx over and over again
On Wed, Jul 14, 2021 at 03:02:21PM +0200, Christian König wrote:
> Am 14.07.21 um 14:56 schrieb Kirill A. Shutemov:
> > On Tue, Jul 06, 2021 at 08:58:37AM +0200, Christian König wrote:
> > > Hi guys,
> > >
> > > yes nouveau was using the same functionality for internal BOs without
> > > noticing i
Am 14.07.21 um 16:54 schrieb Zheyu Ma:
When calling ttm_range_man_fini(), 'man' may be uninitialized, which may
cause a null pointer dereference bug.
Fix this by checking if it is a null pointer.
It would be better if the driver doesn't try to fini a manager which was
never initialized, but f
On 7/14/21 5:50 PM, Dmitry Osipenko wrote:
14.07.2021 11:30, Thierry Reding пишет:
On Sat, Jul 10, 2021 at 12:16:28AM +0300, Dmitry Osipenko wrote:
Hello Thierry,
09.07.2021 22:31, Thierry Reding пишет:
From: Thierry Reding
Hi all,
Mikko has been away for a few weeks, so I've been testing
Hi Steven,
Thank you for the patch.
On Wed, Jul 14, 2021 at 03:33:00PM +0100, Steven Price wrote:
> When bailing out due to the sanity check the iterator value needs to be
> freed because the early return prevents for_each_child_of_node() from
> doing the dereference itself.
>
> Fixes: 652900752
Hi Geert,
On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> This patch series optimizes console operations on ssd1307fb, after the
> customary fixes and cleanups.
What is required to to have a drm driver that could do the same?
Note: I will take a look at t
From: Sean Paul
Avoids the following WARN:
[3.009556] [ cut here ]
[3.014306] WARNING: CPU: 7 PID: 109 at
drivers/gpu/drm/drm_dp_helper.c:1796 drm_dp_aux_register+0xa4/0xac
[3.024209] Modules linked in:
[3.027351] CPU: 7 PID: 109 Comm: kworker/7:8 Not taint
Am 2021-07-14 um 6:51 a.m. schrieb Christian König:
> Am 14.07.21 um 12:44 schrieb Daniel Vetter:
>> On Mon, Jul 12, 2021 at 06:06:36PM -0400, Felix Kuehling wrote:
>>> KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
>>> is_cow_mapping returns true for these mappings. Add a check for
On 2021-07-14 3:35 a.m., Pekka Paalanen wrote:
> On Tue, 13 Jul 2021 09:54:35 -0400
> Harry Wentland wrote:
>
>> On 2021-07-13 3:52 a.m., Pekka Paalanen wrote:
>>> On Mon, 12 Jul 2021 12:15:59 -0400
>>> Harry Wentland wrote:
>>>
On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:
> O
1 - 100 of 194 matches
Mail list logo
