Am 16.07.20 um 07:44 schrieb Thomas Zimmermann:
> Hi
>
> Am 15.07.20 um 21:56 schrieb Dave Airlie:
>> On Thu, 16 Jul 2020 at 00:59, Thomas Zimmermann wrote:
>>>
>>> This patchset puts device initialization in the correct order and
>>> adds support for G200 Desktop chips (PCI ids 0x520 and
Hi
Am 15.07.20 um 21:56 schrieb Dave Airlie:
> On Thu, 16 Jul 2020 at 00:59, Thomas Zimmermann wrote:
>>
>> This patchset puts device initialization in the correct order and
>> adds support for G200 Desktop chips (PCI ids 0x520 and 0x521).
>
> why? :-)
With G200 support in place, we can add
On Wed, Jul 15, 2020 at 09:27:42PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/gpu/drm/i915/display/intel_combo_phy.c:268:3: warning: variable
> 'ret' is uninitialized when used here [-Wuninitialized]
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
>
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #65 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to Duncan from comment #63)
> NB: The 3202fa62f followups are cbfc35a48 and 89b83f282. That should let
> anyone else with git and kernel building skills try reverting the three.
>
Will try to look over this tomorrow, jfyi
On Wed, 2020-07-15 at 16:58 +0200, Thomas Zimmermann wrote:
> This patchset puts device initialization in the correct order and
> adds support for G200 Desktop chips (PCI ids 0x520 and 0x521).
>
> The first 7 patches prepare the driver. Desktop chips
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 ++-
Hi Dave, Daniel,
Fixes for 5.8.
The following changes since commit 38794a5465b752118098e36cf95c59083f9f1f88:
Merge tag 'amd-drm-fixes-5.8-2020-07-09' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-07-10 07:02:02
+1000)
are available in the Git repository at:
On Fri, 03 Jul 2020 13:47:17 +0200, Ondrej Jirman wrote:
> The display has one port. Allow it in the binding.
>
> Signed-off-by: Ondrej Jirman
> ---
> .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring
On Fri, 03 Jul 2020 13:47:16 +0200, Ondrej Jirman wrote:
> The example is now validated against rocktech,jh057n00900 schema
> that was ported to yaml, and didn't validate with:
>
> - '#address-cells', '#size-cells', 'port@0' do not match any of
> the regexes: 'pinctrl-[0-9]+'
> - 'vcc-supply'
On Wed, Jul 15, 2020 at 9:56 PM Dave Airlie wrote:
>
> On Thu, 16 Jul 2020 at 00:59, Thomas Zimmermann wrote:
> >
> > This patchset puts device initialization in the correct order and
> > adds support for G200 Desktop chips (PCI ids 0x520 and 0x521).
>
> why? :-)
>
> I'm pretty sure I NAKed the
On Tue, 30 Jun 2020 00:33:12 +0200, Sebastian Reichel wrote:
> Convert panel-dsi-cm bindings to YAML and add
> missing properties while at it.
>
> Signed-off-by: Sebastian Reichel
> ---
> .../bindings/display/panel/panel-dsi-cm.txt | 29 -
> .../bindings/display/panel/panel-dsi-cm.yaml
On Wed, Jul 15, 2020 at 12:07:30PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> If there is no interconnect-names, but there is an interconnects
> property, then of_icc_get(dev, "gfx-mem"); would return an error
> rather than NULL.
>
> Also, if there is no interconnect-names property, there
On Thu, 16 Jul 2020 at 00:59, Thomas Zimmermann wrote:
>
> This patchset puts device initialization in the correct order and
> adds support for G200 Desktop chips (PCI ids 0x520 and 0x521).
why? :-)
I'm pretty sure I NAKed the previous version because the userspace
experience for these old
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: d7373aaf738393f38f40b0570bfa1403584eb982
commit: 1f61a43fcec1dceac2ec537a63aba6846dd0e80a [140/193] drm/amd/sriov
porting sriov cap to vcn3.0
config: parisc-allyesconfig (attached as .config)
compiler: hppa-linux-gcc (GCC)
From: Rob Clark
If there is no interconnect-names, but there is an interconnects
property, then of_icc_get(dev, "gfx-mem"); would return an error
rather than NULL.
Also, if there is no interconnect-names property, there will never
be a ocmem path. But of_icc_get(dev, "ocmem") would return
https://bugzilla.kernel.org/show_bug.cgi?id=208573
--- Comment #2 from Thomas Langkamp (thomas.langk...@medicalschool-hamburg.de)
---
Created attachment 290305
--> https://bugzilla.kernel.org/attachment.cgi?id=290305=edit
dmesg just after plugging in second display
--
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=208573
--- Comment #3 from Thomas Langkamp (thomas.langk...@medicalschool-hamburg.de)
---
Created attachment 290307
--> https://bugzilla.kernel.org/attachment.cgi?id=290307=edit
xorg.log just after connecting second display
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=208413
ghutzr...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=208573
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
On Wed, Jul 15, 2020 at 11:37 AM Jonathan Marek wrote:
>
> On 7/15/20 2:29 PM, Rob Clark wrote:
> > From: Rob Clark
> >
> > If there is no interconnect-names, but there is an interconnects
> > property, then of_icc_get(dev, "gfx-mem"); would return an error
> > rather than NULL.
> >
> > Also, if
Hi Sam and Daniel,
Thank you very much for reviewing the code. I will squish all the commits and
send version 3, so it will be easier for you to review.
Anitha
> -Original Message-
> From: Sam Ravnborg
> Sent: Wednesday, July 15, 2020 10:07 AM
> To: Daniel Vetter
> Cc: Chrisanthus,
https://bugzilla.kernel.org/show_bug.cgi?id=208573
Bug ID: 208573
Summary: Black screen on boot if two displays plugged in with
NAVI 10
Product: Drivers
Version: 2.5
Kernel Version: 5.7.8-6-MANJARO
Hardware: x86-64
From: Rob Clark
If there is no interconnect-names, but there is an interconnects
property, then of_icc_get(dev, "gfx-mem"); would return an error
rather than NULL.
Also, if there is no interconnect-names property, there will never
be a ocmem path. But of_icc_get(dev, "ocmem") would return
On Mon, Jul 13, 2020 at 5:42 AM Akhil P Oommen wrote:
>
> From: Sharat Masetty
>
> This patch adds the interconnects property to the GPU node. This enables
> the GPU->DDR path bandwidth voting.
>
> Signed-off-by: Sharat Masetty
> Signed-off-by: Akhil P Oommen
> ---
>
On Sat, 13 Jun 2020 19:37:03 +0530, Kamlesh Gurudasani wrote:
> This adds binding for ilitek,ili9488 based display panels
>
> Signed-off-by: Kamlesh Gurudasani
> ---
> .../bindings/display/ilitek,ili9488.yaml | 71
> ++
> 1 file changed, 71 insertions(+)
> create
On Sat, 13 Jun 2020 19:36:46 +0530, Kamlesh Gurudasani wrote:
> Add vendor prefix for display manufacturer company EastRising
> Technology Co.,Ltd
>
> [1]https://eastrising.en.ec21.com/
>
> Signed-off-by: Kamlesh Gurudasani
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
On Tue, Jul 14, 2020 at 4:54 PM Bjorn Andersson
wrote:
>
> On Tue 14 Jul 15:13 PDT 2020, Rob Herring wrote:
>
> > On Tue, Jul 14, 2020 at 10:33 AM Jeffrey Hugo
> > wrote:
> > >
> > > On Mon, Jul 13, 2020 at 5:50 PM Doug Anderson
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Jul 13,
Hi Dave and Daniel,
here is the PR for the current drm-misc-fixes. The aspeed fix is only
about dmesg noise. The dmabuf locking appears to be a real bug.
Best regards
Thomas
drm-misc-fixes-2020-07-15:
* aspeed: setup fbdev console after registering device; avoids warning
and stacktrace in
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #64 from Anthony Ruhier (anthony.ruh...@gmail.com) ---
(In reply to Duncan from comment #63)
> (In reply to Duncan from comment #62)
> > I've applied the three 320-and-followups revert-patches to
> > v5.8-rc5-8-g0dc589da8 and just did
On Wed, Jul 15, 2020 at 05:05:49PM +0200, Daniel Vetter wrote:
> Hi Anitha
>
> On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> > This is a new DRM driver for Intel's KeemBay SOC.
> > The SoC couples an ARM Cortex A53 CPU with an Intel
> > Movidius VPU.
> >
> > This driver
Hi Anitha.
On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
>
> This driver is tested with the KMB EVM board which is the refernce baord
> for Keem Bay
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #63 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to Duncan from comment #62)
> I've applied the three 320-and-followups revert-patches to
> v5.8-rc5-8-g0dc589da8 and just did the rebuild with them applied.
> Now to reboot to it
Dave, Daniel,
vmwgfx-fixes pull for 5.8.
Just one fix for now, but it's a really important one, causing black
screens in VMs (sometimes on boot), hence marking it for stable.
The following changes since commit 1f054fd26e29784d373c3d29c348ee48f1c41fb2:
drm/vmwgfx: fix update of display surface
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #30 from Cyrax (ev...@hotmail.com) ---
The patch in https://bugzilla.kernel.org/show_bug.cgi?id=207979 works
beatifully.
19 days heavy usage without system crash on patched 5.7.6 kernel.
--
You are receiving this mail because:
You
On Wed, Jul 15, 2020 at 5:57 PM Melissa Wen wrote:
>
> On 07/15, Sidong Yang wrote:
> > On Wed, Jul 15, 2020 at 10:17:56AM +0200, Daniel Vetter wrote:
> > > On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen wrote:
> > > >
> > > > On 07/14, Daniel Vetter wrote:
> > > > > On Tue, Jul 14, 2020 at
https://bugzilla.kernel.org/show_bug.cgi?id=206987
Cyrax (ev...@hotmail.com) changed:
What|Removed |Added
Kernel Version|5.7.0 |5.7.6
--
You are receiving
On 07/15, Sidong Yang wrote:
> On Wed, Jul 15, 2020 at 10:17:56AM +0200, Daniel Vetter wrote:
> > On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen wrote:
> > >
> > > On 07/14, Daniel Vetter wrote:
> > > > On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > > > > On Tue, Jul 14, 2020 at
On Mon, Jul 13, 2020 at 5:41 AM Akhil P Oommen wrote:
>
> This series adds support for GPU DDR bandwidth scaling and is based on the
> bindings from Georgi [1]. This is mostly a rebase of Sharat's patches [2] on
> the
> tip of msm-next branch.
>
> Changes from v4:
> - Squashed a patch to another
On Wed, Jul 15, 2020 at 05:05:49PM +0200, Daniel Vetter wrote:
> Hi Anitha
>
> On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> > This is a new DRM driver for Intel's KeemBay SOC.
> > The SoC couples an ARM Cortex A53 CPU with an Intel
> > Movidius VPU.
> >
> > This driver
On Wed, Jul 15, 2020 at 11:02:58PM +0900, Tetsuo Handa wrote:
> On 2020/07/15 20:17, Tetsuo Handa wrote:
> > On 2020/07/15 18:48, Dan Carpenter wrote:
> >>> @@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_data *vc,
> >>> struct fb_info *info,
> >>> region.color = color;
> >>>
Hi Anitha
On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
>
> This driver is tested with the KMB EVM board which is the refernce baord
> for Keem Bay SOC.
This patchset puts device initialization in the correct order and
adds support for G200 Desktop chips (PCI ids 0x520 and 0x521).
The first 7 patches prepare the driver. Desktop chips would probably
work without them, but since we're at it we can also do it right.
Patch 1 enables cached page
This patch adds support for G200 desktop cards. We can reuse the whole
memory and modesetting code. A few PCI and DAC register values have to
be updated accordingly.
The most significant change is in the PLL setup. The get the clock limits
and reference clocks, parses the device's BIOS. With no
So far, PCI option registers were initialized as part of modesetting,
which is late in the process. As these registers control fundamental
operation, they should be set early.
The patch moves the PCI option handling into device register setup,
before even the device MMIO memory is being mapped.
MGA cards can run in traditional VGA mode or an enhanced MGA mode; with
the latter being required for KMS. So far, MGA mode was enabled during
modesetting. As it's fundamental for device operation, the patch moves
it next to the device register setup.
Signed-off-by: Thomas Zimmermann
---
The modesetting code initialized the memory-related register CRTCEXT4.
Move this code to MM initialization.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mm.c | 2 ++
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +-
2 files changed, 3 insertions(+), 5 deletions(-)
The modesetting code initialized several memory-related flags in the
MISC register. Move this code to MM initialization.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mm.c | 6 ++
drivers/gpu/drm/mgag200/mgag200_mode.c | 4 +---
2 files changed, 7 insertions(+), 3
The unique revision id is only useful for G200SE devices. Store the
value in model-specific data within struct mga_device. While at it,
the patch also adds an init helper for the value.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 19 +--
SHMEM pages use write-combine caching by default, but can also use the
platform's default page caching. Doing so may improve the performance
of I/O on the framebuffer.
Mgag200's hardware does not access framebuffer pages directly (i.e.,
via DMA), so enabling caching does not have an effect on
The mgag200 driver maps registers into the address space. Move the
code into a separate helper function. No functional changes.
One small difference is in the handling of SDRAM/SGRAM. MGA devices
can come with either SDRAM or SGRAM. So far, the driver checked for
SDRAM, which is the common case.
On Wed, Jul 15, 2020 at 4:37 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2020-07-15 15:03:34)
> > On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson
> > wrote:
> > > There's a further problem in that we call INIT_LIST_HEAD on the
> > > dma_fence_cb before the signal callback. So even if
Quoting Daniel Vetter (2020-07-15 15:03:34)
> On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson wrote:
> > There's a further problem in that we call INIT_LIST_HEAD on the
> > dma_fence_cb before the signal callback. So even if list_empty_careful()
> > confirms the dma_fence_cb to be completely
On Wed, Jul 15, 2020 at 3:34 PM Jani Nikula wrote:
>
>
> Argh, failed to mention:
>
> On Wed, 15 Jul 2020, Jani Nikula wrote:
> > Lee Shawn C (1):
> > drm/i915/mst: filter out the display mode exceed sink's capability
>
> The above depends on:
>
> > Lyude Paul (1):
> >
On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson wrote:
> Quoting Chris Wilson (2020-07-15 13:21:43)
> > Quoting Daniel Vetter (2020-07-15 13:10:22)
> > > On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > > > When waiting with a callback on the stack, we must remove the callback
> > >
On Wed, Jul 15, 2020 at 2:53 PM Liviu Dudau wrote:
>
> On Tue, Jul 07, 2020 at 10:12:12PM +0200, Daniel Vetter wrote:
> > Again needs to be put right after the call to
> > drm_atomic_helper_commit_hw_done(), since that's the last thing which
> > can hold up a subsequent atomic commit.
> >
> > No
Argh, failed to mention:
On Wed, 15 Jul 2020, Jani Nikula wrote:
> Lee Shawn C (1):
> drm/i915/mst: filter out the display mode exceed sink's capability
The above depends on:
> Lyude Paul (1):
> drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx
Which has changes
etch changes up to e57bd05ec0d2d82d63725dedf9f5a063f879de25:
drm/i915: Update DRIVER_DATE to 20200715 (2020-07-15 14:18:02 +0300)
drm/i915 features for v5.9, batch #2
Highlights:
- Very early DG1 enabling (Abdiel, Lucas, Anusha)
Hi Dave & Daniel -
drm-intel-fixes-2020-07-15:
drm/i915 fixes for v5.8-rc6:
- FBC w/a stride fix
- Fix use-after-free fix on module reload
- Ignore irq enabling on the virtual engines to fix device sleep
- Use GTT when saving/restoring engine GPR
- Fix selftest sort function
BR,
Jani.
The
On Tue, Jul 07, 2020 at 10:12:12PM +0200, Daniel Vetter wrote:
> Again needs to be put right after the call to
> drm_atomic_helper_commit_hw_done(), since that's the last thing which
> can hold up a subsequent atomic commit.
>
> No surprises here.
I was (still am) hoping to do a testing for this
On Wed, Jul 15, 2020 at 10:17:56AM +0200, Daniel Vetter wrote:
> On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen wrote:
> >
> > On 07/14, Daniel Vetter wrote:
> > > On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > > > On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen
> > > > wrote:
> > >
Quoting Chris Wilson (2020-07-15 13:21:43)
> Quoting Daniel Vetter (2020-07-15 13:10:22)
> > On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > > When waiting with a callback on the stack, we must remove the callback
> > > upon wait completion. Since this will be notified by the
Quoting Daniel Vetter (2020-07-15 13:10:22)
> On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > When waiting with a callback on the stack, we must remove the callback
> > upon wait completion. Since this will be notified by the fence signal
> > callback, the removal often contends
On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> When waiting with a callback on the stack, we must remove the callback
> upon wait completion. Since this will be notified by the fence signal
> callback, the removal often contends with the fence->lock being held by
> the signaler.
On Wed, Jul 15, 2020 at 03:05:59PM +0800, Jing Xiangfeng wrote:
> The variable ret has been assigned the value '-EINVAL'. The assignment
> in the if() is redundant. We can remove it.
Nope, that's not correct. Before this assignement ret is guaranteed to be
0.
-Daniel
>
> Signed-off-by: Jing
On Tue, Jul 14, 2020 at 10:23:43PM -0700, Randy Dunlap wrote:
> Drop doubled word "than" in a comment.
>
> Signed-off-by: Randy Dunlap
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
Entire series pushed to drm-misc-next, thanks for your patches. Should
still make
On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote:
>
> Hi,
>
> On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen
> wrote:
> > On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson
> > wrote:
> > > Maybe now is the time to ask: are you using sw_sync outside of
> > > validation?
> >
> > Yes, this is
On Wed, Jul 15, 2020 at 11:17 AM Christian König
wrote:
>
> Am 14.07.20 um 16:31 schrieb Daniel Vetter:
> > On Tue, Jul 14, 2020 at 01:40:11PM +0200, Christian König wrote:
> >> Am 14.07.20 um 12:49 schrieb Daniel Vetter:
> >>> On Tue, Jul 07, 2020 at 10:12:23PM +0200, Daniel Vetter wrote:
>
Hi,
On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen
wrote:
> On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson
> wrote:
> > Maybe now is the time to ask: are you using sw_sync outside of
> > validation?
>
> Yes, this is used as part of the Android stack on Chrome OS (need to
> see if ChromeOS
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
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 --
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
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
Reviewed-by: Bas Nieuwenhuizen
On Wed, Jul 15, 2020 at 12:04 PM Chris Wilson wrote:
>
> If a signal callback releases the sw_sync fence, that will trigger a
> deadlock as the timeline_fence_release recurses onto the fence->lock
> (used both for signaling and the the timeline tree).
>
> If we
On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson wrote:
>
> Quoting Bas Nieuwenhuizen (2020-07-15 11:23:35)
> > Hi Chris,
> >
> > My concern with going in this direction was that we potentially allow
> > an application to allocate a lot of kernel memory but not a lot of fds
> > by creating lots of
When waiting with a callback on the stack, we must remove the callback
upon wait completion. Since this will be notified by the fence signal
callback, the removal often contends with the fence->lock being held by
the signaler. We can look at the list entry to see if the callback was
already
Rearrange the code to pull the operations beore the fence->lock critical
section, and remove a small amount of redundancy:
Function old new delta
dma_fence_add_callback 156 145 -11
Signed-off-by: Chris Wilson
---
Quoting Bas Nieuwenhuizen (2020-07-15 11:23:35)
> Hi Chris,
>
> My concern with going in this direction was that we potentially allow
> an application to allocate a lot of kernel memory but not a lot of fds
> by creating lots of fences and then closing the fds but never
> signaling them. Is that
Hi,
On Wed, 15 Jul 2020 at 11:23, Bas Nieuwenhuizen
wrote:
> My concern with going in this direction was that we potentially allow
> an application to allocate a lot of kernel memory but not a lot of fds
> by creating lots of fences and then closing the fds but never
> signaling them. Is that
Hi Chris,
My concern with going in this direction was that we potentially allow
an application to allocate a lot of kernel memory but not a lot of fds
by creating lots of fences and then closing the fds but never
signaling them. Is that not an issue?
- Bas
On Wed, Jul 15, 2020 at 12:04 PM Chris
While sw_sync is purely a debug facility for userspace to create fences
and timelines it can control, nevertheless it has some tricky locking
semantics of its own. In particular, Bas Nieuwenhuizen reported that we
had reintroduced a deadlock if a signal callback attempted to destroy
the fence. So
If a signal callback releases the sw_sync fence, that will trigger a
deadlock as the timeline_fence_release recurses onto the fence->lock
(used both for signaling and the the timeline tree).
If we always hold a reference for an unsignaled fence held by the
timeline, we no longer need to detach
dma_fence_release() objects to a fence being freed before it is
signaled, so instead of playing fancy tricks to avoid handling dying
requests, let's keep the syncpt alive until signaled. This neatly
removes the issue with having to decouple the syncpt from the timeline
upon fence release.
-Chris
On Wed, Jul 15, 2020 at 10:51:02AM +0900, Tetsuo Handa wrote:
> syzbot is reporting general protection fault in bitfill_aligned() [1]
> caused by integer underflow in bit_clear_margins(). The cause of this
> problem is when and how do_vc_resize() updates vc->vc_{cols,rows}.
>
> If vc_do_resize()
Still Reviewed-by: Bas Nieuwenhuizen
On Tue, Jul 14, 2020 at 11:24 PM Chris Wilson wrote:
>
> Since we decouple the sync_pt from the timeline tree upon release, in
> order to allow releasing the sync_pt from a signal callback we need to
> separate the sync_pt signaling lock from the timeline
Am 14.07.20 um 16:31 schrieb Daniel Vetter:
On Tue, Jul 14, 2020 at 01:40:11PM +0200, Christian König wrote:
Am 14.07.20 um 12:49 schrieb Daniel Vetter:
On Tue, Jul 07, 2020 at 10:12:23PM +0200, Daniel Vetter wrote:
My dma-fence lockdep annotations caught an inversion because we
allocate
Quoting YueHaibing (2020-07-15 04:21:04)
> It is not used since commit 058179e72e09 ("drm/i915/gt: Replace
> hangcheck by heartbeats")
>
> Signed-off-by: YueHaibing
Indeed, it is no more.
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
Am 14.07.20 um 22:06 schrieb Chris Wilson:
From: Bas Nieuwenhuizen
Calltree:
timeline_fence_release
drm_sched_entity_wakeup
dma_fence_signal_locked
sync_timeline_signal
sw_sync_ioctl
Releasing the reference to the fence in the fence signal callback
seems reasonable to me, so
On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen wrote:
>
> On 07/14, Daniel Vetter wrote:
> > On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > > On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen wrote:
> > > >
> > > > On 07/13, Daniel Vetter wrote:
> > > > > On Fri, Jul 10, 2020 at
On Tue 14 Jul 15:13 PDT 2020, Rob Herring wrote:
> On Tue, Jul 14, 2020 at 10:33 AM Jeffrey Hugo
> wrote:
> >
> > On Mon, Jul 13, 2020 at 5:50 PM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Jul 13, 2020 at 1:25 PM Rob Herring wrote:
> > > >
> > > > On Mon, Jul 13, 2020 at 9:08 AM
Chen-Yu Tsai writes:
> From: Chen-Yu Tsai
>
> When the extra HPD polling in sun4i_hdmi was removed, the result of
> HPD was accidentally inverted.
>
> Fix this by inverting the check.
>
> Fixes: bda8eaa6dee7 ("drm: sun4i: hdmi: Remove extra HPD polling")
> Signed-off-by: Chen-Yu Tsai
hi
I've encountered [BUG: unable to handle kernel NULL pointer dereference at]
which has call stack like your pattern2.
And before this happended, I got a lot of memory allocation failure warnings.
And my kernel is 3.10.0-327.62.1.el7.x86_64.
Since, you mentioned it may be a bug of drm/tmm.
It is not used since commit 058179e72e09 ("drm/i915/gt: Replace
hangcheck by heartbeats")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/i915/i915_utils.h | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
On 2020/07/14 18:13, Gu Jinxiang wrote:
> I've encountered [BUG: unable to handle kernel NULL pointer dereference at]
> which has call stack like your pattern2.
> And before this happended, I got a lot of memory allocation failure warnings.
> And my kernel is 3.10.0-327.62.1.el7.x86_64.
>
>
Drop doubled words "the" and "be" in comments.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
include/uapi/drm/i915_drm.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
---
Hello Tetsuo,
Can you try the a.out built from the original Syzkaller modified repro C
program? It walks 0-7 through xres and yres of the fb_var_screeninfo struct.
// https://syzkaller.appspot.com/bug?id=a565882df74fa76f10d3a6fec4be31098dbb37c6
// autogenerated by syzkaller
On 2020/07/15 2:15, George Kennedy wrote:
> Can you try the a.out built from the original Syzkaller modified repro C
> program? It walks 0-7 through xres and yres of the fb_var_screeninfo struct.
I'm not familiar with exploit code. What do you want to explain via this
program?
> struct
Drop doubled word "should" in a comment.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
include/drm/drm_bridge.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200714.orig/include/drm/drm_bridge.h
+++
Hi Jonas,
Am 07.07.20 um 00:30 schrieb Jonas Karlman:
Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the
Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399.
Also add support for 10-bit 4:4:4 format while at it.
V2: Added NV30 support
Signed-off-by:
Drop doubled word "the" in a comment.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
include/drm/drm_rect.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200714.orig/include/drm/drm_rect.h
+++
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
---
1 - 100 of 113 matches
Mail list logo
