On Tue, Sep 9, 2025 at 5:31 PM Danilo Krummrich wrote:
>
> On Thu Sep 4, 2025 at 4:16 AM CEST, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > While discussing cgroups we noticed a problem where you could export
> > a BO to a dma-buf without having it ever being backed or accounted for.
> >
> >
On Mon, Sep 1, 2025 at 6:02 PM Thomas Hellström
wrote:
>
> Hi Dave,
>
> On Mon, 2025-09-01 at 14:56 +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > While discussing cgroups we noticed a problem where you could export
> > a BO to a dma-buf without having it ever being backed or accounted
>
On Tue, Sep 2, 2025 at 11:22 AM David Airlie wrote:
>
> On Mon, Sep 1, 2025 at 6:02 PM Thomas Hellström
> wrote:
> >
> > Hi Dave,
> >
> > On Mon, 2025-09-01 at 14:56 +1000, Dave Airlie wrote:
> > > From: Dave Airlie
> > >
> > > W
> > On 14.07.25 07:18, Dave Airlie wrote:
> > > From: Dave Airlie
> > >
> > > This enables all the backend code to use the list lru in memcg mode,
> > > and set the shrinker to be memcg aware.
> > >
> > > It adds the loop case for when pooled pages end up being reparented
> > > to a higher memcg g
On Tue, Jul 15, 2025 at 5:34 PM Christian König
wrote:
>
>
>
> On 14.07.25 07:18, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This enables all the backend code to use the list lru in memcg mode,
> > and set the shrinker to be memcg aware.
> >
> > It adds the loop case for when pooled pages e
On Fri, Jul 4, 2025 at 7:46 AM Danilo Krummrich wrote:
>
> On 7/3/25 1:27 AM, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This fixes a bunch of command hangs after runtime suspend/resume.
> >
> > This fixes a regression caused by code movement in the commit below,
> > the commit seems to jus
>
> Do you mean a task in cgroup A does amdgpu_gem_object_create() and then
> the actual allocation can happen in the task in cgroup B?
On android and in some graphics scenarios, this might happen, not sure
if it does always though. We have scenarios where a display server
allocate a buffer for an
On Wed, Jul 2, 2025 at 6:24 PM Christian König wrote:
>
> On 02.07.25 09:57, David Airlie wrote:
> >>>
> >>> It makes it easier now, but when we have to solve swapping, step one
> >>> will be moving all this code around to what I have now, and starti
On Thu, Jul 3, 2025 at 2:06 AM Shakeel Butt wrote:
>
> On Mon, Jun 30, 2025 at 02:49:27PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This introduces 2 new statistics and 3 new memcontrol APIs for dealing
> > with GPU system memory allocations.
> >
> > The stats corresponds to the sam
On Thu, Jul 3, 2025 at 2:03 AM Shakeel Butt wrote:
>
> On Mon, Jun 30, 2025 at 02:49:36PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This adds support for adding a obj cgroup to a buffer object,
> > and passing in the placement flags to make sure it's accounted
> > properly.
> >
> >
> >
> > It makes it easier now, but when we have to solve swapping, step one
> > will be moving all this code around to what I have now, and starting
> > from there.
> >
> > This just raises the bar to solving the next problem.
> >
> > We need to find incremental approaches to getting all the piece
On Tue, Jul 1, 2025 at 6:16 PM Christian König wrote:
>
> On 01.07.25 10:06, David Airlie wrote:
> > On Tue, Jul 1, 2025 at 5:22 PM Christian König
> > wrote:
> >>>>> diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
> >>>>>
On Tue, Jul 1, 2025 at 5:22 PM Christian König wrote:
>
> On 30.06.25 23:33, David Airlie wrote:
> > On Mon, Jun 30, 2025 at 8:24 PM Christian König
> > wrote:
> >>
> >> On 30.06.25 06:49, Dave Airlie wrote:
> >>> From: Dave Airlie
> >>&g
On Mon, Jun 30, 2025 at 8:20 PM Christian König
wrote:
>
> On 30.06.25 06:49, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This flag does nothing yet, but this just changes the APIs to accept
> > it in the future across all users.
> >
> > This flag will eventually be filled out with when to a
On Mon, Jun 30, 2025 at 8:04 PM Christian König
wrote:
>
> On 30.06.25 06:49, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This uses the newly introduced per-node gpu tracking stats,
> > to track GPU memory allocated via TTM and reclaimable memory in
> > the TTM page pools.
> >
> > These stat
On Mon, Jun 30, 2025 at 8:24 PM Christian König
wrote:
>
> On 30.06.25 06:49, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This just adds the obj cgroup pointer to the bo and tt structs,
> > and sets it between them.
> >
> > Signed-off-by: Dave Airlie
> > ---
> > drivers/gpu/drm/ttm/ttm_tt.
On Mon, Jun 30, 2025 at 8:15 PM Christian König
wrote:
>
> On 30.06.25 06:49, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This enable NUMA awareness for the shrinker on the
> > ttm pools.
>
>
> Looks good from my side, but the last time I suggested this Sima explicitly
> told me that it isn
On Mon, Jun 30, 2025 at 8:23 PM Christian König
wrote:
>
> On 30.06.25 06:49, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This enables all the backend code to use the list lru in memcg mode,
> > and set the shrinker to be memcg aware.
> >
> > It adds the loop case for when pooled pages end u
On Wed, Jun 25, 2025 at 9:55 PM Christian König
wrote:
>
> On 24.06.25 03:12, David Airlie wrote:
> > On Mon, Jun 23, 2025 at 6:54 PM Christian König
> > wrote:
> >>
> >> On 6/19/25 09:20, Dave Airlie wrote:
> >>> From: Dave Airlie
> >>&g
On Mon, Jun 23, 2025 at 6:54 PM Christian König
wrote:
>
> On 6/19/25 09:20, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > While discussing memcg intergration with gpu memory allocations,
> > it was pointed out that there was no numa/system counters for
> > GPU memory allocations.
> >
> > With
On Thu, Jun 19, 2025 at 10:33 AM Shakeel Butt wrote:
>
> On Wed, Jun 18, 2025 at 02:06:17PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > While discussing memcg intergration with gpu memory allocations,
> > it was pointed out that there was no numa/system counters for
> > GPU memory all
On Tue, Jun 3, 2025 at 5:47 PM Christian König wrote:
>
> On 6/2/25 22:40, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > Currently you can't see per-device numa aware pools properly.
> >
> > Cc: Christian König
> > Signed-off-by: Dave Airlie
>
> Reviewed-by: Christian König
>
> Any follow u
adding some people
On Tue, Apr 15, 2025 at 10:35 AM Wakko Warner wrote:
>
> I found the fix that works for me. See below.
>
> Wakko Warner wrote:
> > I decided to upgrade to 6.14 on a system with a Matrox G200 onboard vga
> > (supermicro X9SCL).
> >
> > I use this system via the BMC. When the m
On Sun, Feb 9, 2025 at 6:48 AM Theodore Ts'o wrote:
>
> On Fri, Feb 07, 2025 at 06:16:38AM -0600, Dr. Greg wrote:
> >
> > The all powerful sub-system maintainer model works well if the big
> > technology companies can employ omniscient individuals in these roles,
> > but those types are a bit hard
On Thu, Aug 8, 2024 at 6:33 AM Bjorn Helgaas wrote:
>
> On Wed, Aug 07, 2024 at 10:30:18AM +0200, Philipp Stanner wrote:
> > pcim_iomap_regions() is a complicated function that uses a bit mask to
> > determine the BARs the user wishes to request and ioremap. Almost all
> > users only ever set a si
On Fri, Jul 12, 2024 at 12:28 PM Stephen Rothwell wrote:
>
> Hi all,
>
> On Mon, 1 Jul 2024 10:19:01 -0700 Nathan Chancellor wrote:
> >
> > On Mon, Jul 01, 2024 at 07:13:19PM +1000, Stephen Rothwell wrote:
> > >
> > > After merging the drm tree, today's linux-next build (powerpc
> > > allyesconfi
> V2:
> * Fixup explanation as the prior one was bogus
For v2 of both patches,
Reviewed-by: Dave Airlie
Please apply to drm-misc-fixes
Dave.
Reviewed-by: Dave Airlie
On Sat, Mar 16, 2024 at 7:21 AM Lyude Paul wrote:
>
> I've recently been seeing some unexplained GSP errors on my RTX 6000 from
> failed aux transactions:
>
> [ 132.915867] nouveau :1f:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl cmd:0x00731341 failed: 0x
On Wed, Jan 31, 2024 at 8:29 AM Zeng, Oak wrote:
>
> Hi Christian,
>
>
>
> Nvidia Nouveau driver uses exactly the same concept of SVM with HMM, GPU
> address in the same process is exactly the same with CPU virtual address. It
> is already in upstream Linux kernel. We Intel just follow the same
>
>
> For us, Xekmd doesn't need to know it is running under bare metal or
> virtualized environment. Xekmd is always a guest driver. All the virtual
> address used in xekmd is guest virtual address. For SVM, we require all the
> VF devices share one single shared address space with guest CPU pr
NAK for backporting this to anything, it is just a fix for 6.7
On Mon, Jan 8, 2024 at 10:28 PM Sasha Levin wrote:
>
> From: Dave Airlie
>
> [ Upstream commit 7854ea0e408d7f2e8faaada1773f3ddf9cb538f5 ]
>
> This func ptr here is normally static allocation, but gsp r535
> uses a dynamic pointer, s
On Tue, Jul 18, 2023 at 5:41 AM Lucas De Marchi
wrote:
>
> On Fri, Jul 07, 2023 at 11:41:48AM -0700, Luis Chamberlain wrote:
> >On Tue, Jul 04, 2023 at 12:50:50PM +1000, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> This adds two tags that will go into the module info.
> >>
> >> The first d
On Wed, May 24, 2023 at 3:26 PM Luis Chamberlain wrote:
>
> On Wed, May 03, 2023 at 01:19:31PM +1000, Dave Airlie wrote:
> > >
> > > >
> > > >> > the GROUP until after the FIRMWARE, so this can't work, as it already
> > > >> > will have included all the ones below, hence why I bracketed top and
>
On Fri, Feb 10, 2023 at 9:47 AM Stephen Rothwell wrote:
>
> Hi all,
>
> The following commit is also in the drm-fixes tree as a different commit
> (but the same patch):
>
> 94d8b6572a1f ("nvidiafb: detect the hardware support before removing
> console.")
>
> This is commit
>
> 04119ab1a49f ("
On Mon, Feb 6, 2023 at 6:38 PM Zeno Davatz wrote:
>
> Dear Dave
>
> On Mon, Feb 6, 2023 at 9:10 AM Dave Airlie wrote:
> >
> > On Mon, 6 Feb 2023 at 18:01, Zeno Davatz wrote:
> > >
> > > Dear Dave
> > >
> > > On Mon, Feb 6, 2023 at 8:54 AM Dave Airlie wrote:
> > > >
> > > > On Mon, 6 Feb 2023 at
On Sat, Jan 28, 2023 at 1:17 AM Christian König
wrote:
>
> Am 27.01.23 um 15:44 schrieb Danilo Krummrich:
> > [SNIP]
>
> What you want is one component for tracking the VA allocations
> (drm_mm based) and a different component/interface for tracking the
> VA mappings (probably
On Thu, Dec 29, 2022 at 12:58 AM Diogo Ivo wrote:
>
> Hello,
>
> Commit 2541626cfb79 breaks GM20B probe with
> the following kernel log:
>
> [2.153892] [ cut here ]
> [2.153897] WARNING: CPU: 1 PID: 36 at
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:273
>
On Wed, Nov 23, 2022 at 3:21 PM Stephen Rothwell wrote:
>
> Hi all,
>
> On Thu, 17 Nov 2022 18:32:14 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (powerpc
> > ppc44x_defconfig) failed like this:
> >
> > ld: drivers/video/fbdev/core/fbmon.o: in
On Tue, Oct 4, 2022 at 12:21 PM Stephen Rothwell wrote:
>
> Hi broo...@kernel.org,
>
> On Fri, 30 Sep 2022 11:54:34 +0100 broo...@kernel.org wrote:
> >
> > After merging the drm tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > /tmp/next/build/drivers/gpu/drm/amd/a
I'd like to make sure this has no side effects on x86 guests, it
probably is safe, but keep an eye for regression reports.
Reviewed-by: Dave Airlie
Dave.
On Wed, Mar 30, 2022 at 8:20 PM Cong Liu wrote:
>
> any suggestions or extra test I can do now?
>
> Regards,
> Cong
>
> On 2022/3/25 15:45, C
On Tue, Oct 12, 2021 at 2:07 AM Kim Phillips wrote:
>
> Hi,
>
> On 10/5/21 1:10 PM, Kim Phillips wrote:
> > Hi, I occasionally see the below trace with Linus' master on an
> > AMD Milan system:
> >
> > [ 25.657322] BUG: kernel NULL pointer dereference, address:
> >
> > [ 25.6
cc'ing lists/people
On Sun, Sep 5, 2021 at 11:50 AM Andrew Falcon wrote:
>
> Hello,
>
> I am encountering a kernel panic with the error in the subject line using
> kernel 5.14.0 (final). Kernel 5.14.0-rc7 works without issue for me so
> looking back at the last amdgpu commits for 5.14.0 (final)
On Wed, Jun 2, 2021 at 12:25 AM Zbigniew Kempczyński
wrote:
>
> We have established previously we stop using relocations starting
> from gen12 platforms with Tigerlake as an exception. We keep this
> statement but we want to enable relocations conditionally for
> Rocketlake and Alderlake under req
On Fri, Oct 16, 2020 at 6:03 PM KuoHsiang Chou
wrote:
>
> The patch is upstreamed
> 1. For RHEL7.x, because its native kernel is suggested to update
>from 3.10 to 4.9 on 2 ODM's platform.
> 2. For AST2600.
> 3. For ASTDP.
> 4. v1.11
Hi,
I've cc'ed Thomas who is maintaining this upstream, but
:08.058435 kernel: PM: Device :04:00.0 failed to suspend
> async: error -22
> Apr 28 14:36:08.058472 kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
> Apr 28 14:36:08.058879 kernel: sd 0:0:0:0: [sda] Stopping disk
> Apr 28 14:36:08.059229 kernel: ata6: SATA link down (SStatus 0
Adding dri-devel.
This might need a bisect to work out where it went wrong,
Dave.
On Tue, Apr 28, 2020 at 7:48 AM Cary Garrett wrote:
>
> Hello,
>
> System won't go into suspend state after migrating to V5.6.7 kernel. Working
> in V5.5.10.
>
> Journal showing following:
>
> Apr 27 16:07:54 ker
On Fri, Dec 6, 2019 at 4:14 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.12.19 um 10:36 schrieb Dave Airlie:
> > On Wed, 4 Dec 2019 at 17:30, Thomas Zimmermann wrote:
> >>
> >> Hi John
> >>
> >> Am 03.12.19 um 18:55 schrieb John Donnelly:
> >>> Hi ,
> >>>
> >>> See below ,
> >>>
> >>>
> On N
Reviewed-by: Dave Airlie
On Thu, Aug 22, 2019 at 4:59 PM Gerd Hoffmann wrote:
>
> On Mon, Aug 05, 2019 at 12:54:01PM +0200, Gerd Hoffmann wrote:
> > qxl has two modes: "native" (used by the drm driver) and "vga" (vga
> > compatibility mode, typically used for boot display and firmware
> > frameb
Reviewed-by: Dave Airlie
On Wed, Jul 3, 2019 at 1:20 PM Ilia Mirkin wrote:
>
> Make it actually clear the LUT.
>
> Reported-by: Dave Airlie
> Signed-off-by: Ilia Mirkin
> ---
> tests/util/pattern.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/util/pattern.c b
On Tue, Apr 9, 2019 at 4:03 PM Gerd Hoffmann wrote:
>
> On Tue, Apr 09, 2019 at 02:01:33PM +1000, Dave Airlie wrote:
> > On Sat, 12 Jan 2019 at 07:13, Dave Airlie wrote:
> > >
> > > On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann wrote:
> > > >
> > > > Also set prime_handle_to_fd and prime_fd_to_han
On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann wrote:
>
> Time to kill some bad sample code people are copying from ;)
>
> This is a complete rewrite of the cirrus driver. The cirrus_mode_set()
> function is pretty much the only function which is carried over largely
> unmodified. Everything else
On Thu, Nov 8, 2018 at 10:05 PM Jean Delvare wrote:
>
> On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote:
> > Hi David,
> >
> > The following commit:
> >
> > commit 7cf321d118a825c1541b43ca45294126fd474efa
> > Author: Dave Airlie
> > Date: Mon Oct 24 15:37:48 2016 +1000
> >
> > drm/driv
On Tue, Oct 9, 2018 at 11:29 AM Ben Skeggs wrote:
>
> On Fri, Oct 5, 2018 at 5:50 PM Daniel Vetter wrote:
> >
> > On Fri, Oct 05, 2018 at 04:45:54PM +1000, Ben Skeggs wrote:
> > > The following changes since commit
> > > 3483f08106fcd0e8edad2b9f2fc4726d25177799:
> > >
> > > drm/nouveau/devinit
On Thu, Sep 20, 2018 at 6:40 AM Sean Paul wrote:
>
> From: Sean Paul
>
> Move udl maintenance into drm-misc tree. I've also signed up to be a
> reviewer, but have kept it at "Odd Fixes" level of support.
>
> Cc: Dave Airlie
Acked-by: Dave Airlie
>
I'm pretty sure udlkms handles this already.
Dave.
On Wed, Aug 1, 2018 at 11:34 PM, Mikulas Patocka
wrote:
>
>
> On Wed, 1 Aug 2018, Geert Uytterhoeven wrote:
>
> > Hi Mikulas,
> >
> > On Wed, Aug 1, 2018 at 12:59 PM Mikulas Patocka
> wrote:
> > > On Wed, 1 Aug 2018, Geert Uytterhoeven wrote:
>
> No.
>
> IMO Not fixing this immediately through stable is out of the question.
> The deal is that we don't break userspace.
> Having said that, I'm not against a long term vmwgfx-only solution. But
> let's fix this now.
>
> Admittedly we missed testing this but you got to understand that no
- Original Message -
> From: "Linus Torvalds"
> To: "Eric W. Biederman" , "Boris Brezillon"
> , "Daniel
> Vetter"
> Cc: "Linux Kernel Mailing List" , "Dave
> Airlie" , "David Airlie"
> ,
- Original Message -
> From: "Alexey Brodkin"
> To: airlied at redhat.com, daniel at ffwll.ch, "Vineet Gupta" at synopsys.com>, airlied at linux.ie
> Cc: dri-devel at lists.freedesktop.org, linux-kernel at vger.kernel.org,
> linux-snps-arc at lists.infradead.org
> Sent: Monday, 23 May
- Original Message -
> From: "Saket Sinha"
> To: dri-devel at lists.freedesktop.org, kvm at vger.kernel.org, qemu-devel at
> nongnu.org
> Cc: "Dave Airlie"
> Sent: Monday, 15 February, 2016 12:34:18 PM
> Subject: VirtIO-GPU 3D OpenGL Hardware Acceleration for VMs
>
> Hi,
>
> It seems
- Original Message -
> From: "Linus Torvalds"
> To: "Jani Nikula"
> Cc: "Daniel Vetter" , "Olof Johansson" lixom.net>, "Maarten Lankhorst"
> , "Dave Airlie" redhat.com>, "Duncan Laurie" ,
> "dri-devel" , "Linux Kernel Mailing List"
>
> Sent: Thursday, 19 November, 2015 2:18:50 AM
>
- Original Message -
> From: "Michael S. Tsirkin"
> To: "Gerd Hoffmann"
> Cc: "Dave Airlie" , "Dave Airlie" redhat.com>, "dri-devel"
>
> Sent: Tuesday, 2 June, 2015 6:57:33 PM
> Subject: Re: [PATCH v3 0/4] Add virtio gpu driver.
>
> On Tue, Jun 02, 2015 at 10:48:27AM +0200, Gerd Hoff
> On 8 December 2014 at 22:55, Daniel Vetter wrote:
> > When we unplug a dp mst branch we unreference the entire tree from
> > the root towards the leaves. Which is ok, since that's the way the
> > pointers and so also the refcounts go.
> >
> > But when we drop the reference we must make sure tha
Wierd I can't see this in my dri-devel feed,
Daniel any quick opinions?
Dave.
- Original Message -
> From: "Sergei Antonov"
> To: "Dave Airlie"
> Cc: "Daniel Vetter"
> Sent: Friday, 30 May, 2014 8:12:54 PM
> Subject: Reminder: drm/crtc-helper patch
>
> Dave,
> did you notice this [
> Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> loaded.
> (Note, no X running on that box)
>
> Trace below shows trinity, but I can reproduce it with just cat
> /proc/dri/0/vma
How about this, lets just rip it all out.
Dave.
-- next part --
> Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> loaded.
> (Note, no X running on that box)
>
> Trace below shows trinity, but I can reproduce it with just cat
> /proc/dri/0/vma
How about this, lets just rip it all out.
Dave.From 54f9605737437272f440bbc6cc4adf805334
>
> I use KVM VM's to test kernels, and lately with 3.9.2 when my code panic's
> the
> kernel mode setting panic's as well.
>
> In this example, the first one is my fault; but then cirrus framebuffer DRM
> modesetting craps out.
Yeah the fix went to stable today I think
drm: don't check modeset
>
> I use KVM VM's to test kernels, and lately with 3.9.2 when my code panic's
> the
> kernel mode setting panic's as well.
>
> In this example, the first one is my fault; but then cirrus framebuffer DRM
> modesetting craps out.
Yeah the fix went to stable today I think
drm: don't check modeset
- Original Message -
> From: "Rafa? Mi?ecki"
> To: xorg-devel at lists.x.org, "dri-devel" lists.freedesktop.org>, "Dave Airlie"
> Cc: "Alex Deucher"
> Sent: Monday, 11 June, 2012 8:55:56 PM
> Subject: Re: No screens after (WW) Falling back to old probe method for
> modesetting
>
> 2
- Original Message -
> From: "Rafał Miłecki"
> To: xorg-de...@lists.x.org, "dri-devel" ,
> "Dave Airlie"
> Cc: "Alex Deucher"
> Sent: Monday, 11 June, 2012 8:55:56 PM
> Subject: Re: No screens after (WW) Falling back to old probe method for
> modesetting
>
> 2012/6/11 Rafał Miłecki
- Original Message -
> From: "Christian K?nig"
> To: "j glisse"
> Cc: "Jerome Glisse" , dri-devel at
> lists.freedesktop.org
> Sent: Thursday, 26 April, 2012 10:11:12 AM
> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
>
> Hi Jerome,
>
> I totally agree tha
- Original Message -
> From: "Christian König"
> To: "j glisse"
> Cc: "Jerome Glisse" , dri-devel@lists.freedesktop.org
> Sent: Thursday, 26 April, 2012 10:11:12 AM
> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
>
> Hi Jerome,
>
> I totally agree that we c
>
> I agree with your point, too. When I worked on supporting these
> modes
> in X server side, I didn't pick up all such modes but only really de
> facto standard ones. It should suffice for most demands, indeed.
>
> Also, we don't have to add always 1600x900 or 1366x768. Such a mode
> is ne
>
> I agree with your point, too. When I worked on supporting these
> modes
> in X server side, I didn't pick up all such modes but only really de
> facto standard ones. It should suffice for most demands, indeed.
>
> Also, we don't have to add always 1600x900 or 1366x768. Such a mode
> is ne
>
> Ok, not that trivial...
>
> The problem is more like POWER_SUPPLY should be a bool, not a
> tristate.
>
> If you think about it: you don't want things like nouveau to depend
> on a
> random subsystem like that, people will never get it. In fact,
> POWER_SUPPLY provides empty inline stubs wh
>
> Ok, not that trivial...
>
> The problem is more like POWER_SUPPLY should be a bool, not a
> tristate.
>
> If you think about it: you don't want things like nouveau to depend
> on a
> random subsystem like that, people will never get it. In fact,
> POWER_SUPPLY provides empty inline stubs wh
- Original Message -
> From: "James Simmons"
> To: "Dave Airlie"
> Cc: "dri-devel"
> Sent: Thursday, 15 March, 2012 3:18:14 PM
> Subject: Re: drm-core-next vs drm-next
>
>
> > as a headsup, if you are basing a tree on mine, please use
> > drm-core-next not drm-next itself as a basis
- Original Message -
> From: "James Simmons"
> To: "Dave Airlie"
> Cc: "dri-devel"
> Sent: Thursday, 15 March, 2012 3:18:14 PM
> Subject: Re: drm-core-next vs drm-next
>
>
> > as a headsup, if you are basing a tree on mine, please use
> > drm-core-next not drm-next itself as a basis
- Original Message -
> From: "Inki Dae"
> To: "Dave Airlie"
> Cc: "kyungmin park" , "sw0312 kim" at samsung.com>,
> dri-devel at lists.freedesktop.org
> Sent: Thursday, 15 March, 2012 11:36:14 AM
> Subject: RE: [PATCH 10/10] drm/exynos: added virtual display driver.
>
>
>
> > -O
- Original Message -
> From: "Inki Dae"
> To: "Dave Airlie"
> Cc: "kyungmin park" , "sw0312 kim"
> ,
> dri-devel@lists.freedesktop.org
> Sent: Thursday, 15 March, 2012 11:36:14 AM
> Subject: RE: [PATCH 10/10] drm/exynos: added virtual display driver.
>
>
>
> > -Original Message-
- Original Message -
> From: "Linus Torvalds"
> To: "Alan Cox"
> Cc: dri-devel at lists.freedesktop.org
> Sent: Monday, 5 March, 2012 4:50:14 PM
> Subject: Re: [PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc
>
> On Mon, Mar 5, 2012 at 6:22 AM, Alan Cox
> wrote:
> > From: A
- Original Message -
> From: "Linus Torvalds"
> To: "Alan Cox"
> Cc: dri-devel@lists.freedesktop.org
> Sent: Monday, 5 March, 2012 4:50:14 PM
> Subject: Re: [PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc
>
> On Mon, Mar 5, 2012 at 6:22 AM, Alan Cox
> wrote:
> > From: Alan
> ---
> drivers/gpu/drm/radeon/radeon_cs.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 9b4124e..f7ee2f8 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/ra
> ---
> drivers/gpu/drm/radeon/radeon_cs.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 9b4124e..f7ee2f8 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/ra
>
> I'm certainly absolutely in favour of creating a common EDID parser,
> and
> the DRM/KMS implementation might indeed be the most complete /
> advanced
> one, but at least back in 2010 as I was working on the sh-mobile HDMI
> driver, some functinality was still missing there, which I had to ad
>
> I'm certainly absolutely in favour of creating a common EDID parser,
> and
> the DRM/KMS implementation might indeed be the most complete /
> advanced
> one, but at least back in 2010 as I was working on the sh-mobile HDMI
> driver, some functinality was still missing there, which I had to ad
>
>
> using radeontool 1.6.2-1.1 from Debian Wheezy/testing [1]
>
> $ sudo radeontool --debug light off
> Found card 1002:9555 (3)
> Radeon found. Base control address is 7f0746826000; base
> framebuffer address is 7f0735e73000.
> reading RADEON_LVDS_
>
>
> using radeontool 1.6.2-1.1 from Debian Wheezy/testing [1]
>
> $ sudo radeontool --debug light off
> Found card 1002:9555 (3)
> Radeon found. Base control address is 7f0746826000; base
> framebuffer address is 7f0735e73000.
> reading RADEON_LVDS_
- Original Message -
> From: "Sascha Hauer"
> To: "David Airlie"
> Cc: "Inki Dae" , kernel at pengutronix.de, dri-devel
> at lists.freedesktop.org
> Sent: Thursday, 2 February, 2012 12:34:02 PM
> Subject: Re: [PATCH] drm: cleanup device
- Original Message -
> From: "Sascha Hauer"
> To: dri-devel at lists.freedesktop.org
> Cc: "Inki Dae" , kernel at pengutronix.de
> Sent: Thursday, 2 February, 2012 11:57:52 AM
> Subject: [PATCH] drm: cleanup device registration
>
> The non modesetting drm drivers currently use a handcraft
- Original Message -
> From: "Sascha Hauer"
> To: "David Airlie"
> Cc: "Inki Dae" , ker...@pengutronix.de,
> dri-devel@lists.freedesktop.org
> Sent: Thursday, 2 February, 2012 12:34:02 PM
> Subject: Re: [PATCH] drm: cleanup device regi
- Original Message -
> From: "Sascha Hauer"
> To: dri-devel@lists.freedesktop.org
> Cc: "Inki Dae" , ker...@pengutronix.de
> Sent: Thursday, 2 February, 2012 11:57:52 AM
> Subject: [PATCH] drm: cleanup device registration
>
> The non modesetting drm drivers currently use a handcrafted pci
- Original Message -
> From: "Chris Wilson"
> To: "Sascha Hauer" , dri-devel at
> lists.freedesktop.org
> Cc: kernel at pengutronix.de
> Sent: Wednesday, 1 February, 2012 11:48:53 AM
> Subject: Re: [PATCH 14/20] drm: add convenience function to create an enum
> property
>
> On Wed,
- Original Message -
> From: "Chris Wilson"
> To: "Sascha Hauer" , dri-devel@lists.freedesktop.org
> Cc: ker...@pengutronix.de
> Sent: Wednesday, 1 February, 2012 11:48:53 AM
> Subject: Re: [PATCH 14/20] drm: add convenience function to create an enum
> property
>
> On Wed, 1 Feb 2
Some comments below.
> + struct radeon_device *rdev = dev->dev_private;
> + struct drm_gem_object *gobj;
> + struct radeon_bo *robj;
> + void *buffer_data;
> + uint32_t *fence_data;
> + int r = 0;
> + long timeout;
> + int ring = RADEON_RING_TYPE_GFX_INDEX;
> +
>
Some comments below.
> + struct radeon_device *rdev = dev->dev_private;
> + struct drm_gem_object *gobj;
> + struct radeon_bo *robj;
> + void *buffer_data;
> + uint32_t *fence_data;
> + int r = 0;
> + long timeout;
> + int ring = RADEON_RING_TYPE_GFX_INDEX;
> +
>
- Original Message -
> From: "Inki Dae"
> To: airlied at linux.ie, dri-devel at lists.freedesktop.org
> Cc: "Inki Dae" , "kyungmin park" samsung.com>, "sw0312 kim"
>
> Sent: Wednesday, 21 December, 2011 6:22:16 AM
> Subject: [GIT PULL] drm/exynos: update exynos drm driver.
>
> Hi, Dav
- Original Message -
> From: "Xi Wang"
> To: "Jakob Bornecrantz" , "Thomas Hellstrom" at vmware.com>
> Cc: dri-devel at lists.freedesktop.org, "Dave Airlie"
> Sent: Tuesday, 20 December, 2011 9:08:32 PM
> Subject: [PATCH RESEND] vmwgfx: fix incorrect vram size check in
> vmw_kms_fb_cr
- Original Message -
> From: "Inki Dae"
> To: airl...@linux.ie, dri-devel@lists.freedesktop.org
> Cc: "Inki Dae" , "kyungmin park"
> , "sw0312 kim"
>
> Sent: Wednesday, 21 December, 2011 6:22:16 AM
> Subject: [GIT PULL] drm/exynos: update exynos drm driver.
>
> Hi, Dave.
>
> Please p
- Original Message -
> From: "Xi Wang"
> To: "Jakob Bornecrantz" , "Thomas Hellstrom"
>
> Cc: dri-devel@lists.freedesktop.org, "Dave Airlie"
> Sent: Tuesday, 20 December, 2011 9:08:32 PM
> Subject: [PATCH RESEND] vmwgfx: fix incorrect vram size check in
> vmw_kms_fb_create()
This pa
- Original Message -
> From: "ville syrjala"
> To: dri-devel at lists.freedesktop.org
> Sent: Monday, 19 December, 2011 10:06:37 PM
> Subject: Rebased drm_plane patches
>
> I rebased this set on top of drm-next.
>
> I updated some of the error values based on what Jesse suggested.
>
>
1 - 100 of 121 matches
Mail list logo
