> ==
> Augmented Page Reclaim
> ==
> We would like to share a work with you and see if there is enough
> interest to warrant a run for the mainline. This work is a part of
> result from a decade of research and experimentation in memory
> overcommit at
On Thu, Nov 19, 2020 at 11:19 AM Bjorn Helgaas wrote:
>
> [+cc Jesse]
>
> On Thu, Nov 19, 2020 at 10:37:10AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 19, 2020 at 12:14 AM Bjorn Helgaas wrote:
> > > On Wed, Nov 18, 2020 at 10:57:26PM +0100, Daniel Vetter wrote:
> > > > On Wed, Nov 18, 2020 at
t; >>> ../arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of
> >>> function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
> >>> [-Werror=implicit-function-declaration]
> >>>acpi_noirq_set();
> >
> > Reviewed-by: And
tion ‘intel_mid_pci_init’:
> ../arch/x86/pci/intel_mid_pci.c:303:2: error: implicit declaration of
> function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
> [-Werror=implicit-function-declaration]
> acpi_noirq_set();
>
> Signed-off-by: Randy Dunlap
> Cc: Jacob Pan
> Cc: Le
> > I think your suggestion to disable driver binding once the initial
> > bus/slot devices have been bound will probably work for this
> > situation. I just wanted to be clear that without some auditing,
> > fuzzing, and additional testing, we simply have to assume that drivers
> > are *not*
> > I feel a lot of resistance to the proposal, however, I'm not hearing
> > any realistic solutions that may help us to move forward. We want to
> > go with a solution that is acceptable upstream as that is our mission,
> > and also helps the community, however the behemoth task of "inspect
> >
On Thu, May 21, 2020 at 1:45 PM Joel Fernandes wrote:
>
> Hi Linus,
>
> On Thu, May 21, 2020 at 11:31:38AM -0700, Linus Torvalds wrote:
> > On Wed, May 20, 2020 at 3:26 PM Joel Fernandes (Google)
> > wrote:
> > Generally throughput benchmarks are much easier to do, how do you do
> > this latency
On 02/23/2016 08:19 AM, Simon Guinot wrote:
> On Mon, Feb 22, 2016 at 12:46:09PM -0800, Jesse Barnes wrote:
>> On 02/22/2016 05:49 AM, Alan Cox wrote:
>>>> we have some good alternatives in the form of bus and platform
>>>> drivers that
>>>> can manage
On 02/23/2016 08:19 AM, Simon Guinot wrote:
> On Mon, Feb 22, 2016 at 12:46:09PM -0800, Jesse Barnes wrote:
>> On 02/22/2016 05:49 AM, Alan Cox wrote:
>>>> we have some good alternatives in the form of bus and platform
>>>> drivers that
>>>> can manage
On 02/22/2016 05:49 AM, Alan Cox wrote:
>> we have some good alternatives in the form of bus and platform
>> drivers that
>> can manage the appropriate serialization and keep things from
>> stomping
>> on one another.
>
> It's not used much, especially nowdays. The use case is basically multi
>
On 02/22/2016 05:49 AM, Alan Cox wrote:
>> we have some good alternatives in the form of bus and platform
>> drivers that
>> can manage the appropriate serialization and keep things from
>> stomping
>> on one another.
>
> It's not used much, especially nowdays. The use case is basically multi
>
On February 20, 2016 9:12:01 AM Linus Torvalds
<torva...@linux-foundation.org> wrote:
On Fri, Feb 19, 2016 at 3:25 PM, Jesse Barnes <jbar...@virtuousgeek.org> wrote:
+Linus (the de-facto resource guy).
On 02/19/2016 01:10 PM, Vincent Pelletier wrote:
Tested-by: Vincent Pelleti
On February 20, 2016 9:12:01 AM Linus Torvalds
wrote:
On Fri, Feb 19, 2016 at 3:25 PM, Jesse Barnes wrote:
+Linus (the de-facto resource guy).
On 02/19/2016 01:10 PM, Vincent Pelletier wrote:
Tested-by: Vincent Pelletier
Hmm.
So I'm not entirely happy with the patch, because I think
+Linus (the de-facto resource guy).
On 02/19/2016 01:10 PM, Vincent Pelletier wrote:
> Hello,
>
> I finally got around to rebasing some patches, and realised that the
> patch from Simon Guinot below still gets rebased over torvalds' v4.4 .
>
> Any reason it was not applied ?
> Or was the issue
+Linus (the de-facto resource guy).
On 02/19/2016 01:10 PM, Vincent Pelletier wrote:
> Hello,
>
> I finally got around to rebasing some patches, and realised that the
> patch from Simon Guinot below still gets rebased over torvalds' v4.4 .
>
> Any reason it was not applied ?
> Or was the issue
On 11/17/2015 07:11 AM, Joerg Roedel wrote:
> Hi,
>
> here is the second version of the patch-set to implement
> proper access checks into the io-page-fault handlers of the
> AMD IOMMU and Intel VT-d drivers.
>
> Two additional patches clean up the AMD part a bit further.
> Since I can't test
On 11/17/2015 07:11 AM, Joerg Roedel wrote:
> Hi,
>
> here is the second version of the patch-set to implement
> proper access checks into the io-page-fault handlers of the
> AMD IOMMU and Intel VT-d drivers.
>
> Two additional patches clean up the AMD part a bit further.
> Since I can't test
Cc'ing Maarten and Matt; I'm guessing this may be related to one of
their recent patches.
Jesse
On 09/21/2015 11:48 AM, Dave Jones wrote:
> On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
> > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
> > >
> > > Hi Linus,
>
Cc'ing Maarten and Matt; I'm guessing this may be related to one of
their recent patches.
Jesse
On 09/21/2015 11:48 AM, Dave Jones wrote:
> On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
> > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
> > >
> > > Hi Linus,
>
On 12/16/2014 09:42 AM, Daniel Vetter wrote:
> On Tue, Dec 16, 2014 at 6:15 PM, Peter Hurley
> wrote:
>> On 12/16/2014 11:22 AM, Imre Deak wrote:
>>> On Tue, 2014-12-16 at 10:00 -0500, Peter Hurley wrote:
Fine. Just another expedient fix piled on top of other expedient fixes
that go
On 12/16/2014 09:42 AM, Daniel Vetter wrote:
On Tue, Dec 16, 2014 at 6:15 PM, Peter Hurley pe...@hurleysoftware.com
wrote:
On 12/16/2014 11:22 AM, Imre Deak wrote:
On Tue, 2014-12-16 at 10:00 -0500, Peter Hurley wrote:
Fine. Just another expedient fix piled on top of other expedient fixes
On Tue, 3 Feb 2015 13:25:51 +0100
Peter Zijlstra wrote:
> On Tue, Feb 03, 2015 at 12:27:33PM +0100, Peter Zijlstra wrote:
> > drivers/iommu/amd_iommu_v2.c-static void
> > put_device_state_wait(struct device_state *dev_state)
> > drivers/iommu/amd_iommu_v2.c-{ drivers/iommu/amd_iommu_v2.c-
> >
On Tue, 3 Feb 2015 13:25:51 +0100
Peter Zijlstra pet...@infradead.org wrote:
On Tue, Feb 03, 2015 at 12:27:33PM +0100, Peter Zijlstra wrote:
drivers/iommu/amd_iommu_v2.c-static void
put_device_state_wait(struct device_state *dev_state)
drivers/iommu/amd_iommu_v2.c-{
On Sun, 25 Jan 2015 15:16:44 +0200
Oded Gabbay wrote:
>
>
> On 11/13/2014 12:10 AM, Jesse Barnes wrote:
> > This could be useful for debug in the future if we want to track
> > major/minor faults more closely, and also avoids the put_page trick we
> > used with
On Sun, 25 Jan 2015 15:16:44 +0200
Oded Gabbay oded.gab...@amd.com wrote:
On 11/13/2014 12:10 AM, Jesse Barnes wrote:
This could be useful for debug in the future if we want to track
major/minor faults more closely, and also avoids the put_page trick we
used with gup.
In order
On Thu, 11 Dec 2014 13:11:36 -0500
Greg Kroah-Hartman wrote:
> On Thu, Dec 11, 2014 at 10:34:30AM -0700, Bjorn Helgaas wrote:
> > It looks like you added the initial pciehp driver [1], which
> > includes the following code in pciehp_disable_slot():
> >
> > + if (class_code ==
On Thu, 11 Dec 2014 13:11:36 -0500
Greg Kroah-Hartman gre...@linuxfoundation.org wrote:
On Thu, Dec 11, 2014 at 10:34:30AM -0700, Bjorn Helgaas wrote:
It looks like you added the initial pciehp driver [1], which
includes the following code in pciehp_disable_slot():
+ if (class_code ==
has been handled, and may aid with debug in the future as well.
v2: drop task accounting; GPU activity may have been submitted by a
different thread than the one binding the PASID (Joerg)
Tested-by: Oded Gabbay
Signed-off-by: Jesse Barnes
---
drivers/iommu/amd_iommu_v2.c | 84
On Thu, 6 Nov 2014 14:01:22 +0100
Joerg Roedel wrote:
> On Wed, Nov 05, 2014 at 01:51:09PM -0800, Jesse Barnes wrote:
> > On Wed, 5 Nov 2014 13:03:51 +0100
> > Joerg Roedel wrote:
> > > Thanks for testing Oded. Jesse, the patch looks good to me, except the
> >
This lets drivers like the AMD IOMMUv2 driver handle faults a bit more
simply, rather than doing tricks with page refs and get_user_pages().
Signed-off-by: Jesse Barnes
---
mm/memory.c | 1 +
mm/mmap.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index
This lets drivers like the AMD IOMMUv2 driver handle faults a bit more
simply, rather than doing tricks with page refs and get_user_pages().
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
mm/memory.c | 1 +
mm/mmap.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/mm/memory.c
On Thu, 6 Nov 2014 14:01:22 +0100
Joerg Roedel jroe...@suse.de wrote:
On Wed, Nov 05, 2014 at 01:51:09PM -0800, Jesse Barnes wrote:
On Wed, 5 Nov 2014 13:03:51 +0100
Joerg Roedel jroe...@suse.de wrote:
Thanks for testing Oded. Jesse, the patch looks good to me, except the
task
has been handled, and may aid with debug in the future as well.
v2: drop task accounting; GPU activity may have been submitted by a
different thread than the one binding the PASID (Joerg)
Tested-by: Oded Gabbay oded.gab...@amd.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
t; as spanning the CPUs and GPUs and other devices in the system,
rather than just representing the CPU activity.
> So can you please remove that code and resend the patches with Oded's
> Tested-by and Andrew Morton on Cc? I think these patches should go
> through the -mm tree.
Sure, than
than just representing the CPU activity.
So can you please remove that code and resend the patches with Oded's
Tested-by and Andrew Morton on Cc? I think these patches should go
through the -mm tree.
Sure, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from
rapi/Sumatra (Java) and OpenMP
>
> All tests passed and I didn't see any kernel error messages.
>
> So:
>
> Tested-by: Oded Gabbay
>
> Oded
>
> On 10/27/2014 05:35 PM, Jesse Barnes wrote:
>
> Thanks, I have no way of testing this, but I'm hopeful. :)
>
>
, Aparapi/Sumatra (Java) and OpenMP
All tests passed and I didn't see any kernel error messages.
So:
Tested-by: Oded Gabbay oded.gab...@amd.com
Oded
On 10/27/2014 05:35 PM, Jesse Barnes wrote:
Thanks, I have no way of testing this, but I'm hopeful. :)
Jesse
On Mon, 27 Oct 2014 17
he KFD driver and make sure
> nothing breaks for you? I really like this improvement and it would be
> great to send it upstream for v3.19.
>
> Thanks,
>
> Joerg
>
> On Fri, Oct 24, 2014 at 12:34:30PM -0700, Jesse Barnes wrote:
>
> > This lets drivers like the AM
sure
nothing breaks for you? I really like this improvement and it would be
great to send it upstream for v3.19.
Thanks,
Joerg
On Fri, Oct 24, 2014 at 12:34:30PM -0700, Jesse Barnes wrote:
This lets drivers like the AMD IOMMUv2 driver handle faults a bit more
simply, rather
has been handled, and may aid with debug in the future as well.
Signed-off-by: Jesse Barnes
---
drivers/iommu/amd_iommu_v2.c | 93 +---
1 file changed, 62 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/amd_iommu_v2.c b/drivers/iommu/amd_iommu_v2
This lets drivers like the AMD IOMMUv2 driver handle faults a bit more
simply, rather than doing tricks with page refs and get_user_pages().
Signed-off-by: Jesse Barnes
---
mm/memory.c | 1 +
mm/mmap.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index
has been handled, and may aid with debug in the future as well.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/iommu/amd_iommu_v2.c | 93 +---
1 file changed, 62 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/amd_iommu_v2.c b
This lets drivers like the AMD IOMMUv2 driver handle faults a bit more
simply, rather than doing tricks with page refs and get_user_pages().
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
mm/memory.c | 1 +
mm/mmap.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/mm/memory.c
This makes symbol lookups significantly faster at the cost of some disk
space.
Signed-off-by: Jesse Barnes
---
scripts/tags.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/tags.sh b/scripts/tags.sh
index 293828b..3de7719 100755
--- a/scripts/tags.sh
+++ b/scripts
This makes symbol lookups significantly faster at the cost of some disk
space.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
scripts/tags.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/tags.sh b/scripts/tags.sh
index 293828b..3de7719 100755
add new api calls.
I have some code that uses them, but I need a userspace user to push my
stuff. :)
I'm working on the latter bit too in Mesa, and we have demand from
Android, so we should get some users shortly.
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this l
add new api calls.
I have some code that uses them, but I need a userspace user to push my
stuff. :)
I'm working on the latter bit too in Mesa, and we have demand from
Android, so we should get some users shortly.
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from
On Thu, 14 Aug 2014 11:54:52 +0200
Maarten Lankhorst wrote:
> This allows users of dma fences to create a android fence.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Jesse Barnes
> ---
> drivers/staging/android/sync.c | 24 --
On Thu, 14 Aug 2014 11:54:52 +0200
Maarten Lankhorst maarten.lankho...@canonical.com wrote:
This allows users of dma fences to create a android fence.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Cc: Daniel Vetter dan...@ffwll.ch
Cc: Jesse Barnes jbar...@virtuousgeek.org
atible MMU in the GPU itself, so re-using the
defines makes sense. I suppose with your work you'll move them and
make them a bit more opaque? If so, we'll still want a way to get at
them directly, or access your mapping functions for generating PTE bits
for the GPU MMU.
Thanks,
--
Jesse Barn
with your work you'll move them and
make them a bit more opaque? If so, we'll still want a way to get at
them directly, or access your mapping functions for generating PTE bits
for the GPU MMU.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send
On Fri, 25 Jul 2014 23:38:06 +0200
Joerg Roedel wrote:
> On Fri, Jul 25, 2014 at 01:16:39PM -0700, Jesse Barnes wrote:
> > > To allow managing external TLBs the MMU-notifiers need to
> > > catch the moment when pages are unmapped but not yet freed.
> > > This ne
ther serialization or debug stuff, right?
Seems like a good addition, and saves us a bunch of trouble...
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
like a good addition, and saves us a bunch of trouble...
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Fri, 25 Jul 2014 23:38:06 +0200
Joerg Roedel j...@8bytes.org wrote:
On Fri, Jul 25, 2014 at 01:16:39PM -0700, Jesse Barnes wrote:
To allow managing external TLBs the MMU-notifiers need to
catch the moment when pages are unmapped but not yet freed.
This new notifier catches
On Wed, 23 Jul 2014 11:47:15 +0200
Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 9:14 PM, Jesse Barnes
> wrote:
> >> We don't have the code yet ready, but that's the direction i915 will
> >> move towards for the near future. Jesse is working on some patches
> >&g
On Wed, 23 Jul 2014 11:47:15 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Jul 22, 2014 at 9:14 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
We don't have the code yet ready, but that's the direction i915 will
move towards for the near future. Jesse is working on some patches
move towards for the near future. Jesse is working on some patches
> already.
Yeah I'd like to get some feedback from Maarten on my bits so I can get
them ready for upstream. I still need to add documentation and tests,
but I'd like to make sure the interfaces and internals get acked first.
Thanks
to add documentation and tests,
but I'd like to make sure the interfaces and internals get acked first.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
rove fruitful,
> >either because I messed it up or there's a combination of things that
> >fix the issue. So instead I did a regular git bisect between 3.12 and
> >3.13 to see which commit _broke_ things and caused the above behavior.
> > That landed me at:
> >
> >Auth
and 3.14-rc1 didn't prove fruitful,
either because I messed it up or there's a combination of things that
fix the issue. So instead I did a regular git bisect between 3.12 and
3.13 to see which commit _broke_ things and caused the above behavior.
That landed me at:
Author: Jesse Barnes
ection off if a panel is present for now ?
Looks like another option would be to add an 'e' to your forced boot
line. That should prevent the detection stuff from running. E.g. in
your case:
video=VGA-1:1366x768e
There's some info on this in Documentation/fb/modedb.txt
--
Jesse Barnes, Intel
On Tue, 11 Feb 2014 10:18:15 -0800
Greg KH wrote:
> On Tue, Feb 11, 2014 at 10:11:37AM -0800, Jesse Barnes wrote:
> > On Tue, 11 Feb 2014 08:35:41 -0800
> > Greg KH wrote:
> >
> > > On Tue, Feb 11, 2014 at 02:22:03PM +, One Thousand Gnomes wrote:
> > &g
wise running nicely and playing 3D games to 3.13-rc8
> >
> > This has now been pinned down to (confirmed by multiple people)
> >
> > commit 6c4a8962a4a078cacfc8eb5d4bd79f6343b8cd7a
> > Author: Jesse Barnes
> > Date: Tue Sep 10 14:54:42 2013 -0700
> >
> &
been pinned down to (confirmed by multiple people)
commit 6c4a8962a4a078cacfc8eb5d4bd79f6343b8cd7a
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Tue Sep 10 14:54:42 2013 -0700
drm/i915/vlv: re-enable hotplug detect based probing on VLV/BYT
which given
On Tue, 11 Feb 2014 10:18:15 -0800
Greg KH gre...@linuxfoundation.org wrote:
On Tue, Feb 11, 2014 at 10:11:37AM -0800, Jesse Barnes wrote:
On Tue, 11 Feb 2014 08:35:41 -0800
Greg KH gre...@linuxfoundation.org wrote:
On Tue, Feb 11, 2014 at 02:22:03PM +, One Thousand Gnomes wrote
option would be to add an 'e' to your forced boot
line. That should prevent the detection stuff from running. E.g. in
your case:
video=VGA-1:1366x768e
There's some info on this in Documentation/fb/modedb.txt
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list
On Thu, 12 Dec 2013 02:22:52 +0100
"Rafael J. Wysocki" wrote:
> On Wednesday, December 11, 2013 04:38:12 PM Jesse Barnes wrote:
> > On one of my BYT systems, I see a hang at resume. Based on my bisect,
> > it looks like this commit is the
Is this a known issue? If so, is there a fix somewhere already?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
/hibernate
Is this a known issue? If so, is there a fix somewhere already?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Thu, 12 Dec 2013 02:22:52 +0100
Rafael J. Wysocki r...@rjwysocki.net wrote:
On Wednesday, December 11, 2013 04:38:12 PM Jesse Barnes wrote:
On one of my BYT systems, I see a hang at resume. Based on my bisect,
it looks like this commit is the culprit:
commit
Add support for the Baytrail processor.
The hangs occur at different times, so unless the get/set functions
aren't called until we change the state, the problem may be in the
core_set_pstate function instead? Maybe it's not suited to BYT somehow?
Thanks,
--
Jesse Barnes, Intel Open Source
Baytrail support
Add support for the Baytrail processor.
The hangs occur at different times, so unless the get/set functions
aren't called until we change the state, the problem may be in the
core_set_pstate function instead? Maybe it's not suited to BYT somehow?
Thanks,
--
Jesse Barnes
We've always been able to use either method on VLV, but it appears more
recent BIOSes only support the gen6 method, so switch over to that.
References: https://bugs.freedesktop.org/show_bug.cgi?id=71370
Signed-off-by: Jesse Barnes
---
arch/x86/kernel/early-quirks.c | 4 ++--
1 file changed, 2
We've always been able to use either method on VLV, but it appears more
recent BIOSes only support the gen6 method, so switch over to that.
References: https://bugs.freedesktop.org/show_bug.cgi?id=71370
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
arch/x86/kernel/early-quirks.c | 4
t; Because my shiny new 65W haswell is really nice and does a "make
> allmodconfig" in half the time of my old machine, but the GPU side has
> been something of a step backwards...
Well we definitely don't want that...
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubs
the time of my old machine, but the GPU side has
been something of a step backwards...
Well we definitely don't want that...
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On Thu, 29 Aug 2013 12:18:14 -0400
Joseph Salisbury wrote:
> On 08/14/2013 05:11 PM, Linus Torvalds wrote:
> > On Wed, Aug 14, 2013 at 9:38 AM, Jesse Barnes
> > wrote:
> >> Linus, you may want to pick this up directly, as I'm not sure if
> >> Matthew is st
On Thu, 29 Aug 2013 12:18:14 -0400
Joseph Salisbury joseph.salisb...@canonical.com wrote:
On 08/14/2013 05:11 PM, Linus Torvalds wrote:
On Wed, Aug 14, 2013 at 9:38 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Linus, you may want to pick this up directly, as I'm not sure if
Matthew
esn't support the feature, so requesting it be blacklisted for now.
>
> Signed-off-by: Joseph Salisbury
> Tested-by: Nick Jenkins
> Cc: Jesse Barnes
> Cc: platform-driver-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org
> ---
> d
doesn't support the feature, so requesting it be blacklisted for now.
Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
Tested-by: Nick Jenkins tech.crew.jenk...@gmail.com
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-kernel
ut you'll need docs for it. Charlie
Huang ought to be able to get you the NDA docs that should have the
info you need.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj
to get you the NDA docs that should have the
info you need.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
s)
v3: use a function pointer (Chris)
drop gen2 bits (Daniel)
v4: call e820_sanitize_map after adding the region
v5: fixup comments (Peter)
simplify loop (Chris)
Acked-by: Ingo Molnar
Signed-off-by: Jesse Barnes
---
arch/x86/kernel/early-quirks
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
v4: fix up PCI match structure init for easier use by userspace (Chris)
Signed-off-by: Jesse Barnes
These address the comments I've received so far, but omit the new E820
type for this mem.
Chris's patches could go on top if desired; they add a new type and
resource reservation function for looking up regions by name. That
allows us to remove some duplicate code in the driver for finding
On Fri, 26 Jul 2013 09:58:45 -0700
"H. Peter Anvin" wrote:
> On 07/25/2013 09:37 AM, Jesse Barnes wrote:
> > Systems with Intel graphics controllers set aside memory exclusively for
> > + /*
> > +* Almost universally we can find the Graphics Base of Stolen M
f : :00:02.0
After (yay):
cb00-cb9f : RAM buffer
cba0-cf9f : reserved
cba0-cf9f : Graphics Stolen Memory
cfa0-feaf : PCI Bus :00
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line &quo
On Thu, 25 Jul 2013 20:31:27 -0700
"H. Peter Anvin" wrote:
> On 07/25/2013 07:14 PM, Jesse Barnes wrote:
> > To clarify: it'll either be marked reserved or not listed at all in e820,
> > which is why I did this early, before any other e820 stuff like the "
On Thu, 25 Jul 2013 20:31:27 -0700
H. Peter Anvin h...@zytor.com wrote:
On 07/25/2013 07:14 PM, Jesse Barnes wrote:
To clarify: it'll either be marked reserved or not listed at all in e820,
which is why I did this early, before any other e820 stuff like the RAM
buffer are allocated
: reserved
cba0-cf9f : Graphics Stolen Memory
cfa0-feaf : PCI Bus :00
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Fri, 26 Jul 2013 09:58:45 -0700
H. Peter Anvin h...@zytor.com wrote:
On 07/25/2013 09:37 AM, Jesse Barnes wrote:
Systems with Intel graphics controllers set aside memory exclusively for
+ /*
+* Almost universally we can find the Graphics Base of Stolen Memory
+* at offset
These address the comments I've received so far, but omit the new E820
type for this mem.
Chris's patches could go on top if desired; they add a new type and
resource reservation function for looking up regions by name. That
allows us to remove some duplicate code in the driver for finding
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
v4: fix up PCI match structure init for easier use by userspace (Chris)
Signed-off-by: Jesse Barnes
a function pointer (Chris)
drop gen2 bits (Daniel)
v4: call e820_sanitize_map after adding the region
v5: fixup comments (Peter)
simplify loop (Chris)
Acked-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
arch/x86/kernel/early-quirks.c | 154
On Thu, 25 Jul 2013 23:59:25 +0100
Chris Wilson wrote:
> Hmm, interesting licence block in i915_pciids.h - our claim to
> grant licence but TG disclaims liability.
Oops my manual search & replace obviously failed. Will fix up.
--
Jesse Barnes, Intel Open Source Technol
ote:
> So the bootloader is just as likely to step on things... what happens when/if
> it does?
>
> Ingo Molnar wrote:
> >
> >* Jesse Barnes wrote:
> >
> >> Patch 2/2 has the description, but suffice it to say I'm
> >> not really pleased with th
On Thu, 25 Jul 2013 22:05:51 +0200
Ingo Molnar wrote:
>
> * Jesse Barnes wrote:
>
> > Patch 2/2 has the description, but suffice it to say I'm
> > not really pleased with this, though it does solve a
> > problem we have. On some machines, we get MMIO
a function pointer (Chris)
drop gen2 bits (Daniel)
Signed-off-by: Jesse Barnes
---
arch/x86/kernel/early-quirks.c | 158 +++
drivers/gpu/drm/i915/i915_reg.h | 15
include/drm/i915_drm.h | 32
3 files changed, 190 inserti
Patch 2/2 has the description, but suffice it to say I'm not really
pleased with this, though it does solve a problem we have. On some
machines, we get MMIO space allocated on top of this hidden memory,
which can cause problems. I'm not sure if there are similar problems
for other hunks of the
1 - 100 of 832 matches
Mail list logo
