The !ATOMIC_IOMAP version of io_maping_init_wc will always return
success, even when the ioremap fails.
Since the ATOMIC_IOMAP version returns NULL when the init fails, and
callers check for a NULL return on error this is unexpected.
During a device probe, where the ioremap failed, a crash can
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #79 from mn...@protonmail.com ---
(In reply to Kees Cook from comment #78)
> (In reply to mnrzk from comment #76)
> > If my understanding is correct, base would have previously been filled with
> > the freelist pointer (since it's the
On Tue, Jul 21, 2020 at 7:46 PM Thomas Hellström (Intel)
wrote:
>
>
> On 2020-07-21 15:59, Christian König wrote:
> > Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel):
> ...
> >> Yes, we can't do magic. As soon as an indefinite batch makes it to
> >> such hardware we've lost. But since we
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #78 from Kees Cook (k...@outflux.net) ---
(In reply to mnrzk from comment #76)
> If my understanding is correct, base would have previously been filled with
> the freelist pointer (since it's the first 8 bytes). Now since the freelist
Applied. Thanks!
Alex
On Fri, Jul 17, 2020 at 8:23 AM Qiu Wenbo wrote:
>
> Avoid kernel crash when vddci_control is SMU7_VOLTAGE_CONTROL_NONE and
> vddci_voltage_table is empty. It has been tested on Intel Hades Canyon
> (i7-8809G).
>
> Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208489
>
Hi Lucas,
Thank you for following up on this. Some things have slowed down,
given the world pandemic we've been experiencing this year.
I've had the design ready and half of it implemented and committed
into a branch. Just as per what I wrote earlier this year on this thread.
I need to finish
On Mon, Jul 20, 2020 at 05:40:10PM -0700, Almahallawy, Khaled wrote:
> On Mon, 2020-07-20 at 17:07 -0700, Manasi Navare wrote:
> > On Mon, Jul 20, 2020 at 04:41:25PM -0700, Khaled Almahallawy wrote:
> > > Add the missing CP2520 pattern 2 and 3 phy compliance patterns
> > >
> > > Signed-off-by:
Fixes the following W=1 kernel build warning(s):
drivers/scsi/lpfc/lpfc_mem.c:85: warning: Function parameter or member 'align'
not described in 'lpfc_mem_alloc'
Cc: James Smart
Cc: Dick Kennedy
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/scsi/lpfc/lpfc_sli.c:257: warning: Function parameter or member 'mqe'
not described in 'lpfc_sli4_mq_put'
drivers/scsi/lpfc/lpfc_sli.c:257: warning: Excess function parameter 'wqe'
description in 'lpfc_sli4_mq_put'
This matches some of the other headers in the file.
Fixes the following W=1 kernel build warning(s):
drivers/scsi/csiostor/csio_lnode.c:2079: warning: Function parameter or member
'hw' not described in 'csio_lnode_init'
drivers/scsi/csiostor/csio_lnode.c:2079: warning: Function parameter or
Fixes the following W=1 kernel build warning(s):
drivers/scsi/lpfc/lpfc_sli.c: In function ‘lpfc_wq_create’:
drivers/scsi/lpfc/lpfc_sli.c:15810:16: warning: variable ‘pg_addr’ set but not
used [-Wunused-but-set-variable]
15810 | unsigned long pg_addr;
| ^~~
Cc: James Smart
Cc: Dick
'pg_addr' is only used when CONFIG_X86 is defined. So only declare it
if CONFIG_X86 is defined.
Fixes the following W=1 kernel build warning(s):
drivers/scsi/lpfc/lpfc_sli.c: In function ‘lpfc_wq_create’:
drivers/scsi/lpfc/lpfc_sli.c:15813:16: warning: unused variable ‘pg_addr’
On 2020-07-21 15:59, Christian König wrote:
Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel):
...
Yes, we can't do magic. As soon as an indefinite batch makes it to
such hardware we've lost. But since we can break out while the batch
is stuck in the scheduler waiting, what I believe we
>-Original Message-
>From: Andrew Morton
>Sent: Tuesday, July 21, 2020 4:57 PM
>To: Ruhl, Michael J
>Cc: dri-devel@lists.freedesktop.org; Mike Rapoport ;
>Andy Shevchenko ; Chris Wilson
>; sta...@vger.kernel.org
>Subject: Re: [PATCH v2] io-mapping: Indicate mapping failure
>
>On Tue, 21
https://bugzilla.kernel.org/show_bug.cgi?id=207383
Jeremy Kescher (jer...@kescher.at) changed:
What|Removed |Added
CC||jer...@kescher.at
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #75 from Kees Cook (k...@outflux.net) ---
Hi!
First, let me say sorry for all the work my patch has caused! It seems like it
might be tickling another (previously dormant) bug in the gpu driver.
(In reply to mnrzk from comment #30)
On Tue, 21 Jul 2020 21:02:44 + "Ruhl, Michael J"
wrote:
> >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
> >+++ a/include/linux/io-mapping.h
> >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> >resource_size_t base,
> >
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 7173949df4548299ee6c63736f76247d3f288cd4
commit: f6668a70defec83ec0c837e052dd5490b66068d3 [1133/1153] drm/amdgpu: add
timeout flush mechanism to update wptr for self interrupt
config: alpha-allmodconfig (attached
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #76 from mn...@protonmail.com ---
(In reply to Kees Cook from comment #75)
> Hi!
>
> First, let me say sorry for all the work my patch has caused! It seems like
> it might be tickling another (previously dormant) bug in the gpu
>
> >> That's also why I'm not positive on the "no hw preemption, only
> >> scheduler" case: You still have a dma_fence for the batch itself,
> >> which means still no userspace controlled synchronization or other
> >> form of indefinite batches allowed. So not getting us any closer to
> >>
On Tue, 2020-07-21 at 12:00 -0400, Lyude Paul wrote:
> On Tue, 2020-07-21 at 18:27 +0300, Mika Westerberg wrote:
> > On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote:
> > > Sure thing. Also, feel free to let me know if you'd like access to one
> > > of
> > > the
> > > systems we saw
Hi list,
virtio-gpu is moving in the direction where BO pages are pinned for
the lifetime for simplicity. I am wondering if that is considered a
security issue in general, especially after running into the
description of the new DMABUF_MOVE_NOTIFY config option.
Most drivers do not have a
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #77 from Kees Cook (k...@outflux.net) ---
(Midair collision... you saw the same about the structure layout as I did.
Here's my comment...)
(In reply to mnrzk from comment #30)
> I've been looking at this bug for a while now and I'll
On Tue, 21 Jul 2020 13:19:36 -0400 "Michael J. Ruhl"
wrote:
> The !ATOMIC_IOMAP version of io_maping_init_wc will always return
> success, even when the ioremap fails.
>
> Since the ATOMIC_IOMAP version returns NULL when the init fails, and
> callers check for a NULL return on error this is
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #74 from Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) ---
I sent a message to the LKML and amd-gfx list [1], asking Kees and Andrew on
how to proceed.
[1]: https://lkml.org/lkml/2020/7/21/729
"[Regression] hangs
Hi Bernard,
On Tue, Jul 21, 2020 at 08:24:05PM +0800, Bernard wrote:
>
> Hi:
>
> The function "int drm_panel_add(struct drm_panel *panel)" always returns
> true, this return value is meaningless.
> So I am planning to optimize this function to a non-return implementation,
> "void
On Tue, Jul 21, 2020 at 11:24 PM Andrew Morton
wrote:
>
> On Tue, 21 Jul 2020 21:02:44 + "Ruhl, Michael J"
> wrote:
>
> > >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
> > >+++ a/include/linux/io-mapping.h
> > >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
between commit:
5a2e9b658cdc ("dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml")
from the drm tree and commit:
382646090f7f ("dt-bindings:
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #82 from mn...@protonmail.com ---
(In reply to Kees Cook from comment #81)
> I assume this is the change, BTW:
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
>
On Tue, 21 Jul 2020 at 18:47, Thomas Hellström (Intel)
wrote:
>
>
> On 7/21/20 9:45 AM, Christian König wrote:
> > Am 21.07.20 um 09:41 schrieb Daniel Vetter:
> >> On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel)
> >> wrote:
> >>> Hi,
> >>>
> >>> On 7/9/20 2:33 PM, Daniel Vetter
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #80 from Kees Cook (k...@outflux.net) ---
(In reply to mnrzk from comment #79)
> I wonder if there's any way to set a watchpoint to see where exactly the
> dm_atomic_state gets filled with garbage data.
mm/slub.c set_freepointer()
Hi all,
[I can't find a previous email about this, sorry ...]
There is a semantic conflict between Linus' tree and the amdgpu tree
between commit
d7a6634a4cfb ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir")
from Linus' tree and commts
fe098a5d6443 ("drm/amdgpu/atomfirmware:
The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
and 6.18 inches size. It is found in some of the Poco F1 phones.
Signed-off-by: Sumit Semwal
Change-Id: I401dfbfe23ff2d806c956002f45e349cb9688c16
---
v2: remove ports node, making port@0 directly under panel@0 node.
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support
for the same.
Most of the panel data is taken from downstream panel dts, and is converted to
drm-panel based driver by me.
It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other
dependent patches is
On Tue, Jul 21, 2020 at 4:46 PM Christian König
wrote:
>
> Am 21.07.20 um 11:24 schrieb dan...@ffwll.ch:
> > On Tue, Jul 21, 2020 at 09:32:40AM +0200, Christian König wrote:
> >> The driver doesn't expose any not-mapable memory resources.
> >>
> >> Signed-off-by: Christian König
> >> ---
> >>
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #81 from Kees Cook (k...@outflux.net) ---
I assume this is the change, BTW:
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index d61186ff411d..2b8da2b17a5d 100644
On Fri, Jun 26, 2020 at 7:11 PM Manasi Navare wrote:
>
> From: Bhanuprakash Modem
>
> v3:
> * Rebase (Manasi)
> v2:
> * Rebase (Manasi)
>
> As both VRR min and max are already part of drm_display_info,
> drm can expose this VRR range for each connector.
>
> Hence this logic should move to core
+Christian who added DMABUF_MOVE_NOTIFY which added the relevant blurb:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma-buf/Kconfig#n46
Currently, the user seems to amdgpu for P2P dma-buf and it seems to plumb
ttm (*move_notify) callback to dma-buf. We're not
On Tue, Jul 07, 2020 at 11:04:03AM -0700, Randy Dunlap wrote:
> Drop doubled word "new".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Wolfram Sang
> Cc: linux-...@vger.kernel.org
Reviewed-by: Wolfram Sang
signature.asc
Description: PGP
Hi
Am 20.07.20 um 21:18 schrieb Lyude Paul:
> On Mon, 2020-07-20 at 09:04 +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 17.07.20 um 00:43 schrieb Lyude Paul:
>>> On Wed, 2020-07-15 at 16:59 +0200, Thomas Zimmermann wrote:
This patch adds support for G200 desktop cards. We can reuse the
Implementing those is completely unecessary.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 5 -
drivers/gpu/drm/drm_gem_vram_helper.c | 5 -
drivers/gpu/drm/qxl/qxl_ttm.c | 6 --
drivers/gpu/drm/radeon/radeon_ttm.c| 5
Fixes the following kernel build warning:
drivers/video/backlight/cr_bllcd.c: In function ‘cr_backlight_set_intensity’:
drivers/video/backlight/cr_bllcd.c:62:6: warning: unused variable ‘intensity’
[-Wunused-variable]
62 | int intensity = bd->props.brightness;
| ^
Cc: Sam Ravnborg
Quoting Tanmay Shah (2020-06-30 12:51:51)
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index 31b9217bb5bf..271d55db62ab 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -2440,6 +2447,44 @@
commit 2cd7b6f08bc4 ("drm/virtio: add in/out fence support
for explicit synchronization") deleted dma_fence_put(),
which will cause the memory leak. To balance the reference
count initialized when allocating fence, dma_fence_put()
should not be deleted.
Fixes: 2cd7b6f08bc4 ("drm/virtio: add
On Tue, Jul 21, 2020 at 05:33:00AM +, Sidong Yang wrote:
> Hi, Daniel and Melissa
>
> I tested some code for this problem trying to find the code that make problem
> in igt test.
> kms_cursor_crc test in igt test has 3 steps (preparation, test, cleanup). I
> check each steps
> and I found
Nouveau is the only user of this functionality and evicting io space
on -EAGAIN is really a misuse of the return code.
Instead switch to using -ENOSPC here which makes much more sense and
simplifies the code.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 --
The driver does support some not-mapable resources, but
those are already handled correctly in the switch/case
statement in the code.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
Not used any more. And it is bad design to use a TTM flag
to do a check inside a driver.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_driver.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index
Just use the use_io_reserve_lru flag. It doesn't make much
sense to have two flags.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
drivers/gpu/drm/ttm/ttm_bo.c | 1 -
drivers/gpu/drm/ttm/ttm_bo_util.c| 8
include/drm/ttm/ttm_bo_driver.h
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index
The original intention was to avoid CPU page table unmaps
when BOs move between the GTT and SYSTEM domain.
The problem is that this never correctly handled changes
in the caching attributes or backing pages.
Just drop this for now and simply unmap the CPU page
tables in all cases.
The driver doesn't expose any not-mapable memory resources.
v2: remove unused man variable as well
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_ttm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c
Only functional change is to always keep io_reserved_count up to date
for debugging even when it is not used otherwise.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 97 +++
1 file changed, 48 insertions(+), 49 deletions(-)
diff --git
The driver doesn't expose any not-mapable memory resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel) wrote:
> Hi,
>
> On 7/9/20 2:33 PM, Daniel Vetter wrote:
> > Comes up every few years, gets somewhat tedious to discuss, let's
> > write this down once and for all.
> >
> > What I'm not sure about is whether the text should be
Hi Lee.
On Tue, Jul 21, 2020 at 08:39:19AM +0100, Lee Jones wrote:
> Fixes the following kernel build warning:
>
> drivers/video/backlight/cr_bllcd.c: In function ‘cr_backlight_set_intensity’:
> drivers/video/backlight/cr_bllcd.c:62:6: warning: unused variable
> ‘intensity’
On Mon, Jul 20, 2020 at 03:07:35PM -0400, Lyude Paul wrote:
> This one's easy - we're already calling kzalloc() in this function, so
Nit: "kzalloc(GFP_KERNEL)", since kzalloc(GFP_ATOMIC) is perfectly fine in
interrupt context. With that clarified for the entire series:
Reviewed-by: Daniel Vetter
Am 21.07.20 um 09:41 schrieb Daniel Vetter:
On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel) wrote:
Hi,
On 7/9/20 2:33 PM, Daniel Vetter wrote:
Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.
What I'm not sure about is
On Tue, Jul 21, 2020 at 09:32:35AM +0200, Christian König wrote:
> Implementing those is completely unecessary.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 5 -
> drivers/gpu/drm/drm_gem_vram_helper.c | 5 -
Sorry, I once more forgot the cover letter.
This is just some cleanup all over drivers using TTM.
The only important functional change is the removal of the CMA (Can't
Map Aperture) flag since this might be a bug fix.
Please review and/or comment,
Christian.
Am 21.07.20 um 09:32 schrieb
Hi Dan,
Le lun. 20 juil. 2020 à 10:22, dan.carpen...@oracle.com a écrit :
Hello Paul Cercueil,
The patch fc1acf317b01: "drm/ingenic: Add support for the IPU" from
Jul 16, 2020, leads to the following static checker warning:
drivers/gpu/drm/ingenic/ingenic-drm-drv.c:232
On 20-07-20, 08:03, Rob Clark wrote:
> On Mon, Jul 20, 2020 at 3:01 AM Viresh Kumar wrote:
> >
> > On 15-07-20, 08:36, Rob Clark wrote:
> > > I can take the first two into msm-next, the 3rd will need to wait
> > > until dev_pm_opp_set_bw() lands
> >
> > You can base that on a8351c12c6c7 in
On 2020-07-20 17:31, Rajendra Nayak wrote:
Its possible for msm_dsi_host_init() to fail early, before
dev_pm_opp_set_clkname() is called. In such cases, unconditionally
calling dev_pm_opp_put_clkname() in msm_dsi_host_destroy() results
in a crash. Put an additional check so that
Quoting harig...@codeaurora.org (2020-06-29 06:50:09)
> On 2020-06-25 06:37, Stephen Boyd wrote:
> > Quoting Harigovindan P (2020-02-17 00:58:42)
> >> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> >> b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> >> index 388f50ad4fde..349db8fe78a5 100644
>
Some displays need the low end of the curve cropped in order to make
them happy. In that case we still want to have the 0% point, even though
anything between 0% and 5%(example) would be skipped.
Signed-off-by: Alexandru Stan
---
drivers/video/backlight/pwm_bl.c | 8
1 file changed, 8
Quoting Kuogee Hsieh (2020-07-07 11:41:25)
> add event thread to execute events serially from event queue. Also
> timeout mode is supported which allow an event be deferred to be
> executed at later time. Both link and phy compliant tests had been
> done successfully.
>
> This change depends-on
> … To balance the reference
> count initialized when allocating fence, dma_fence_put()
> should not be deleted.
* Would an imperative wording be more appropriate for the change description?
* Is the information “hexin” sufficient for a real name?
Regards,
Markus
Hi Alex:
On 7/19/20 4:03 AM, Alex Bee wrote:
This patch adds dither_up, dsp_lut_en, data_blank and dsp_data_swap
registers to enable their respective functionality for RK3188's VOP.
Signed-off-by: Alex Bee
---
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 4
1 file changed, 4
Use kthread_create_worker to simplify the code and optimise
the manager struct: msm_drm_thread. With this change, we
could remove struct element (struct task_struct *thread &
struct kthread_worker worker), instead, use one point (struct
kthread_worker *worker).
Signed-off-by: Bernard Zhao
---
On 2020-07-20 13:18, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2020-07-07 11:41:25)
add event thread to execute events serially from event queue. Also
timeout mode is supported which allow an event be deferred to be
executed at later time. Both link and phy compliant tests had been
done
On 7/15/20 7:35 AM, Jim Quinlan wrote:
> Patchset Summary:
> Enhance a PCIe host controller driver. Because of its unusual design
> we are foced to change dev->dma_pfn_offset into a more general role
> allowing multiple offsets. See the 'v1' notes below for more info.
Christoph, Robin,
Quoting khs...@codeaurora.org (2020-07-20 15:48:13)
> On 2020-07-20 13:18, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2020-07-07 11:41:25)
> >> drivers/gpu/drm/msm/dp/dp_power.c | 32 +-
> >> drivers/gpu/drm/msm/dp/dp_power.h | 1 +
> >> drivers/gpu/drm/msm/dp/dp_reg.h
On 7/3/20 4:41 PM, Samuel Iglesias Gonsálvez wrote:
> Hi,
>
> In the last meeting, X.Org Foundation board has decided that XDC 2020
> will be a virtual conference, given the uncertain COVID-19 situation in
> Europe by September, including the possibility of a second wave,
> outbreaks and travel
Hello,
syzbot found the following issue on:
HEAD commit:4fa640dc Merge tag 'vfio-v5.8-rc7' of git://github.com/awi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17ec2d5890
kernel config: https://syzkaller.appspot.com/x/.config?x=575b381064b1cba2
On 15-07-20, 08:36, Rob Clark wrote:
> I can take the first two into msm-next, the 3rd will need to wait
> until dev_pm_opp_set_bw() lands
You can base that on a8351c12c6c7 in linux-next, I will make sure not to rebase
it anymore.
--
viresh
___
On 2020-07-16 03:49, Rob Clark wrote:
From: Rob Clark
If split-lm is used (for ex, on sdm845), we can have multiple ping-
pongs, but only a single phys encoder. We need to configure dithering
on each of them.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 22
A use-after-free in drm_gem_open_ioctl can happen if the
GEM object handle is closed between the idr lookup and
retrieving the size from said object since a local reference
is not being held at that point. Hold the local reference
while the object can still be accessed to fix this and
plug the
I was trying to adjust the brightness for a new chromebook:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2291209
Like a lot of panels, the low end needs to be cropped,
and now that we have the interpolation stuff I wanted to make use of it
and bake in even the curve.
* I suggest to add a change description.
* Is “hexin.op” a real name?
Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Alex:
On 7/20/20 10:46 PM, Alex Bee wrote:
Hi Andy,
Am 20.07.20 um 10:22 schrieb Andy Yan:
Hi Alex:
On 7/19/20 4:03 AM, Alex Bee wrote:
This patch adds dither_up, dsp_lut_en, data_blank and dsp_data_swap
registers to enable their respective functionality for RK3188's VOP.
Signed-off-by:
Hi Andy,
Am 21.07.20 um 03:17 schrieb Andy Yan:
Hi Alex:
On 7/20/20 10:46 PM, Alex Bee wrote:
Hi Andy,
Am 20.07.20 um 10:22 schrieb Andy Yan:
Hi Alex:
On 7/19/20 4:03 AM, Alex Bee wrote:
This patch adds dither_up, dsp_lut_en, data_blank and dsp_data_swap
registers to enable their
On Fri, 17 Jul 2020 20:32:44 +0100 Chris Wilson wrote:
>
>
> Quoting Jisheng Zhang (2020-07-17 07:11:38)
> > The i915 doesn't depend on IOSF_MBI, asm/iosf_mbi.h already defines
> > isof_mbi_* APIs when ISOF_MBI is disabled.
> >
> > Don't force IOSF_MBI to allow disabling IOSF_MBI for non SoC
Hi Andy,
Am 20.07.20 um 10:22 schrieb Andy Yan:
Hi Alex:
On 7/19/20 4:03 AM, Alex Bee wrote:
This patch adds dither_up, dsp_lut_en, data_blank and dsp_data_swap
registers to enable their respective functionality for RK3188's VOP.
Signed-off-by: Alex Bee
---
Whenever num-interpolated-steps was larger than the distance
between 2 consecutive brightness levels the table would get really
discontinuous. The slope of the interpolation would stick with
integers only and if it was 0 the whole line segment would get skipped.
Example settings:
On 2020-07-20 17:47, Rajendra Nayak wrote:
Its possible that dpu_bind() fails early enough before
dev_pm_opp_set_clkname() is called. In such cases, unconditionally
calling dev_pm_opp_put_clkname() in dpu_unbind() can result in
a crash. Put an additional check so that dev_pm_opp_put_clkname()
is
Hi Linus.
On Mon, Jul 20, 2020 at 10:35:05PM +0200, Linus Walleij wrote:
> This adds device tree bindings for the Kinetic KTD253
> white LED backlight driver.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij
See a few comments in the following.
Sam
> ---
>
Hi Andrey,
Am Mittwoch, den 12.02.2020, 11:33 -0500 schrieb Andrey Grodzovsky:
> On 2/11/20 7:53 PM, Luben Tuikov wrote:
> > On 2020-02-11 4:27 p.m., Andrey Grodzovsky wrote:
> > > On 2/11/20 10:55 AM, Andrey Grodzovsky wrote:
> > > > On 2/10/20 4:50 PM, Luben Tuikov wrote:
> > > > > Hi Lucas,
>
Hi Dillon
On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:
From: dillon min
V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
for SPI_SIMPLEX_RX mode on stm32 spi controller.
V5:
1 instead of add send dummy data out under SIMPLEX_RX mode,
add flags
From: Qi Liu
We should put the reference count of the fence after calling
virtio_gpu_cmd_submit(). So add the missing dma_fence_put().
Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit
synchronization")
Co-developed-by: Xin He
Signed-off-by: Xin He
Signed-off-by: Qi Liu
Hi Alexandre,
On Tue, Jul 21, 2020 at 5:19 PM Alexandre Torgue
wrote:
>
> Hi Dillon
>
> On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:
> > From: dillon min
> >
> > V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
> > for SPI_SIMPLEX_RX mode on stm32 spi controller.
> >
On Mon, Jul 20, 2020 at 08:10:26PM -0600, Rob Herring wrote:
> On Tue, Jul 14, 2020 at 03:13:01PM +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai
> >
> > Some LCD panels do not support 24-bit true color, or 8bits per channel
> > RGB. Many low end ones only support up to 6 bits per channel
On Mon, Jul 20, 2020 at 10:35:05PM +0200, Linus Walleij wrote:
> This adds device tree bindings for the Kinetic KTD253
> white LED backlight driver.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij
> ---
> .../leds/backlight/kinetic,ktd253.yaml| 48 +++
>
ipu_mbus_code_to_colorspace, ipu_stride_to_bytes, and
ipu_pixelformat_is_planar are unused. Remove them.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 67 -
include/video/imx-ipu-v3.h | 3 --
2 files changed, 70 deletions(-)
diff --git
Hi Laurentiu,
On Tue, 2020-07-21 at 13:20 +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu
>
> This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> Some of its capabilities include:
> * 4K@60fps;
> * HDR10;
> * one graphics and 2 video pipelines;
> * on-the-fly
This is the same code and comment that is already shared by imx-ldb,
imx-tve, and parallel-display in imx_drm_encoder_parse_of().
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git
The drm_panel_attach/detach() functions are empty since
commit aa6c43644bc5 ("drm/panel: drop drm_device from drm_panel"),
remove them.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-ldb.c | 10 --
drivers/gpu/drm/imx/parallel-display.c | 6 --
2 files changed,
Hello Rob,
Thanks for the review!
On Tue, 21 Jul 2020 at 09:03, Rob Herring wrote:
>
> On Thu, Jul 16, 2020 at 09:08:57PM +0530, Sumit Semwal wrote:
> > The nt36672a panel from Tianma is a FHD+ panel with a resolution of
> > 1080x2246
> > and 6.18 inches size. It is found in some of the Poco F1
Hi all,
I traced the subtests' execution to figure out what happens (or not) in
a clean run and a blocked run, and this led me to suspect the
vkms_crtc_atomic_flush function. Examining the code and considering the
DRM doc, it seemed to me that a drm_crtc_vblank_get call was missing a
1 - 100 of 167 matches
Mail list logo
