On Fri, Aug 07, 2020 at 11:00:11AM +0800, 何鑫 wrote:
> Xin He 于2020年7月21日周二 下午6:17写道：
> >
> > 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
I was investigating this bug too and this seems correct to me.
I've tested it with a kernel which doesn't have the other crash issue,
and indeed it seems to work fine.
That said, this also needs to be fixed in the older paths (these will be
used by vms using older hw version lacking some
Hi Dave,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next
linus/master drm/drm-next drm-exynos/exynos-drm-next v5.8 next-20200806]
[If your patch is applied to the wrong git tree
On Fri, 7 Aug 2020 at 14:03, Dave Airlie wrote:
>
> On Fri, 7 Aug 2020 at 11:13, Rodrigo Vivi wrote:
> >
> > From: Rodrigo Vivi
> >
> > These are missed cases that I just identified with allyesconfig build.
> >
>
> Is this against drm-tip? it's a merge problem, that I thought I'd
> already
On Fri, 7 Aug 2020 at 11:13, Rodrigo Vivi wrote:
>
> From: Rodrigo Vivi
>
> These are missed cases that I just identified with allyesconfig build.
>
Is this against drm-tip? it's a merge problem, that I thought I'd
already addressed, but tip seems to have lost it.
Dave.
> Fixes: 2966141ad2dd
Hi Dave,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next
linus/master drm/drm-next drm-exynos/exynos-drm-next v5.8 next-20200806]
[If your patch is applied to the wrong git tree
Hi Swapnil,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v5.8 next-20200806]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
From: Rodrigo Vivi
These are missed cases that I just identified with allyesconfig build.
Fixes: 2966141ad2dd ("drm/ttm: rename ttm_mem_reg to ttm_resource.")
Cc: Dave Airlie
Cc: Ben Skeggs
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/nouveau/nouveau_bo.h | 14 +++---
On Thu, 6 Aug 2020 at 23:51, Christian König
wrote:
>
> The object flags created in radeon_ttm_placement_from_domain take care that
> we use the correct caching for AGP, this is just superflous.
>
> Signed-off-by: Christian König
Reviewed-by: Dave Airlie
> ---
>
On Thu, 6 Aug 2020 at 23:51, Christian König
wrote:
>
> This is a separate object we work within TTM.
Reviewed-by: Dave Airlie
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 8 +-
>
On Thu, 6 Aug 2020 at 23:51, Christian König
wrote:
>
> The names get/put are associated with reference counting
> in the Linux kernel, use alloc/free instead.
>
Sounds good,
Reviewed-by: Dave Airlie
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4
From: Dave Airlie
Christian suggested this and it makes sense.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 21 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 19
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 24
These are a bit misc/bit rfc, Christian you suggested the first, the second
follows on from that and are both amdgpu specifc.
These are more RFC or may ignite some better ideas, I'm not hard sold on either.
Dave.
___
dri-devel mailing list
From: Dave Airlie
This is a bit more involved that it looked, the range manager
needs accessors adding and amdgpu needs a bit of a refactor.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 21 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 +++--
From: Dave Airlie
There is no need for that now since it's embedded.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 11 +++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git
From: Dave Airlie
This moves the io lru tracking into the driver allocated structure.
Probably need to consider if we can move more stuff in there around the
nouveau only io_lru functionality.
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 24 +---
drivers/gpu/drm/ttm/ttm_bo.c
Not entirely sure why this never came up when I originally tested this
(maybe some BIOSes already have this setup?) but the ->caps_init vfunc
appears to cause the display engine to throw an exception on driver
init, at least on my ThinkPad P72:
nouveau :01:00.0: disp: chid 0 mthd 008c data
On Thu, Aug 6, 2020 at 8:20 PM Krzysztof Kozlowski wrote:
>
> Hi All,
>
> Shortly
> ===
> This is a continuation of Arnd's work from 2019 [1]. The goal is to
> cleanup, merge and finally make the Samsung S3C24xx and S3C64xx
> architectures multiplatform. The multiplatform did not happen yet
On Wed, Aug 5, 2020 at 1:51 AM Mauro Carvalho Chehab
wrote:
> I've been working to get upstream support for the DRM driver on HiKey 970.
>
> While the patches are not ready yet for upstream merge, I'm placing
> what I've sone so far on this repository:
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=208839
--- Comment #7 from Alex Deucher (alexdeuc...@gmail.com) ---
It has nothing to do with kernels that are installed. From the link:
"Although in principle the image might be loaded into memory and the
pre-hibernation memory contents restored by
https://bugzilla.kernel.org/show_bug.cgi?id=208839
--- Comment #6 from sandy.8...@gmail.com ---
It is the same kernel in this case. I didn't install any new kernel before
hibernating, therefore the kernel that entered the hibernate is the same kernel
that resumed from hibernation.
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=208839
--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to sandy.8925 from comment #3)
> That doesn't seem to be the case, based on the traces I took. AFAICT the
> kernel just calls the freeze function and then the restore
Am 06.08.20 um 17:28 schrieb Christian König:
> My best guess is that you are facing two separate bugs here.
>
> Crash #1 is somehow related to CRTCs and might even be cause by the
> atomic-helper change you noted below.
>
> Crash #2 is caused because vmw_bo_create_and_populate() tries to
>
https://bugzilla.kernel.org/show_bug.cgi?id=208839
--- Comment #4 from sandy.8...@gmail.com ---
Created attachment 290805
--> https://bugzilla.kernel.org/attachment.cgi?id=290805=edit
dmesg on Arch Linux 5.8 kernel, after hibernate and resume
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=208839
--- Comment #3 from sandy.8...@gmail.com ---
That doesn't seem to be the case, based on the traces I took. AFAICT the kernel
just calls the freeze function and then the restore function.
--
You are receiving this mail because:
You are watching
On 2020-08-05 4:45 p.m., Rodrigo Siqueira wrote:
On 07/30, Nicholas Kazlauskas wrote:
[Why]
MEDIUM or FULL updates can require global validation or affect
bandwidth. By treating these all simply as surface updates we aren't
actually passing this through DC global validation.
[How]
There's
From: Arnd Bergmann
The s3c2410fb driver is too deeply intertwined with the s3c24xx
platform code. Change it in a way that avoids the use of platform
header files but having all interface data in a platform_data
header, and the private register definitions next to the driver
itself.
One ugly
Hi All,
Shortly
===
This is a continuation of Arnd's work from 2019 [1]. The goal is to
cleanup, merge and finally make the Samsung S3C24xx and S3C64xx
architectures multiplatform. The multiplatform did not happen yet
here... just cleaning up and merging into one mach-s3c.
I intend to take
On 2020-08-05 5:11 p.m., Rodrigo Siqueira wrote:
On 07/30, Nicholas Kazlauskas wrote:
[Why]
Enabling or disable DCC or switching between tiled and linear formats
can require bandwidth updates.
They're currently skipping all DC validation by being treated as purely
surface updates.
[How]
Treat
https://bugzilla.kernel.org/show_bug.cgi?id=208839
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
This fixes the bug I reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=208839
Reproducing bug report here:
After hibernating and resuming, DPM is not enabled. This remains the case even
if you test hibernate using the steps here:
https://bugzilla.kernel.org/show_bug.cgi?id=208839
sandy.8...@gmail.com changed:
What|Removed |Added
CC||sandy.8...@gmail.com
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=208839
Bug ID: 208839
Summary: AMDGPU: DPM is not enabled after hibernate and resume
for CIK/Hawaii GPUs (e.g R9 390)
Product: Drivers
Version: 2.5
Kernel Version: 5.8
https://bugzilla.kernel.org/show_bug.cgi?id=207137
sandy.8...@gmail.com changed:
What|Removed |Added
Kernel Version|5.6 |5.8
--
You are receiving this
On Thu, Aug 6, 2020 at 7:46 AM wrote:
>
> On 2020-08-05 21:18, Rob Clark wrote:
> > On Wed, Aug 5, 2020 at 6:34 AM Kalyan Thota
> > wrote:
> >>
> >> In TEST_ONLY commit, rm global_state will duplicate the
> >> object and request for new reservations, once they pass
> >> then the new state will
From: Thierry Reding
Use the of_get_i2c_adapter_by_node(), which is similar to the existing
call to of_find_i2c_adapter_by_node() except that it also takes a
reference to the owner module of the I2C adapter. In order to properly
balance this out, call i2c_put_adapter() to release the reference
When converting to atomic the state reset was done by directly calling
the functions, and before the modeset object was fully initialized.
This means the various ->dev pointers weren't set up.
After
commit 51f644b40b4b794b28b982fdd5d0dd8ee63f9272
Author: Daniel Vetter
Date: Fri Jun 12
On Thu, Aug 6, 2020 at 5:28 PM Christian König wrote:
>
> My best guess is that you are facing two separate bugs here.
>
> Crash #1 is somehow related to CRTCs and might even be cause by the
> atomic-helper change you noted below.
Yeah, and I think I know what's going on. Patch incoming. When
My best guess is that you are facing two separate bugs here.
Crash #1 is somehow related to CRTCs and might even be cause by the
atomic-helper change you noted below.
Crash #2 is caused because vmw_bo_create_and_populate() tries to
manually populate a BO object instead of relying on TTM to
https://bugzilla.kernel.org/show_bug.cgi?id=208835
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=208835
Bug ID: 208835
Summary: amdgpu fails to resume from suspend
Product: Drivers
Version: 2.5
Kernel Version: 5.8.0-050800-generic
Hardware: Intel
OS: Linux
On 2020-08-05 4:37 p.m., Rodrigo Siqueira wrote:
Hi,
I have some minor inline comments, but everything looks fine when I
tested it on Raven; feel free to add
Tested-by: Rodrigo Siqueira
in the whole series.
Thanks for the reviews!
I can clean up the nitpicks for this patch and make a v2.
The names get/put are associated with reference counting
in the Linux kernel, use alloc/free instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 6 +++---
drivers/gpu/drm/nouveau/nouveau_ttm.c
This is a separate object we work within TTM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 8 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 +-
The object flags created in radeon_ttm_placement_from_domain take care that
we use the correct caching for AGP, this is just superflous.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 21 ++---
1 file changed, 2 insertions(+), 19 deletions(-)
diff
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: f39035176cb854c6d620af7614a60a485ee26818
commit: ad11f45fae37631b0482ebf6543bdd013d3f9336 [6/10] Merge remote-tracking
branch 'drm-misc/drm-misc-next' into drm-tip
config: x86_64-randconfig-a015-20200806 (attached as .config
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: f39035176cb854c6d620af7614a60a485ee26818
commit: ad11f45fae37631b0482ebf6543bdd013d3f9336 [6/10] Merge remote-tracking
branch 'drm-misc/drm-misc-next' into drm-tip
config: mips-allyesconfig (attached as .config)
compiler:
On 08/04, dan...@ffwll.ch wrote:
> On Sat, Aug 01, 2020 at 03:49:29PM -0300, Melissa Wen wrote:
> > VKMS needs vblank interrupts enabled to capture CRC. When vblank is
> > disabled, tests like kms_cursor_crc and kms_pipe_crc_basic getting stuck
> > waiting for a capture that will not occur until
VKMS needs vblank interrupts enabled to capture CRC. When vblank is
disabled, tests like kms_cursor_crc and kms_pipe_crc_basic getting stuck
waiting for a capture that will not occur until vkms wakes up. This patch
adds a helper to set composer and ensure that vblank remains enabled as
long as the
Some drivers may expose primary planes compatible with multiple CRTCs.
Make this clear in the docs: the current wording may be misunderstood as
"exactly one primary plane per CRTC".
Signed-off-by: Simon Ser
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 4 ++--
1 file changed, 2
On Tue, Aug 04, 2020 at 06:35:20AM +, Oleksandr Andrushchenko wrote:
>
> On 8/4/20 9:12 AM, Jürgen Groß wrote:
> > On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> >> display
Looks great! Thanks.
Reviewed-by: Dan Carpenter
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Am 06.08.20 um 11:05 schrieb Michel Dänzer:
On 2020-08-06 10:43 a.m., Christian König wrote:
Am 06.08.20 um 10:01 schrieb Michel Dänzer:
On 2020-08-06 9:13 a.m., Christian König wrote:
Am 05.08.20 um 18:16 schrieb Michel Dänzer:
On 2020-06-29 5:19 p.m., Christian König wrote:
We only need
On 2020-08-06 10:43 a.m., Christian König wrote:
> Am 06.08.20 um 10:01 schrieb Michel Dänzer:
>> On 2020-08-06 9:13 a.m., Christian König wrote:
>>> Am 05.08.20 um 18:16 schrieb Michel Dänzer:
On 2020-06-29 5:19 p.m., Christian König wrote:
> We only need the page array when the BO is
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions test for the type of memory and call the rsp fb_sys_ of fb_cfb_
functions. For drivers that employ a
GEM's vmap interface now wraps memory pointers in struct drm_gem_membuf.
The structure represents a pointer into the framebuffer, which is either
in I/O memory or in system memory. The structure contains a flag that
distinguishes these cases.
Signed-off-by: Thomas Zimmermann
---
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem. Previous attempts to resolve the
issue returned an
VRAM helpers support ref counting for pin and vmap operations, no need to
avoid these operations with the internal kmap interface. Also unexport
the kmap interfaces from VRAM helpers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 56 +--
This patch replaces the vmap's use of raw pointers in GEM object
functions with instances of struct drm_gem_membuf. GEM backends are
converted as well.
For most GEM backends, this simply change the returned type. GEM VRAM
helpers are also updated to indicate whether the returned frmabuffer
Am 06.08.20 um 10:01 schrieb Michel Dänzer:
On 2020-08-06 9:13 a.m., Christian König wrote:
Am 05.08.20 um 18:16 schrieb Michel Dänzer:
On 2020-06-29 5:19 p.m., Christian König wrote:
We only need the page array when the BO is about to be accessed.
So not only populate, but also create it on
Am 06.08.20 um 05:46 schrieb Dave Airlie:
That was not what I was talking about. Take a look at what those fields
are used for :)
As far as I see the only usage of the size is in
ttm_resource_manager_debug(). But this size is actually totally opaque
to TTM, it could be pages, bytes, fried
On 2020-08-06 9:13 a.m., Christian König wrote:
> Am 05.08.20 um 18:16 schrieb Michel Dänzer:
>> On 2020-06-29 5:19 p.m., Christian König wrote:
>>> We only need the page array when the BO is about to be accessed.
>>>
>>> So not only populate, but also create it on demand.
>>>
>>> v2: move NULL
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Drivers using legacy PCI power management .suspend()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a "struct dev_pm_ops"
variable to take the
Fixes commit 42ddb453a0cd ("radeon: Conditionally compile PM code")
Before the above mentioned patch, codes between the line number 547 and
2803 were already inside "#ifdef CONFIG_PM" container. Thus, addition of
"#if defined(CONFIG_PM)" was not required in the patch. It also affected
the "#ifdef
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
As of commit 47ec5303d73ea344 ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") on linux.git ,
my VMware environment cannot boot. Do I need to bisect?
[9.314496][T1] vga16fb: mapped to 0x71050562
[9.467770][T1] Console: switching to colour frame
In TEST_ONLY commit, rm global_state will duplicate the
object and request for new reservations, once they pass
then the new state will be swapped with the old and will
be available for the Atomic Commit.
This patch fixes some of missing links in the resource
reservation sequence mentioned above.
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
On Wed, Aug 05, 2020 at 03:19:01PM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 05, 2020 at 11:37:11PM +0530, Vaibhav Gupta wrote:
> > Drivers using legacy power management .suspen()/.resume() callbacks
> > have to manage PCI states and device's PM states themselves. They also
> > need to take care
Hi Daniel
在 2020/8/5 17:36, Daniel Vetter 写道:
On Wed, Aug 5, 2020 at 10:37 AM Sandy Huang wrote:
add this node to get the current true mode.
Signed-off-by: Sandy Huang
Uh what's this for? Since it's sysfs, I guess there's something
parsing this, which means we'd kinda need to have that
CC Rob Herring + devicetree List + Sean
> Gesendet: Dienstag, 04. August 2020 um 20:02 Uhr
> Von: "David Woodhouse"
> On Tue, 2020-08-04 at 19:40 +0200, Frank Wunderlich wrote:
> > > Gesendet: Dienstag, 04. August 2020 um 19:24 Uhr
> > > Von: "David Woodhouse"
> > > > + mipi_tx0:
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
> Gesendet: Mittwoch, 05. August 2020 um 10:36 Uhr
> Von: "David Woodhouse"
> > mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts
> > mt7623.dtsi => mt7623a.dtsi => mt7623a-unielec-u7623.dts (not existing yet,
> > openwrt seems to use a board-specific dtsi)
>
> Yes, I think we should.
Linux Kernel Mentee: Remove Legacy Power Management.
The original goal of the patch series is to upgrade the power management
framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not
Xin He 于2020年7月22日周三 下午1:19写道：
>
> Before setting shmem->pages to NULL, kfree() should
> be called.
>
> Signed-off-by: Xin He
> Reviewed-by: Qi Liu
> ---
> drivers/gpu/drm/virtio/virtgpu_object.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
add this node to get the current true mode.
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/drm_sysfs.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 939f0032aab1..f39bcd34853b 100644
---
On 2020-08-05 01:02, Rob Clark wrote:
On Tue, Aug 4, 2020 at 4:32 AM Kalyan Thota
wrote:
DPU resources reserved in the atomic_check path gets unwinded
during modeset operation before commit happens in a non seamless
transition.
Update the reservations in the commit path to avoid resource
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
On Mon, Jul 20, 2020 at 9:27 PM Alexandru Stan wrote:
>
> 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
Hi David
> Gesendet: Mittwoch, 05. August 2020 um 13:30 Uhr
> Von: "David Woodhouse"
> From: David Woodhouse
>
> The MT7623A doesn't have a GPU; add it only for MT7623N boards.
>
> Fixes: 1f6ed224594 ("arm: dts: mt7623: add Mali-450 device node")
> Signed-off-by: David Woodhouse
> diff --git
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Linux Kernel Mentee: Remove Legacy Power Management.
The purpose of this patch series is to upgrade power management in video fbdev
drivers. This has been done by upgrading .suspend() and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not change the
order of
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Linux Kernel Mentee: Remove Legacy Power Management.
The original goal of the patch series is to upgrade the power management
framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not
On Thu, Aug 06, 2020 at 09:36:41AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 05 Aug 2020 15:19:38 -0700 Joe Perches wrote:
> >
> > On Wed, 2020-08-05 at 17:27 -0400, Alex Deucher wrote:
> > > On Wed, Aug 5, 2020 at 4:53 PM Joe Perches wrote:
> > > > On Wed, 2020-08-05 at 16:01
Am 05.08.20 um 18:16 schrieb Michel Dänzer:
On 2020-06-29 5:19 p.m., Christian König wrote:
We only need the page array when the BO is about to be accessed.
So not only populate, but also create it on demand.
v2: move NULL check into ttm_tt_create()
v3: fix the occurrence in ttm_bo_kmap_ttm
On Thu, Aug 06, 2020 at 03:43:02PM +0900, Tetsuo Handa wrote:
> As of commit 47ec5303d73ea344 ("Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") on linux.git ,
> my VMware environment cannot boot. Do I need to bisect?
That sounds like a good idea, but please start a new
93 matches
Mail list logo
