On Wed, Jun 27, 2012 at 3:27 PM, Ozan Çağlayan wrote:
> Hi,
>
> I'm maintaining a compat-drm tree (based on compat.git) as part of my
> GSoC project with Linux Foundation, under the mentorship of Luis R.
> Rodriguez.
>
> The aim of the tree is to offer the latest DRM stuff to people stuck
> with o
On 06/28/2012 11:19 AM, Lucas Stach wrote:
...
> CMA is just a way of providing large contiguous address space blocks in
> a dynamic fashion. ...
>
> TTM though solves more advanced matters, like buffer synchronisation
> between 3D and 2D block of hardware ...
>
> IMHO the best solution would be
> > Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren:
> > > On 06/28/2012 05:12 AM, Thierry Reding wrote:
> > > > On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> > > >> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> > > ...
> > > >>> In the ideal
Am Donnerstag, den 28.06.2012, 09:06 +0300 schrieb Hiroshi Doyu:
> Hi Lucas,
>
> On Wed, 27 Jun 2012 17:59:55 +0200
> Lucas Stach wrote:
>
> > > > > > Rather than introducing a new property, how about using
> > > > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > >
Hi all,
I'm not sure what your exact plans are for the direction in which the
DRM driver should head, as I'm still a bit out of the loop as many of
those matters were only discussed internally at NVIDIA or with some NDA
developers. But I'll still try to get into the discussion.
Am Mittwoch, den 2
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120628/967e55bd/attachment.pgp>
Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren:
> On 06/28/2012 05:12 AM, Thierry Reding wrote:
> > On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> >> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> ...
> >>> In the ideal case I would want to not
On Thu, Jun 28, 2012 at 5:50 PM, wrote:
> From: Alex Deucher
>
> It was stuck right in the middle of the gart functions.
> Move next to the bm_disable function and where it is used.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> ?drivers/gpu/drm/radeon/r100.c | ? 18 ++
On Thu, Jun 28, 2012 at 5:50 PM, wrote:
> From: Alex Deucher
>
> Consolidate the CS functions to one section of the file.
> Previously they were spread all around.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> ?drivers/gpu/drm/radeon/r100.c | 2983
> -
On Thu, Jun 28, 2012 at 5:53 PM, wrote:
> From: Alex Deucher
>
> Cayman and trinity allow for variable sized VM page
> tables, but SI requires that all page tables be the
> same size. ?The current code assumes variablely sized
> VM page tables so SI may end up with part of each page
> table over
Hi Thierry,
Am Donnerstag, den 28.06.2012, 13:12 +0200 schrieb Thierry Reding:
> On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> > Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> > > On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> > > > On Wed, 27
https://bugs.freedesktop.org/show_bug.cgi?id=50149
--- Comment #16 from Roman ?makal 2012-06-28
11:47:19 PDT ---
For me Lightsmark is slightly better in first scene, textures at least appears
(but colors and shade are flickering) but its not really okayish. Reflections
not working and so on. Any
> Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren:
> > On 06/28/2012 05:12 AM, Thierry Reding wrote:
> > > On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> > >> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> > ...
> > >>> In the ideal case I would
From: Alex Deucher
Cayman and trinity allow for variable sized VM page
tables, but SI requires that all page tables be the
same size. The current code assumes variablely sized
VM page tables so SI may end up with part of each page
table overlapping with other memory which could end
up being inte
From: Alex Deucher
It was stuck right in the middle of the gart functions.
Move next to the bm_disable function and where it is used.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/
From: Alex Deucher
Consolidate the CS functions to one section of the file.
Previously they were spread all around.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 2983 -
1 files changed, 1491 insertions(+), 1492 deletions(-)
diff --git
On 28.06.2012 16:25, alexdeucher at gmail.com wrote:
> From: Alex Deucher
>
> It's not used anywhere else.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon_fence.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a
On Thu, Jun 28, 2012 at 5:50 PM, wrote:
> From: Alex Deucher
>
> It was stuck right in the middle of the gart functions.
> Move next to the bm_disable function and where it is used.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/r100.c | 18 ++
On Thu, Jun 28, 2012 at 5:53 PM, wrote:
> From: Alex Deucher
>
> Cayman and trinity allow for variable sized VM page
> tables, but SI requires that all page tables be the
> same size. The current code assumes variablely sized
> VM page tables so SI may end up with part of each page
> table over
On Thu, Jun 28, 2012 at 09:51:58PM +0200, Johannes Obermayr wrote:
These patches should be sent to dri-devel, not mesa-dev.
> ---
> xf86drm.c | 15 ++-
> 1 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 6ea068f..798f1fd 100644
> ---
From: Alex Deucher
Cayman and trinity allow for variable sized VM page
tables, but SI requires that all page tables be the
same size. The current code assumes variablely sized
VM page tables so SI may end up with part of each page
table overlapping with other memory which could end
up being inte
From: Alex Deucher
It was stuck right in the middle of the gart functions.
Move next to the bm_disable function and where it is used.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/
On Thu, Jun 28, 2012 at 01:58:54PM +0200, Lekensteyn wrote:
> On Thursday 28 June 2012 13:22:02 Daniel Vetter wrote:
> > On Thu, Jun 28, 2012 at 1:05 PM, Daniel Vetter wrote:
> > > - When loading the i915.ko with the CADL patch the screen went black
> > > (like at boot), but with some excessive vt
On Thu, Jun 28, 2012 at 02:05:16PM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> New -next pull request. Highlights:
> - Remaining vlv patches from Jesse et al.
> - Some hw workarounds from Jesse
> - hw context support from Ben
> - full uncore sharing on ivb
> - prep work to move the gtt code from in
to
find some time to work all the changes into a new binding proposal and
get working on the code.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120628/b984f7b2/attachment.pgp>
Hi Dave,
New -next pull request. Highlights:
- Remaining vlv patches from Jesse et al.
- Some hw workarounds from Jesse
- hw context support from Ben
- full uncore sharing on ivb
- prep work to move the gtt code from intel-gtt.c to drm/i915 for gen6+
- some backlight code improvements
- leftovers
On Thursday 28 June 2012 13:22:02 Daniel Vetter wrote:
> On Thu, Jun 28, 2012 at 1:05 PM, Daniel Vetter wrote:
> > - When loading the i915.ko with the CADL patch the screen went black
> > (like at boot), but with some excessive vt-switching and X restarting
> > I've managed to light it up. Althoug
ut = <0x0400>;". Or "contiguous-memory" or whatever.
Thierry
------ next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120628/ddadaa40/attachment.pgp>
Hi Linus,
Nearly all intel, one missing license header in nouveau, nothing majorly
earth shattering.
Dave.
The following changes since commit d1346a6cbabf6d377d753f1adc16cb0b305830cc:
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
(2012-06-26 11:26:50 -0700)
are a
On Thu, Jun 28, 2012 at 1:05 PM, Daniel Vetter wrote:
> - When loading the i915.ko with the CADL patch the screen went black
> (like at boot), but with some excessive vt-switching and X restarting
> I've managed to light it up. Although it is flickery as hell,
> especially the lower part of the sc
ge allocations outside of the DRM. host1x is the most logical
choice here.
Perhaps we can put host1x code somewhere below drivers/gpu (mm
subdirectory?), drivers/memory or perhaps some other or new location
that could eventually host similar drivers for other SoCs.
Then again, maybe it'd be easier for now to put everything below the
drivers/gpu/drm/tegra directory and cross that bridge when we get to it.
> > > I think that "coherent_pool" can be used only when the amount of
> > > contiguous memory is short in your system. Otherwise even unnecessary.
> > >
> > > Could you explain a bit more why you want carveout size on per-board
> > > basis?
> >
> > In the ideal case I would want to not have a carveout size at all.
> > However there may be situations where you need to make sure some driver
> > can allocate a given amount of memory. Having to specify this using a
> > kernel command-line parameter is cumbersome because it may require
> > changes to the bootloader or whatever. So if you know that a particular
> > board always needs 128 MiB of carveout, then it makes sense to specify
> > it on a per-board basis.
>
> If we go with CMA, this is a non-issue, as CMA allows to use the contig
> area for normal allocations and only purges them if it really needs the
> space for contig allocs.
CMA certainly sounds like the most simple approach. While it may not be
suited for 3D graphics or multimedia processing later on, I think we
could use it at a starting point to get basic framebuffer and X support
up and running. We can always move to something more advanced like TTM
later.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120628/6e7c9abb/attachment.pgp>
-
A non-text attachment was scrubbed...
Name: dmidecode
Type: application/octet-stream
Size: 9877 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120628/c7b1d6b9/attachment.obj>
witcheroo_client_ops.patch
Type: application/octet-stream
Size: 3393 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120628/091a7df7/attachment.obj>
https://bugs.freedesktop.org/show_bug.cgi?id=50149
--- Comment #16 from Roman Šmakal 2012-06-28 11:47:19
PDT ---
For me Lightsmark is slightly better in first scene, textures at least appears
(but colors and shade are flickering) but its not really okayish. Reflections
not working and so on. Any
On 06/28/2012 11:19 AM, Lucas Stach wrote:
...
> CMA is just a way of providing large contiguous address space blocks in
> a dynamic fashion. ...
>
> TTM though solves more advanced matters, like buffer synchronisation
> between 3D and 2D block of hardware ...
>
> IMHO the best solution would be
On Thu, Jun 28, 2012 at 11:33:56AM -0600, Stephen Warren wrote:
> On 06/28/2012 11:19 AM, Lucas Stach wrote:
> ...
> > CMA is just a way of providing large contiguous address space blocks in
> > a dynamic fashion. ...
> >
> > TTM though solves more advanced matters, like buffer synchronisation
> >
On Mit, 2012-06-27 at 14:14 -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> After unrecovered GPU lockup avoid any GPU activities to avoid
> things like kernel segfault and alike to happen in any of the
> path that assume hw is working.
>
> The segfault is due to PCIE vram gart ta
On 06/28/2012 05:12 AM, Thierry Reding wrote:
> On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
>> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
...
>>> In the ideal case I would want to not have a carveout size at
>>> all. However there may be situations where you n
On 06/28/2012 12:18 AM, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 16:44:14 +0200
> Thierry Reding wrote:
>
>>> I think that "coherent_pool" can be used only when the amount of
>>> contiguous memory is short in your system. Otherwise even unnecessary.
>>>
>>> Could you explain a bit more why you w
On Wed, Jun 27, 2012 at 8:35 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> We need these for detecting the max link speed for drm drivers.
Hi Bjorn,
Can you ack this patch so I can carry it in the drm-next tree? we need
these regs for getting the PCIE v2/v3 supported link speeds.
Thanks,
Dave
From: Alex Deucher
It's not used anywhere else.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 7b55625..67f6fa9
Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren:
> On 06/28/2012 05:12 AM, Thierry Reding wrote:
> > On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> >> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> ...
> >>> In the ideal case I would want to not
On 06/28/2012 05:12 AM, Thierry Reding wrote:
> On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
>> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
...
>>> In the ideal case I would want to not have a carveout size at
>>> all. However there may be situations where you n
On 06/28/2012 12:18 AM, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 16:44:14 +0200
> Thierry Reding wrote:
>
>>> I think that "coherent_pool" can be used only when the amount of
>>> contiguous memory is short in your system. Otherwise even unnecessary.
>>>
>>> Could you explain a bit more why you w
On Thursday 28 June 2012 13:22:02 Daniel Vetter wrote:
> On Thu, Jun 28, 2012 at 1:05 PM, Daniel Vetter wrote:
> > - When loading the i915.ko with the CADL patch the screen went black
> > (like at boot), but with some excessive vt-switching and X restarting
> > I've managed to light it up. Althoug
Am Donnerstag, den 28.06.2012, 09:06 +0300 schrieb Hiroshi Doyu:
> Hi Lucas,
>
> On Wed, 27 Jun 2012 17:59:55 +0200
> Lucas Stach wrote:
>
> > > > > > Rather than introducing a new property, how about using
> > > > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > >
Hi Thierry,
Am Donnerstag, den 28.06.2012, 13:12 +0200 schrieb Thierry Reding:
> On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> > Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> > > On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> > > > On Wed, 27
On Wed, 27 Jun 2012 20:02:46 +0200
Stephen Warren wrote:
> On 06/27/2012 06:44 AM, Hiroshi Doyu wrote:
> ...
> > I think that there are 2 cases:
> >
> > (1) discontiguous memory with IOMMU
> > (2) contiguous memory without IOMMU(called "carveout" in general?)
> ...
> > For (2), although memo
On Wed, 27 Jun 2012 19:56:35 +0200
Stephen Warren wrote:
> On 06/27/2012 08:29 AM, Hiroshi Doyu wrote:
> > Could you explain a bit more why you want carveout size on per-board basis?
>
> Different boards have different amounts of memory, and are sometimes
> targeted at different use-cases (e.g.
On Wed, 27 Jun 2012 16:44:14 +0200
Thierry Reding wrote:
> > I think that "coherent_pool" can be used only when the amount of
> > contiguous memory is short in your system. Otherwise even unnecessary.
> >
> > Could you explain a bit more why you want carveout size on per-board basis?
>
> In the
On Wed, Jun 27, 2012 at 3:35 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> We need these for detecting the max link speed for drm drivers.
>
> Signed-off-by: Dave Airlie
For the series:
Reviewed-by: Alex Deucher
> ---
> ?include/linux/pci_regs.h | ? ?5 +
> ?1 files changed, 5 insertions
Hi Lucas,
On Wed, 27 Jun 2012 17:59:55 +0200
Lucas Stach wrote:
> > > > > Rather than introducing a new property, how about using
> > > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > > > that this carveout size depends on the system usage/load.
> > > >
> > > > I
On 28.06.2012 16:25, alexdeuc...@gmail.com wrote:
From: Alex Deucher
It's not used anywhere else.
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm
From: Alex Deucher
It's not used anywhere else.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 7b55625..67f6fa9
On Wed, Jun 27, 2012 at 3:35 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> We need these for detecting the max link speed for drm drivers.
>
> Signed-off-by: Dave Airlie
For the series:
Reviewed-by: Alex Deucher
> ---
> include/linux/pci_regs.h | 5 +
> 1 files changed, 5 insertions
On Thu, Jun 28, 2012 at 01:58:54PM +0200, Lekensteyn wrote:
> On Thursday 28 June 2012 13:22:02 Daniel Vetter wrote:
> > On Thu, Jun 28, 2012 at 1:05 PM, Daniel Vetter wrote:
> > > - When loading the i915.ko with the CADL patch the screen went black
> > > (like at boot), but with some excessive vt
On Thu, Jun 28, 2012 at 02:05:16PM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> New -next pull request. Highlights:
> - Remaining vlv patches from Jesse et al.
> - Some hw workarounds from Jesse
> - hw context support from Ben
> - full uncore sharing on ivb
> - prep work to move the gtt code from in
Hi Linus,
Nearly all intel, one missing license header in nouveau, nothing majorly
earth shattering.
Dave.
The following changes since commit d1346a6cbabf6d377d753f1adc16cb0b305830cc:
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
(2012-06-26 11:26:50 -0700)
are a
Hi Dave,
New -next pull request. Highlights:
- Remaining vlv patches from Jesse et al.
- Some hw workarounds from Jesse
- hw context support from Ben
- full uncore sharing on ivb
- prep work to move the gtt code from intel-gtt.c to drm/i915 for gen6+
- some backlight code improvements
- leftovers
On Wed, Jun 27, 2012 at 11:49:43AM -0600, Stephen Warren wrote:
> On 06/26/2012 11:07 PM, Thierry Reding wrote:
> > On Tue, Jun 26, 2012 at 04:48:14PM -0600, Stephen Warren wrote:
> ...
> > I actually like what you proposed above a lot, so if you don't
> > mind either way I'll go with that proposal
On Wed, Jun 27, 2012 at 12:02:46PM -0600, Stephen Warren wrote:
> On 06/27/2012 06:44 AM, Hiroshi Doyu wrote:
> ...
> > I think that there are 2 cases:
> >
> > (1) discontiguous memory with IOMMU
> > (2) contiguous memory without IOMMU(called "carveout" in general?)
> ...
> > For (2), although
On Thu, Jun 28, 2012 at 1:05 PM, Daniel Vetter wrote:
> - When loading the i915.ko with the CADL patch the screen went black
> (like at boot), but with some excessive vt-switching and X restarting
> I've managed to light it up. Although it is flickery as hell,
> especially the lower part of the sc
On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> > On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> > > On Wed, 27 Jun 2012 16:08:10 +0200
> > > Thierry Reding wrote:
> > >
> > > > * PGP Signed by an u
On Thu, Jun 28, 2012 at 1:24 AM, Lekensteyn wrote:
> Thank you, I've now written a partial analysis which is available at
> https://github.com/Lekensteyn/acpi-
> stuff/blob/HEAD/dsl/Asus_Zenbook_DanielVetter/analysis.txt (note: URL is cut
> in
> two parts in this mail, concat them as needed).
>
>
On Wed, Jun 27, 2012 at 8:35 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> We need these for detecting the max link speed for drm drivers.
Hi Bjorn,
Can you ack this patch so I can carry it in the drm-next tree? we need
these regs for getting the PCIE v2/v3 supported link speeds.
Thanks,
Dave
On Mit, 2012-06-27 at 14:14 -0400, j.gli...@gmail.com wrote:
> From: Jerome Glisse
>
> After unrecovered GPU lockup avoid any GPU activities to avoid
> things like kernel segfault and alike to happen in any of the
> path that assume hw is working.
>
> The segfault is due to PCIE vram gart table
Hi,
I'm maintaining a compat-drm tree (based on compat.git) as part of my
GSoC project with Linux Foundation, under the mentorship of Luis R.
Rodriguez.
The aim of the tree is to offer the latest DRM stuff to people stuck
with older kernels (Currently all of the popular and maintained drm
drivers
On Wednesday 27 June 2012 18:27:37 Daniel Vetter wrote:
> On Wed, Jun 27, 2012 at 05:09:02PM +0200, Lekensteyn wrote:
> > On Wednesday 27 June 2012 17:03:02 Daniel Vetter wrote:
> > > On Tue, Jun 26, 2012 at 11:07:55PM +0200, Daniel Vetter wrote:
> > > > On Tue, Jun 26, 2012 at 02:04:00PM -0700, Je
On Wed, 27 Jun 2012 20:02:46 +0200
Stephen Warren wrote:
> On 06/27/2012 06:44 AM, Hiroshi Doyu wrote:
> ...
> > I think that there are 2 cases:
> >
> > (1) discontiguous memory with IOMMU
> > (2) contiguous memory without IOMMU(called "carveout" in general?)
> ...
> > For (2), although memo
On Wed, 27 Jun 2012 19:56:35 +0200
Stephen Warren wrote:
> On 06/27/2012 08:29 AM, Hiroshi Doyu wrote:
> > Could you explain a bit more why you want carveout size on per-board basis?
>
> Different boards have different amounts of memory, and are sometimes
> targeted at different use-cases (e.g.
On Wed, 27 Jun 2012 16:44:14 +0200
Thierry Reding wrote:
> > I think that "coherent_pool" can be used only when the amount of
> > contiguous memory is short in your system. Otherwise even unnecessary.
> >
> > Could you explain a bit more why you want carveout size on per-board basis?
>
> In the
Hi Lucas,
On Wed, 27 Jun 2012 17:59:55 +0200
Lucas Stach wrote:
> > > > > Rather than introducing a new property, how about using
> > > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > > > that this carveout size depends on the system usage/load.
> > > >
> > > > I
On Wednesday 27 June 2012 18:27:37 Daniel Vetter wrote:
> On Wed, Jun 27, 2012 at 05:09:02PM +0200, Lekensteyn wrote:
> > On Wednesday 27 June 2012 17:03:02 Daniel Vetter wrote:
> > > On Tue, Jun 26, 2012 at 11:07:55PM +0200, Daniel Vetter wrote:
> > > > On Tue, Jun 26, 2012 at 02:04:00PM -0700, Je
On 06/27/2012 06:44 AM, Hiroshi Doyu wrote:
...
> I think that there are 2 cases:
>
> (1) discontiguous memory with IOMMU
> (2) contiguous memory without IOMMU(called "carveout" in general?)
...
> For (2), although memory is mostly anonymous one, we may need to know
> how much to allocate, whe
On 06/27/2012 08:29 AM, Hiroshi Doyu wrote:
> Could you explain a bit more why you want carveout size on per-board basis?
Different boards have different amounts of memory, and are sometimes
targeted at different use-cases (e.g. server with simple display buffer,
vs. consumer-oriented device inten
On 06/26/2012 11:07 PM, Thierry Reding wrote:
> On Tue, Jun 26, 2012 at 04:48:14PM -0600, Stephen Warren wrote:
...
> I actually like what you proposed above a lot, so if you don't
> mind either way I'll go with that proposal. Keeping the connector
> nodes as children of the outputs has the advanta
On 6/27/2012 2:43 AM, Sascha Hauer wrote:
Hi All,
I'd like to have a possibility to describe fixed display modes in the
devicetree. This topic has been discussed before here:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-February/080683.html
The result at that time was that EDID data sh
77 matches
Mail list logo
