I am fighting with Thunderbird to make limit a line to 80 chars but nothing
helps. Any suggestions please.
Andrey
On 6/22/20 5:46 AM, Daniel Vetter wrote:
Also a nit: Please tell your mailer to break long lines, it looks funny
and inconsistent otherwise, at least in some of the mailers I use
On 6/22/20 3:40 PM, Christian König wrote:
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
entity->rq becomes null aftre device unplugged so just return early
in that case.
Mhm, do you have a backtrace for this?
This should only be called by an IOCTL and IOCTLs should already call
On 6/22/20 5:45 AM, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:03AM -0400, Andrey Grodzovsky wrote:
Helper function to be used to invalidate all BOs CPU mappings
once device is removed.
Signed-off-by: Andrey Grodzovsky
This seems to be missing the code to invalidate all the dma-buf
On 6/22/20 12:45 PM, Greg KH wrote:
On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote:
On 6/22/20 7:21 AM, Greg KH wrote:
On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
Track sysfs files in a
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.h
between commit:
7fb81e9d8073 ("drm/i915: Use drmm_add_final_kfree")
from Linus' tree and commit:
8a25c4be583d ("drm/i915/params: switch to device specific parameters")
from the
On Mon, Jun 15, 2020 at 12:21 AM Gerd Hoffmann wrote:
>
> On Fri, Jun 12, 2020 at 11:54:54AM -0700, Gurchetan Singh wrote:
>
> > Plus, I just realized the virtio dma ops and ops used by drm shmem are
> > different, so virtio would have to unconditionally have to skip the
> > shmem path. Perhaps
>
> Just a buch of drive-by comments while browsing the code.
> In general code looks good, especialyl for a v1.
>
> There is a few places that triggers warnings with checkpatch --strict
> Most looks like things that should be fixed.
>
>
Thanks Sam for the review. Will take care of the
On Mon, 2020-06-22 at 14:46 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > +/* Should be done only once during init and resume */
> > +static int synthvid_update_vram_location(struct hv_device *hdev,
> > + phys_addr_t vram_pp)
> > +{
> > + struct hyperv_device *hv
On Mon, Jun 22, 2020 at 08:46:17AM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 19, 2020 at 04:31:47PM -0400, Jerome Glisse wrote:
> > Not doable as page refcount can change for things unrelated to GUP, with
> > John changes we can identify GUP and we could potentialy copy GUPed page
> > instead of
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp"
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just
Nvidia released some documentation on how CRC support works on their
GPUs, hooray!
So: this patch series implements said CRC support in nouveau, along with
adding some special debugfs interfaces for some relevant igt-gpu-tools
tests (already on the ML).
First - we add some new functionality to
We'll be rolling back more things in this function, and the way it's
structured is a bit confusing. So, let's clean this up a bit and just
unroll in the event of failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +
1 file changed, 23
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.
So, fix it by never enabling dithering when it's disabled.
Add some kind of vblank workers. The interface is similar to regular
delayed works, and is mostly based off kthread_work. It allows for
scheduling delayed works that execute once a particular vblank sequence
has passed. It also allows for accurate flushing of scheduled vblank
works - in that
We refer to the armed hardware assembly as armh elsewhere in nouveau, so
fix the naming here to make it consistent.
This patch contains no functional changes.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++--
1 file changed, 6 insertions(+), 6
Since we'll be allocating resources for kthread_create_worker() in the
next commit (which could fail and require us to clean up the mess),
let's simplify the cleanup process a bit by registering a
drm_vblank_init_release() action for each drm_vblank_crtc so they're
still cleaned up if we fail to
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #20 from rtmasura+ker...@hotmail.com ---
I have XFCE4 installed as well, I'll give it a test and let you know in 24
hours; a GPF should have happened by then
--
You are receiving this mail because:
You are watching the assignee of
On Mon, Jun 22, 2020 at 3:38 PM Christian König
wrote:
>
> Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
> > Use the new TTM interface to invalidate all exsisting BO CPU mappings
> > form all user proccesses.
> >
> > Signed-off-by: Andrey Grodzovsky
>
> Reviewed-by: Christian König
>
> I
On Sun, Jun 21, 2020 at 2:05 AM Andrey Grodzovsky
wrote:
>
> Helper function to be used to invalidate all BOs CPU mappings
> once device is removed.
>
> Signed-off-by: Andrey Grodzovsky
Typo in the subject:
unampping -> unmapping
Alex
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
>
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
entity->rq becomes null aftre device unplugged so just return early
in that case.
Mhm, do you have a backtrace for this?
This should only be called by an IOCTL and IOCTLs should already call
drm_dev_enter()/exit() on their own...
Christian.
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Use the new TTM interface to invalidate all exsisting BO CPU mappings
form all user proccesses.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
I think those two patches could already land in amd-staging-drm-next
since they are
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Helper function to be used to invalidate all BOs CPU mappings
once device is removed.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
include/drm/ttm/ttm_bo_driver.h | 7
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #19 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to rtmasura+kernel from comment #18)
> 09:00.0 VGA compatible controller: NVIDIA Corporation GP104GL [Quadro P4000]
> (rev a1)
> 0e:00.0 VGA compatible controller: Advanced Micro
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
On device removal reroute all CPU mappings to dummy page per drm_file
instance or imported GEM object.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 65 -
1 file changed, 57
On Mon, Jun 22, 2020 at 07:55:18PM +0530, Bhanuprakash Modem wrote:
> [Why]
> It's useful to know the min and max vrr range for IGT testing.
>
> [How]
> Expose the min and max vfreq for the connector via a debugfs file
> on the connector, "vrr_range".
>
> Example usage: cat
On Mon, Jun 22, 2020 at 10:57:02AM -0400, Kazlauskas, Nicholas wrote:
> On 2020-06-22 10:25 a.m., Bhanuprakash Modem wrote:
> >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 DRM.
> >
>
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #18 from rtmasura+ker...@hotmail.com ---
lspci:
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890 Northbridge
only single slot PCI-e GFX Hydra part (rev 02)
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD/ATI]
On Mon, Jun 22, 2020 at 7:45 PM Christian König
wrote:
>
> Am 22.06.20 um 16:32 schrieb Andrey Grodzovsky:
> >
> > On 6/22/20 9:18 AM, Christian König wrote:
> >> Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
> >>> Will be used to reroute CPU mapped BO's page faults once
> >>> device is
Am 22.06.20 um 16:32 schrieb Andrey Grodzovsky:
On 6/22/20 9:18 AM, Christian König wrote:
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #17 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to rtmasura+kernel from comment #16)
> Reporting I've had the same issue with kernel 5.7.2 and 5.7.4:
Thanks!
> Jun 22 07:10:24 abiggun kernel: Hardware name: System manufacturer
Am 22.06.20 um 15:45 schrieb Nirmoy Das:
Function prepare_igt_frag() and get_insert_time() were casting
signed value to unsigned value before returning error.
So error check in igt_frag() would not work with unsigned
return value from get_insert_time() compared against negative
value.
Hi Vladimir
> I really don't get what's the problem here. The listing of
> ld9040_prepare at the given commit and with the given .config is:
The culprint is likely ld9040_brightness_set() that is inlined.
I think we have troubles with
static u8 const ld9040_gammas[25][22]
I did not look
On 22/06/2020 18:12, Dennis-YC Hsieh wrote:
> Hi Matthias,
>
> On Mon, 2020-06-22 at 17:54 +0200, Matthias Brugger wrote:
>>
>> On 22/06/2020 17:36, Dennis-YC Hsieh wrote:
>>> Hi Matthias,
>>>
>>> thanks for your comment.
>>>
>>> On Mon, 2020-06-22 at 13:07 +0200, Matthias Brugger wrote:
On Fri, Jun 19, 2020 at 11:53:41PM +0200, Sam Ravnborg wrote:
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> > b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> > new file mode 100644
> > index ..7e1f109a38a4
> > ---
On Mon, Jun 22, 2020 at 10:06 AM Pekka Paalanen wrote:
>
> From: Pekka Paalanen
>
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
>
> Written by Daniel Vetter's request and largely based on his comments in IRC
> and
> from
msm_gem_address_space_create() changed to take a start/length instead
of a start/end for the iova space but all of the callers were just
cut and pasted from the old usage. Most of the mistakes have been fixed
up so just catch up the rest.
Fixes: ccac7ce373c1 ("drm/msm: Refactor address space
On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote:
>
> On 6/22/20 7:21 AM, Greg KH wrote:
> > On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
> > > On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> > > > Track sysfs files in a list so they all can
On Wed, Jun 17, 2020 at 07:39:08PM -0700, Rob Clark wrote:
> On Wed, Jun 17, 2020 at 1:53 PM Eric Anholt wrote:
> >
> > Previously the address space went from 16M to ~0u, but with the
> > refactor one of the 'f's was dropped, limiting us to 256MB.
> > Additionally, the new interface takes a start
On 6/22/20 7:21 AM, Greg KH wrote:
On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
Track sysfs files in a list so they all can be removed during pci remove
since otherwise their removal after that causes crash
On Sat, Jun 20, 2020 at 2:18 PM Hans de Goede wrote:
>
> The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
> controller gets turned off from the _PS3 method of the graphics-card dev:
>
> Method (_PS3, 0, Serialized) // _PS3: Power State 3
> {
>
On Sat, Jun 20, 2020 at 2:18 PM Hans de Goede wrote:
>
> The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
> controller gets poked from the _PS0 method of the graphics-card device:
>
> Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
> If (((Local0 & 0x03) == 0x03))
On 22/06/2020 17:36, Dennis-YC Hsieh wrote:
> Hi Matthias,
>
> thanks for your comment.
>
> On Mon, 2020-06-22 at 13:07 +0200, Matthias Brugger wrote:
>>
>> On 21/06/2020 16:18, Dennis YC Hsieh wrote:
>>> add write_s function in cmdq helper functions which
>>> writes value contains in
I've commited this to our next branch, thanks!
(I'm actually kind of impressed this can be found automatically...)
Roland
Am 17.06.20 um 23:51 schrieb Gustavo A. R. Silva:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
On Mon, Jun 22, 2020 at 11:31:06PM +0800, Hsin-Yi Wang wrote:
> Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
> would proceed with invalid plane and we may see vblank timeout.
>
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
>
On 22/06/2020 17:31, Hsin-Yi Wang wrote:
> Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
> would proceed with invalid plane and we may see vblank timeout.
>
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
> Signed-off-by: Hsin-Yi Wang
On Tue, 16 Jun 2020, ramadevi.ga...@intel.com wrote:
> From: Gandi Ramadevi
>
> Add DG1 PCI ID
There are no DG1 PCI IDs in kernel. So please don't add them here
either.
BR,
Jani.
>
> Signed-off-by: Gandi Ramadevi
> ---
> intel/i915_pciids.h | 5 +
> 1 file changed, 5 insertions(+)
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=207383
rtmasura+ker...@hotmail.com changed:
What|Removed |Added
CC||rtmasura+ker...@hotmail.com
Hi Hsin-Yi,
On Mon, Jun 22, 2020 at 11:01:09PM +0800, Hsin-Yi Wang wrote:
> Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
> would proceed with invalid plane and we may see vblank timeout.
>
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Hi Deepak
On Mon, Jun 22, 2020 at 04:06:22AM -0700, Deepak Rawat wrote:
> DRM driver for hyperv synthetic video device, based on hyperv_fb
> framebuffer driver. Also added config option "DRM_HYPERV" to enabled
> this driver.
Just a buch of drive-by comments while browsing the code.
In general
Hi
Am 22.06.20 um 17:00 schrieb Rong Chen:
> Hi Thomas,
>
> I tested the patch based on commit 24b806b0a1dd3, the regression
Thanks!
> of phoronix-test-suite.glmark2.1024x768.score still exists:
I expected that the test is related to drawing onto the screen. Do you
know what exactly it is
Hi Thomas,
I tested the patch based on commit 24b806b0a1dd3, the regression
of phoronix-test-suite.glmark2.1024x768.score still exists:
1f58fcaf27cb7 drm/mgag200: Enable caching for SHMEM pages
2 2 2
24b806b0a1dd3 drm-tip: 2020y-06m-22d-07h-52m-06s UTC
On 2020-06-22 10:25 a.m., Bhanuprakash Modem wrote:
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 DRM.
This reverts commit 727962f030c23422a01e8b22d0f463815fb15ec4.
Signed-off-by:
On 6/22/20 9:18 AM, Christian König wrote:
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
drivers/gpu/drm/drm_prime.c | 10
Looks great to me.
Reviewed-by: Roland Scheidegger
Am 12.06.20 um 22:49 schrieb Daniel Vetter:
> Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> which means vblank state isn't ill-defined and fail-y at driver load
> before the first modeset on each crtc.
>
> v2:
On Mon, 22 Jun 2020 16:24:38 +0200
Daniel Vetter wrote:
> On Mon, Jun 22, 2020 at 4:22 PM Pekka Paalanen wrote:
> >
> > On Mon, 22 Jun 2020 11:35:01 +0200
> > Daniel Vetter wrote:
> >
> > > On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> > > > Will be used to reroute
On Mon, Jun 22, 2020 at 4:22 PM Pekka Paalanen wrote:
>
> On Mon, 22 Jun 2020 11:35:01 +0200
> Daniel Vetter wrote:
>
> > On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> > > Will be used to reroute CPU mapped BO's page faults once
> > > device is removed.
> > >
> > >
On Mon, Jun 22, 2020 at 3:18 PM Christian König
wrote:
>
> Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
> > Will be used to reroute CPU mapped BO's page faults once
> > device is removed.
> >
> > Signed-off-by: Andrey Grodzovsky
> > ---
> > drivers/gpu/drm/drm_file.c | 8
> >
On Thu, Jun 18, 2020 at 04:44:13PM -0600, Rob Herring wrote:
> Convert the common GPIO, LED, and PWM backlight bindings to DT schema
> format.
>
> Given there's only 2 common properties and the descriptions are slightly
> different, I opted to not create a common backlight schema.
>
> Cc: Lee
On Mon, 22 Jun 2020 11:35:01 +0200
Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> > Will be used to reroute CPU mapped BO's page faults once
> > device is removed.
> >
> > Signed-off-by: Andrey Grodzovsky
> > ---
> > drivers/gpu/drm/drm_file.c |
Hi Laurent,
Thanks for the comment.
>-Original Message-
>From: Laurent Pinchart
>Sent: Wednesday, June 17, 2020 3:18 AM
>To: Venkateshwar Rao Gannavarapu
>Cc: Hyun Kwon ; dri-devel@lists.freedesktop.org;
>airl...@linux.ie; dan...@ffwll.ch; linux-ker...@vger.kernel.org; Sandip Kothari
Hi, Hsin-Yi:
Hsin-Yi Wang 於 2020年6月22日 週一 下午1:32寫道：
>
> Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
> would proceed with invalid plane and we may see vblank timeout.
Except the Fixes tag,
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Hsin-Yi Wang
> ---
>
https://bugzilla.kernel.org/show_bug.cgi?id=207673
--- Comment #4 from phileimer (p...@jpmr.org) ---
I modified my kernel configuration to use the new amdgpu driver for this SI
chip, instead of the legacy radeon.
The same problem occurs: to avoid frequent kernel crashes, I must apply a patch
to
https://bugzilla.kernel.org/show_bug.cgi?id=207673
--- Comment #3 from phileimer (p...@jpmr.org) ---
Created attachment 289807
--> https://bugzilla.kernel.org/attachment.cgi?id=289807=edit
amdgpu: lower the temperature limit to avoid kernel crash
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=207673
phileimer (p...@jpmr.org) changed:
What|Removed |Added
Kernel Version|5.6.x and previous |5.6.x, 5.7.x
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=207673
phileimer (p...@jpmr.org) changed:
What|Removed |Added
Summary|radeon: crash due to over |amdgpu/radeon: crash due to
From: Pekka Paalanen
Set up the expectations on how hot-unplugging a DRM device should look like to
userspace.
Written by Daniel Vetter's request and largely based on his comments in IRC and
from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
A related Wayland protocol
Am 19.06.20 um 12:36 schrieb Marek Szyprowski:
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Track sysfs files in a list so they all can be removed during pci remove
since otherwise their removal after that causes crash because parent
folder was already removed during pci remove.
That looks extremely fishy to me.
It sounds like we just
Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
drivers/gpu/drm/drm_prime.c | 10 ++
include/drm/drm_file.h | 2 ++
Hi,
> +/* Should be done only once during init and resume */
> +static int synthvid_update_vram_location(struct hv_device *hdev,
> + phys_addr_t vram_pp)
> +{
> + struct hyperv_device *hv = hv_get_drvdata(hdev);
> + struct synthvid_msg *msg =
>-Original Message-
>From: charante=codeaurora@mg.codeaurora.org
> On Behalf Of Charan Teja
>Kalla
>Sent: Monday, June 22, 2020 5:26 AM
>To: Ruhl, Michael J ; Sumit Semwal
>; david.lai...@aculab.com; open list:DMA
>BUFFER SHARING FRAMEWORK ; DRI mailing
>list
>Cc: Linaro MM SIG ; LKML
On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add set event function in cmdq helper functions to set specific event.
>
> Signed-off-by: Dennis YC Hsieh
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 15 +++
> include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
>
On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> > Track sysfs files in a list so they all can be removed during pci remove
> > since otherwise their removal after that causes crash because parent
> > folder was
On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add clear parameter to let client decide if
> event should be clear to 0 after GCE receive it.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c |2 +-
>
On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Export finalize function to client which helps append eoc and jump
> command to pkt. Let client decide call finalize or not.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> Acked-by: Chun-Kuang Hu
> ---
>
DRM driver for hyperv synthetic video device, based on hyperv_fb
framebuffer driver. Also added config option "DRM_HYPERV" to enabled
this driver.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/tiny/Kconfig |9 +
drivers/gpu/drm/tiny/Makefile |1 +
On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> add write_s function in cmdq helper functions which
> writes value contains in internal register to address
> with large dma access support.
>
> Signed-off-by: Dennis YC Hsieh
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 19
Maintainer for hyperv synthetic video device.
Signed-off-by: Deepak Rawat
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f437f42b73ad..102f734b99bd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5316,6 +5316,14 @@ T: git
Hi All,
First draft of DRM driver for hyper-v synthetic video device. This synthetic
device is already supported by hyper-v and a corresponding framebuffer driver
exist at drivers/video/fbdev/hyperv_fb.c. With this patch, just reworked the
framebuffer driver into DRM, in doing so got mode-setting
On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add assign function in cmdq helper which assign constant value into
> internal register by index.
>
> Signed-off-by: Dennis YC Hsieh
Applied to v5.8-next/soc
Thanks
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 24
On Fri, Jun 19, 2020 at 11:53:41PM +0200, Sam Ravnborg wrote:
> Good to have these converted. A few comments in the following. One
> comment is for the backlight people as you copied the original text.
... and I've sliced out everything except that in this reply.
> On Thu, Jun 18, 2020 at
On Fri, Jun 19, 2020 at 06:36:17PM +0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 01:39:34PM +0100, Brian Starkey wrote:
> > Hi Simon,
> >
> > On Fri, Jun 19, 2020 at 11:12:25AM +, Simon Ser wrote:
> > > There have suggestions to bake pitch alignment, address alignement,
> > >
On Sun, Jun 21, 2020 at 02:03:06AM -0400, Andrey Grodzovsky wrote:
> Use the new TTM interface to invalidate all exsisting BO CPU mappings
> form all user proccesses.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
On Sun, Jun 21, 2020 at 02:03:07AM -0400, Andrey Grodzovsky wrote:
> entity->rq becomes null aftre device unplugged so just return early
> in that case.
>
> Signed-off-by: Andrey Grodzovsky
That looks very deep in amdgpu internals ... how do you even get in here
after the device is fully
On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
> No point to try recovery if device is gone, just messes up things.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8
On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> Track sysfs files in a list so they all can be removed during pci remove
> since otherwise their removal after that causes crash because parent
> folder was already removed during pci remove.
>
> Signed-off-by: Andrey Grodzovsky
On Sun, Jun 21, 2020 at 02:03:04AM -0400, Andrey Grodzovsky wrote:
> Some of the stuff in amdgpu_device_fini such as HW interrupts
> disable and pending fences finilization must be done right away on
> pci_remove while most of the stuff which relates to finilizing and releasing
> driver data
On Sun, Jun 21, 2020 at 02:03:00AM -0400, Andrey Grodzovsky wrote:
> This RFC is more of a proof of concept then a fully working solution as there
> are a few unresolved issues we are hoping to get advise on from people on the
> mailing list.
> Until now extracting a card either by physical
On Sun, Jun 21, 2020 at 02:03:03AM -0400, Andrey Grodzovsky wrote:
> Helper function to be used to invalidate all BOs CPU mappings
> once device is removed.
>
> Signed-off-by: Andrey Grodzovsky
This seems to be missing the code to invalidate all the dma-buf mmaps?
Probably needs more testcases
On Sun, Jun 21, 2020 at 02:03:02AM -0400, Andrey Grodzovsky wrote:
> On device removal reroute all CPU mappings to dummy page per drm_file
> instance or imported GEM object.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 65
>
On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> Will be used to reroute CPU mapped BO's page faults once
> device is removed.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/drm_file.c | 8
> drivers/gpu/drm/drm_prime.c | 10 ++
>
On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote:
> Am 21.06.20 um 04:07 schrieb Laurent Pinchart:
> > Most of the DRM drivers uAPI headers are licensed under the MIT license,
> > and carry copies of the license with slight variations. Replace them
> > with SPDX headers.
>
> My
On 6/12/20 8:40 PM, Philip Li wrote:
On Fri, Jun 12, 2020 at 01:04:02PM +0200, Linus Walleij wrote:
On Wed, Jun 10, 2020 at 9:38 AM kernel test robot wrote:
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING
On Sun, Jun 21, 2020 at 05:07:03AM +0300, Laurent Pinchart wrote:
> Several DRM drivers uAPI headers that are licensed under the GPL carry
> both an SPDX header and a copy of the license text. Drop the latter.
>
> Signed-off-by: Laurent Pinchart
I do kinda wonder how much lolz these gpl-only
On Sun, Jun 21, 2020 at 05:07:01AM +0300, Laurent Pinchart wrote:
> The DRM core uAPI headers are licensed under the MIT license, and carry
> copies of the license with slight variations. Replace them with SPDX
> headers.
>
> Following a discussion with Daniel Vetter on this topic, add a
>
On Fri, Jun 19, 2020 at 3:12 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2020-06-19 10:43:09)
> > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > Quoting Daniel Vetter (2020-06-19 09:51:59)
> > > > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson
> > > > wrote:
> > > > >
1 - 100 of 168 matches
Mail list logo
