6/xen/setup.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 4 ++--
include/asm-generic/fixmap.h | 2 +-
6 files changed, 6 insertions(+), 13 deletions(-)
Acked-by: Andy Lutomirski
On Tue, Sep 3, 2019 at 1:46 PM Thomas Hellström (VMware)
wrote:
>
> On 9/3/19 6:22 PM, Christoph Hellwig wrote:
> > On Tue, Sep 03, 2019 at 04:32:45PM +0200, Thomas Hellström (VMware) wrote:
> >> Is this a layer violation concern, that is, would you be ok with a similar
> >> helper for TTM, or is
On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
wrote:
>
> On 9/3/19 10:51 PM, Dave Hansen wrote:
> > On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote:
> >> So the question here should really be, can we determine already at mmap
> >> time whether backing memory will be unencrypted and a
> On Sep 3, 2019, at 3:15 PM, Thomas Hellström (VMware)
> wrote:
>
>> On 9/4/19 12:08 AM, Thomas Hellström (VMware) wrote:
>>> On 9/3/19 11:46 PM, Andy Lutomirski wrote:
>>> On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware)
>>> wrote:
On 7/10/23 15:32, Mina Almasry wrote:
Add an interface for the user to notify the kernel that it is done reading
the NET_RX dmabuf pages returned as cmsg. The kernel will drop the
reference on the NET_RX pages to make them available for re-use.
Signed-off-by: Mina Almasry
---
+
On 7/10/23 15:32, Mina Almasry wrote:
* TL;DR:
Device memory TCP (devmem TCP) is a proposal for transferring data to and/or
from device memory efficiently, without bouncing the data to a host memory
buffer.
(I'm writing this as someone who might plausibly use this mechanism, but
I don't think
I have the signed firmware (I think) and I'm running a fresh 4.6
kernel. I got an image to show up briefly, rendering the Fedora
sign-in screen at something like one frame per ten seconds. But then
I got all kinds of garbage, and I see:
[ 719.300820] nouveau :09:00.0: disp: outp 04:0006:0f4
On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin wrote:
> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote:
>> On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin wrote:
>>> Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2.
>>>
>>
>>
play output in general is unreliable enough that I'm having
trouble telling whether the performance is remotely reasonable.
--Andy
> Cheers,
>
> -ilia
>
> On Sat, May 28, 2016 at 4:51 PM, Andy Lutomirski wrote:
>> I have the signed firmware (I think) and I'm runn
On Sun, Jan 10, 2016 at 11:12 AM, Andy Lutomirski
wrote:
> On Sun, Jan 10, 2016 at 10:41 AM, Andy Lutomirski
> wrote:
>> On Wed, Nov 18, 2015 at 8:12 AM, Daniel Stone
>> wrote:
>>> Hi,
>>>
>>> On 18 November 2015 at 15:59, Andy Lutomirski
&g
On Thu, Jan 7, 2016 at 2:16 AM, Chris Wilson
wrote:
> On Mon, Oct 19, 2015 at 10:58:55AM +0100, Chris Wilson wrote:
>> During testing we observed that the last cacheline was not being flushed
>> from a
>>
>> mb()
>> for (addr = addr & -clflush_size; addr < end; addr += clflush_size)
>
lt?
No clue, but I don't know much about the underlying architecture.
Can you try clflush_cache_ranging one cacheline less and then manually
doing clflushopt; mb on the last cache line, just to make sure that
the helper is really doing the right thing? You could also try
clflush instead of clflushopt to see if that makes a difference.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
On Wed, Nov 18, 2015 at 8:12 AM, Daniel Stone wrote:
> Hi,
>
> On 18 November 2015 at 15:59, Andy Lutomirski wrote:
>> On Wed, Nov 18, 2015 at 2:59 AM, Ville Syrjälä
>> wrote:
>>> On Tue, Nov 17, 2015 at 11:43:25AM -0800, Andy Lutomirski wrote:
>>>
On Sun, Jan 10, 2016 at 10:41 AM, Andy Lutomirski
wrote:
> On Wed, Nov 18, 2015 at 8:12 AM, Daniel Stone wrote:
>> Hi,
>>
>> On 18 November 2015 at 15:59, Andy Lutomirski wrote:
>>> On Wed, Nov 18, 2015 at 2:59 AM, Ville Syrjälä
>>> wrote:
>>>
On Tue, Jan 12, 2016 at 6:06 PM, Linus Torvalds
wrote:
> On Tue, Jan 12, 2016 at 4:55 PM, Chris Wilson
> wrote:
>>
>> The double clflush() remains a mystery.
>
> Actually, I think it's explainable.
>
> It's wrong to do the clflush *after* the GPU has done the write, which
> seems to be what you
I have a Dell XPS 13 9350 (Skylake) and a Dell DA200 adapter. The
latter is a Thunderbolt device that includes an HDMI port and connects
over USB Type C. I believe that it's internally using DP Alternate
Mode.
When I plug it in on 4.7-rc4, I get spew like this:
[ 90.718106] [drm:intel_dp_star
On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski wrote:
> On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin wrote:
>> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote:
>>> On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin
>>> wrote:
>>>> Do you have mes
On Sun, Jun 26, 2016 at 10:59 AM, Ilia Mirkin wrote:
> On Sun, Jun 26, 2016 at 1:49 PM, Andy Lutomirski
> wrote:
>> On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski wrote:
>>> On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin
>>> wrote:
>>>> On Sun
On Jun 17, 2014 2:48 AM, "Florian Weimer" wrote:
>
> On 04/10/2014 10:37 PM, Andy Lutomirski wrote:
>
>> It occurs to me that, before going nuts with these kinds of flags, it
>> may pay to just try to fix the /proc/self/fd issue for real -- we
>> could jus
On Fri, Aug 9, 2013 at 11:36 AM, Daniel Vetter wrote:
> On Fri, Aug 9, 2013 at 8:12 PM, Andy Lutomirski wrote:
>> On Thu, Aug 8, 2013 at 6:41 AM, Daniel Vetter wrote:
>>> The new arch_phys_wc_add/del functions do the right thing both with
>>> and without MTRR suppo
On Thu, Aug 8, 2013 at 6:41 AM, Daniel Vetter wrote:
> The new arch_phys_wc_add/del functions do the right thing both with
> and without MTRR support in the kernel. So we can drop these
> additional checks.
If any of the new arch_phys_wc_add calls are reachable and if the
driver calls arch_phys_w
On Fri, Aug 9, 2013 at 11:47 AM, Daniel Vetter wrote:
> On Fri, Aug 9, 2013 at 8:39 PM, Andy Lutomirski wrote:
>> On Fri, Aug 9, 2013 at 11:36 AM, Daniel Vetter
>> wrote:
>>> On Fri, Aug 9, 2013 at 8:12 PM, Andy Lutomirski wrote:
>>>> On Thu, Aug 8, 2013 at
On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> Add support for the new pcommit instruction. This instruction was
> announced in the document "Intel Architecture Instruction Set Extensions
> Programming Reference" with reference number 319433-022.
>
> https://software.intel.com/sites/default/files/
On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> If clwb is available on the system, use it in drm_clflush_virt_range.
> If clwb is not available, fall back to clflushopt if you can.
> If clflushopt is not supported, fall all the way back to clflush.
I don't know exactly what drm_clflush_virt_range (
On Nov 13, 2014 3:20 AM, "Borislav Petkov" wrote:
>
> On Wed, Nov 12, 2014 at 07:14:21PM -0800, Andy Lutomirski wrote:
> > On 11/11/2014 10:43 AM, Ross Zwisler wrote:
> > > If clwb is available on the system, use it in drm_clflush_virt_range.
> > >
On Fri, Nov 14, 2014 at 1:07 PM, Ross Zwisler
wrote:
> On Wed, 2014-11-12 at 19:25 -0800, Andy Lutomirski wrote:
>> On 11/11/2014 10:43 AM, Ross Zwisler wrote:
>> > Add support for the new pcommit instruction. This instruction was
>> > announced in the document &quo
I have a Caicos card, like this:
[3.077260] [drm] radeon kernel modesetting enabled.
[3.077338] checking generic (e000 60) vs hw (e000 1000)
[3.077339] fb: switching to radeondrmfb from EFI VGA
[3.077377] Console: switching to colour dummy device 80x25
[3.078881
On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer wrote:
> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>
>> I have a Caicos card, like this:
>>
>> [3.077260] [drm] radeon kernel modesetting enabled.
>> [3.077338] checking generic (e000 60
On Tue, Nov 18, 2014 at 4:21 PM, Andy Lutomirski wrote:
> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer wrote:
>> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>>
>>> I have a Caicos card, like this:
>>>
>>> [3.077260] [drm] radeon kernel mod
On Tue, Nov 18, 2014 at 4:34 PM, Andy Lutomirski wrote:
> On Tue, Nov 18, 2014 at 4:21 PM, Andy Lutomirski
> wrote:
>> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer
>> wrote:
>>> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>>>
>>>> I hav
My Dell XPS 13 9350 laptop just got a buffer underrun:
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A
FIFO underrun
I'm seeing this very occasionally, and they don't come in groups -- I
seem to get one underrun with a black flash and that's it. This is
with just the laptop s
[53834.386369] traps: gnome-session-b[2308] general protection
ip:7f10efc1fc2b sp:7ffdfde31880 error:0 in
libc-2.22.so[7f10efba1000+1b7000]
[53834.687584] [ cut here ]
[53834.687607] WARNING: CPU: 0 PID: 23730 at
drivers/gpu/drm/i915/i915_gem_context.c:144
i915_gem_context_f
On Tue, Sep 16, 2014 at 9:45 AM, Bjorn Helgaas wrote:
> On Thu, Mar 27, 2014 at 11:30:37AM -0600, Bjorn Helgaas wrote:
>> On Mon, Mar 24, 2014 at 4:04 PM, Bjorn Helgaas
>> wrote:
>> > On Sat, Mar 22, 2014 at 9:18 AM, Andy Lutomirski
>> > wrote:
>> &g
Hi-
As requested in your blog post, I tested PSR. I see something like
2.69W with PSR off and 2.17W with PSR on. Screen blanking,
suspend/resume, and the contents of the screen all seem okay. This is
a Dell XPS 13 9350, i.e.:
System Information
Manufacturer: Dell Inc.
Product N
On Thu, Feb 1, 2018 at 9:40 AM, Andy Lutomirski wrote:
> Hi-
>
> As requested in your blog post, I tested PSR. I see something like
> 2.69W with PSR off and 2.17W with PSR on. Screen blanking,
> suspend/resume, and the contents of the screen all seem okay. This is
> a Del
On Thu, Feb 1, 2018 at 9:53 AM, Chris Wilson wrote:
> Quoting Andy Lutomirski (2018-02-01 17:40:22)
>> *However*, I do see one unfortunate side effect of turning on PSR. It
>> seems that, when I move my cursor a little bit after a few seconds of
>> doing nothing, there see
On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson wrote:
> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>> I got this after a recent suspend/resume:
>>
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
>> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enume
On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson wrote:
>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>>> I got this after a recent suspend/resume:
>>>
>>> Feb 01 09:44:34 laptop systemd-logind[2412]: Li
On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
>> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson
>> wrote:
>>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>>>> I got this after a recent suspe
On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
wrote:
>
> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
>> I updated to 4.15, and the situation is much worse. With
>> enable_psr=1, the system survives for several seconds and then the
>> screen stops
On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
>> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson
>> wrote:
>>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>>>> I got this after a recent suspe
On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski wrote:
> On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
> wrote:
>>
>> On Fri, 2018-02-02 at 19:18 +0000, Andy Lutomirski wrote:
>>> I updated to 4.15, and the situation is much worse. With
>>> enable_ps
On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
wrote:
>
>
>
> On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
>> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski wrote:
>> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
>> > wrote:
>
On Mon, Feb 5, 2018 at 9:17 PM, Pandiyan, Dhinakaran
wrote:
>
> On Mon, 2018-02-05 at 20:35 +, Andy Lutomirski wrote:
>> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
>> wrote:
>> >
>> >
>> >
>> > On Sun, 2018-02-04 at 21:50 +,
ded. This adds
a new function intel_psr_schedule(), which will enable PSR after
the requested time but no sooner.
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 +++--
drivers/gpu/drm/i915/i915_drv.h | 4 ++-
drivers/gpu/drm/i915/inte
> On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi wrote:
>
>> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote:
>>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski wrote:
>>>> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski wrote:
>>>>&
ch on that bugzilla entry but only now I stop to
>> really think why I have written the code that way.
>>
>> So some clarity below.
>>
>>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
>>> The current PSR code has a two call sites that eac
ed with PSR and sorry for not replying sooner.
>>>>
>>>> I first saw this patch on that bugzilla entry but only now I stop to
>>>> really think why I have written the code that way.
>>>>
>>>> So some clarity below.
>>>>
On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote:
> On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
>> The purpose of this series is to:
>>
>> - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment"
>> messages reported by Linus [1], Andy [2], and others.
>>
>>
On Fri, Mar 11, 2016 at 3:29 PM, Bjorn Helgaas wrote:
> On Fri, Mar 11, 2016 at 01:16:09PM -0800, Andy Lutomirski wrote:
>> On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote:
>> > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
>> >> Th
On Mon, Feb 22, 2016 at 7:13 PM, Andy Lutomirski wrote:
> On Wed, Feb 17, 2016 at 5:36 PM, Andy Lutomirski
> wrote:
>> On Wed, Feb 17, 2016 at 8:18 AM, Daniel Vetter wrote:
>>> On Tue, Feb 16, 2016 at 09:26:35AM -0800, Andy Lutomirski wrote:
>>>> On T
On Wed, Feb 17, 2016 at 8:18 AM, Daniel Vetter wrote:
> On Tue, Feb 16, 2016 at 09:26:35AM -0800, Andy Lutomirski wrote:
>> On Tue, Feb 16, 2016 at 9:12 AM, Andy Lutomirski
>> wrote:
>> > On Tue, Feb 16, 2016 at 8:12 AM, Daniel Vetter wrote:
>> >> On Mon, Fe
Hi all-
AFAICT something got rather screwed up in i915 land for 4.5.
$ git log --oneline --grep='Pretend cursor is always on' v4.5
drivers/gpu/drm/i915/
e2e407dc093f drm/i915: Pretend cursor is always on for ILK-style WM
calculations (v2)
$ git log --oneline --grep='Pretend cursor is always on'
On Tue, Mar 29, 2016 at 12:43 AM, Daniel Vetter
wrote:
> On Tue, Mar 29, 2016 at 4:39 AM, Andy Lutomirski
> wrote:
>> AFAICT something got rather screwed up in i915 land for 4.5.
>>
>> $ git log --oneline --grep='Pretend cursor is always on' v4.5
>> d
On Tue, Mar 29, 2016 at 12:49 AM, Andy Lutomirski
wrote:
> On Tue, Mar 29, 2016 at 12:43 AM, Daniel Vetter
> wrote:
>> On Tue, Mar 29, 2016 at 4:39 AM, Andy Lutomirski
>> wrote:
>>> AFAICT something got rather screwed up in i915 land for 4.5.
>>>
>
there anything I can do to debug this? I don't really need
mgag200, since I do pretty much everything via serial console.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freed
On Thu, Aug 23, 2012 at 4:22 PM, Dave Airlie wrote:
> On Fri, Aug 24, 2012 at 7:51 AM, Andy Lutomirski wrote:
>> mgag200 hangs like this on startup, on a Dell PowerEge 12g box. The
>> serial console says:
>
> You can apply this
>
> https://patchwork.kernel.org/p
rdware and software vblank
counts.
Signed-off-by: Andy Lutomirski
---
Rather than tweaking more things to reduce the chance of hitting a race
while keeping the vblank disable timeout as low as possible, why not
just fix the race?
This compiles but is not very well tested, because I don't know wh
On Mon, Nov 21, 2011 at 2:34 PM, Andy Lutomirski wrote:
> On Mon, Nov 21, 2011 at 2:11 PM, Linus Torvalds
> wrote:
>> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>>>
>>> Subject : [3.1 REGRESSION] Commit
>>> 5cec93c216db77c45f7ce970d4628
On Mon, Nov 21, 2011 at 2:18 PM, Linus Torvalds
wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>>
>> Subject : hugetlb oops on 3.1.0-rc8-devel
>> Submitter : Andy Lutomirski
>> Date : 2011-11-01 22:20
>> Message-ID :
>
On Mon, Nov 21, 2011 at 2:11 PM, Linus Torvalds
wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki wrote:
>>
>> Subject : [3.1 REGRESSION] Commit
>> 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
>> Submitter : Nix
>> Date : 2011-11-14 0:40
>> Me
Every day or so, I'll click something and my screens go blank for a
second or two. dmesg complains about a lockup, and afterwards
everything is painfully slow. (Even switching focus to other emacs
windows takes a second or two.) Once this happens, if I restart X, I
get a blank screen, although t
On Mon, Apr 8, 2013 at 7:01 AM, Alex Deucher wrote:
> On Fri, Apr 5, 2013 at 5:11 PM, Andy Lutomirski wrote:
>> Every day or so, I'll click something and my screens go blank for a
>> second or two. dmesg complains about a lockup, and afterwards
>> everything is painfu
On Thu, Apr 18, 2013 at 2:12 PM, Alex Deucher wrote:
> On Thu, Apr 18, 2013 at 5:11 PM, Andy Lutomirski wrote:
>> On Mon, Apr 8, 2013 at 7:01 AM, Alex Deucher wrote:
>>> On Fri, Apr 5, 2013 at 5:11 PM, Andy Lutomirski wrote:
>>>> Every day or so, I'll clic
On Mon, Apr 22, 2013 at 10:55 PM, Michel Dänzer wrote:
> On Mon, 2013-04-22 at 16:19 -0700, Andy Lutomirski wrote:
>> On Thu, Apr 18, 2013 at 2:12 PM, Alex Deucher wrote:
>> > On Thu, Apr 18, 2013 at 5:11 PM, Andy Lutomirski
>> > wrote:
>> >> On Mo
On Tue, Apr 23, 2013 at 10:15 AM, Michel Dänzer wrote:
> On Die, 2013-04-23 at 10:08 -0700, Andy Lutomirski wrote:
>> On Mon, Apr 22, 2013 at 10:55 PM, Michel Dänzer wrote:
>> > On Mon, 2013-04-22 at 16:19 -0700, Andy Lutomirski wrote:
>> >
>> >> I'
out half of the mtrr_add calls in drivers/.
The series is also at:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cleanup
Andy Lutomirski (7):
x86: Add mtrr_{add,del}_wc_if_needed
drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Rework
drm_mtrr_{add,del}
drm: Update
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/mtrr.h | 21
arch/x86/kernel/cpu/mtrr/main.c | 53 +
2 files changed, 74 insertions(+)
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index e235582..cc96
This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything) and it uses
mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems
that don't need them.
Signed-off-by: Andy Lutom
Signed-off-by: Andy Lutomirski
---
This needs careful review. I don't really know what this code does, nor
do I have the hardware. (I don't understand AGP and the associated
caching implications.)
drivers/gpu/drm/drm_bufs.c | 11 ---
drivers/gpu/drm/drm_vm.c | 13 ++
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/drm_pci.c | 8
drivers/gpu/drm/drm_stub.c | 10 ++
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index bd719e9..3628683 100644
--- a/drivers/gpu/drm
i915 open-coded logic that was essentially equivalent to the new
drm_mtrr_{add,del}_wc.
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/i915/i915_dma.c | 43 ++---
1 file changed, 6 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d3aface..01d4906 100644
--- a/drivers/gpu/drm/radeon
addition of a WC MTRR, adding a non-conflicting MTRR is pointless; it's
better to just turn off MTRR support entirely.
As an added bonus, any MTRR added is freed on unload.
Signed-off-by: Andy Lutomirski
---
I can't test this -- the link to v86d in Documentation/fb/uvesafb.txt
seems to
On Sat, May 4, 2013 at 10:45 AM, Daniel Vetter wrote:
> On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote:
>> This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc. The
>> interface is simplified (because the base and size parameters to
>> drm_mtrr_del ne
On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski wrote:
> Signed-off-by: Andy Lutomirski
> ---
>
> This needs careful review. I don't really know what this code does, nor
> do I have the hardware. (I don't understand AGP and the associated
> caching implications.)
T
On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote:
> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski wrote:
>> On Fri, May 3, 2013 at 4:00 PM, Andy Lutomirski wrote:
>>> Signed-off-by: Andy Lutomirski
>>> ---
>>>
>>> This needs careful review.
On Tue, May 7, 2013 at 7:08 AM, Alex Deucher wrote:
> On Mon, May 6, 2013 at 7:39 PM, Andy Lutomirski wrote:
>> On Mon, May 6, 2013 at 4:04 PM, Jerome Glisse wrote:
>>> On Mon, May 6, 2013 at 5:22 PM, Andy Lutomirski wrote:
>>>> On Fri, May 3, 2013 at 4:00 PM
ict warnings on PAT systems
- Eventual unexporting of the MTRR API?
This series eliminates about half of the mtrr_add calls in drivers/.
Changes from v1:
- Helpers renamed
- Lots of bugs fixed
The series is also at:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_clean
ly
warning pointlessly on PAT-supporting systems.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/io.h | 7 ++
arch/x86/include/asm/mtrr.h | 5 -
arch/x86/kernel/cpu/mtrr/main.c | 48 +
include/linux/io.h
This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/ast/ast_
pgprot_writecombine.
The non-WC DRM_REGISTERS case now uses pgprot_noncached instead of
hardcoding the bit twiddling.
The DRM_AGP case is unchanged for now.
Signed-off-by: Andy Lutomirski
---
Unlike v1, this should work well even for drivers that call
drmAddMap from userspace. I didn't understand how the
epending on the architecture and PAT
availability. But cacheable access to the aperture seems like it's
asking for trouble, because, AIUI, the aperture is an alias of RAM.
Signed-off-by: Andy Lutomirski
---
It's conceivable that libpciaccess could have issues with this due to
memtype confl
i915 open-coded logic that was essentially equivalent to the new API.
Signed-off-by: Andy Lutomirski
---
Changes from v1: More cleanup
drivers/gpu/drm/i915/i915_dma.c | 44 ++---
1 file changed, 6 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d3aface..15cd34b 100644
--- a/drivers/gpu/drm/radeon
addition of a WC MTRR, adding a non-conflicting MTRR is pointless; it's
better to just turn off MTRR support entirely.
As an added bonus, any MTRR added is freed on unload.
Signed-off-by: Andy Lutomirski
---
Documentation/fb/uvesafb.txt | 16 --
drivers/video/uvesafb.c
There are no users left in drivers/gpu.
Signed-off-by: Andy Lutomirski
---
This is new in v2. The code I'm deleting is kind of gross.
include/drm/drmP.h | 5 +
include/drm/drm_os_linux.h | 16
2 files changed, 1 insertion(+), 20 deletions(-)
diff --
On Thu, May 9, 2013 at 4:44 PM, Jerome Glisse wrote:
> On Thu, May 9, 2013 at 3:46 PM, Andy Lutomirski wrote:
>> A fair number of drivers (mostly graphics) add write-combining MTRRs.
>> Most ignore errors and most add the MTRR even on PAT systems which don't
>> n
On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter wrote:
> On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
>> Several drivers currently use mtrr_add through various #ifdef guards
>> and/or drm wrappers. The vast majority of them want to add WC MTRRs
>> on
On Fri, May 10, 2013 at 12:09 PM, Daniel Vetter wrote:
> On Fri, May 10, 2013 at 11:00:56AM -0700, Andy Lutomirski wrote:
>> On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter wrote:
>> > On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
>> >> Several
s renamed
- Lots of bugs fixed
Andy Lutomirski (9):
Add arch_phys_wc_{add,del} to manipulate WC MTRRs if needed
drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Remove
drm_mtrr_{add,del}
drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
drm,agpgart: Use pgprot_writecomb
ly
warning pointlessly on PAT-supporting systems.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
Changes from v2:
- Make MTRR_TO_PHYS_WC_OFFSET a macro instead of open-coding it.
- Add phys_wc_to_mtrr_index to make drmGetMap keep working. Sigh.
arch/x86/include/asm/io.h | 7
This replaces drm_mtrr_{add,del} with arch_phys_wc_{add,del}. The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything), and it no longer adds MTRRs on
systems that don't need them.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutom
pgprot_writecombine.
The non-WC DRM_REGISTERS case now uses pgprot_noncached instead of
hardcoding the bit twiddling.
The DRM_AGP case is unchanged for now.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/drm_bufs.c | 17 +
drivers/gpu/drm/drm_vm.c | 23
epending on the architecture and PAT
availability. But cacheable access to the aperture seems like it's
asking for trouble, because, AIUI, the aperture is an alias of RAM.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
It's conceivable that libpciaccess could have issues with this
i915 open-coded logic that was essentially equivalent to the new API.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
Changes from v1: Don't zero the mtrr handle after freeing it
drivers/gpu/drm/i915/i915_dma.c | 42 -
1 file chang
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d3aface..15cd34b 100644
--- a
addition of a WC MTRR, adding a non-conflicting MTRR is pointless; it's
better to just turn off MTRR support entirely.
As an added bonus, any MTRR added is freed on unload.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
Documentation/fb/uvesafb.txt | 16 --
drivers/
There are no users left in drivers/gpu.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
include/drm/drmP.h | 5 +
include/drm/drm_os_linux.h | 16
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
I didn't fix this in the earlier patch -- it would have broken the
build due to the now-deleted garbage in drm_os_linux.h.
Reviewed-by: Daniel Vetter
Signed-off-by: Andy Lutomirski
---
drivers/gpu/drm/drm_bufs.c | 9 +
drivers/gpu/drm/drm_ioctl.c | 15 ++-
2 files ch
1 - 100 of 226 matches
Mail list logo
