https://bugs.freedesktop.org/show_bug.cgi?id=38173
--- Comment #3 from Andre Maasikas 2011-12-20 23:49:55
PST ---
Created attachment 54625
--> https://bugs.freedesktop.org/attachment.cgi?id=54625
proposed
Here's a thing to try ( we should set non_disp_tiling in CB for > 128bpp
formats)
Makes
https://bugs.freedesktop.org/show_bug.cgi?id=43954
Alexandre Demers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=38173
Alexandre Demers changed:
What|Removed |Added
CC||alexandre.f.demers at gmail.co
On 2011.12.21 at 00:54 +0100, Rafael J. Wysocki wrote:
> Subject: WARNING: at fs/sysfs/sysfs.h:195 (during boot)
> Submitter : Markus Trippelsdorf
>
> Date : 2011-11-13 19:24
> Message-ID : 2013192417.ga1659-tlcgzgx+ij+kxvt8iv0...@public.gmane.org
> References : http://marc.info/?l
Hi, Dave.
Please pull from
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-next
this branch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git
branch name: drm-next
commit-id: d0d110e096298d2715aa26b3698e604e0d4a2fb9
th
Am 20.12.2011 21:20, schrieb Adam Jackson:
> On 12/20/11 1:38 PM, Harald Judt wrote:
>> Hi,
>>
>> When using more than one monitor, the card uses higher clocks than in
>> single-monitor mode and low-power profile. As a subjectively negative
>> side-effect, the fan on the card starts making more noi
On Tue, Dec 20, 2011 at 7:55 PM, Rob Clark wrote:
> On Mon, Dec 19, 2011 at 4:33 PM, ? wrote:
>> From: Ville Syrj?l?
>>
>> This function returns the number of planes used by a specific pixel
>> format.
>
> btw, I end up with a very similar util fxn in omapdrm driver.. would
> be nice to have this
On Mon, Dec 19, 2011 at 02:03:28PM +0530, Sumit Semwal wrote:
> Hello Everyone,
>
> This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the
> changelog below.
>
> Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the
> need to have a common mechanism to
From: Ville Syrj?l?
Using sizeof() on a function parameter with an array type does not
work. sizeof() treats such parameters as pointers.
Signed-off-by: Ville Syrj?l?
---
xf86drmMode.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xf86drmMode.c b/xf86drmMode.c
i
From: Ville Syrj?l?
This function was missing.
Signed-off-by: Ville Syrj?l?
---
xf86drmMode.c |9 +
xf86drmMode.h |1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index e67ed4a..473e734 100644
--- a/xf86drmMode.c
+++ b/xf86drmM
From: Ville Syrj?l?
drmModeFreeResources() always leaked some memory.
drmModeGetPlaneResources() and drmModeGetPlane() leaked in one error
path.
Signed-off-by: Ville Syrj?l?
---
xf86drmMode.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/xf86drmMode.c b/xf86drmM
>>
>> This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the
>> changelog below.
>>
>> Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the
>> need to have a common mechanism to share memory buffers across different
>> devices - ARM, video hardware, GPU.
Hi,
When using more than one monitor, the card uses higher clocks than in
single-monitor mode and low-power profile. As a subjectively negative
side-effect, the fan on the card starts making more noise. Other cards I
used before had no problem with staying quiet even when more monitors
were at
On Tue, Dec 20, 2011 at 05:32:13PM +0100, Daniel Vetter wrote:
> On Tue, Dec 20, 2011 at 12:09:39AM +, Ben Hutchings wrote:
> > [Re-sent to the right address, I hope.]
> >
> > Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not
> > leak kernel addresses via /proc/dri/*/vma")
https://bugs.freedesktop.org/show_bug.cgi?id=43964
--- Comment #3 from Ian Romanick 2011-12-20 10:40:59
PST ---
(In reply to comment #0)
> CG: 'PostEffect_Motion_fp.cg' using profile: 'arbfp1'
> CG ERROR : "The compile returned an error."
> ---
> core/programs/
On Tue, Dec 20, 2011 at 10:41:45AM -0600, Rob Clark wrote:
> On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann wrote:
> > On Monday 19 December 2011, Semwal, Sumit wrote:
> >> I didn't see a consensus on whether dma_buf should enforce some form
> >> of serialization within the API - so atleast for v1
On Tue, Dec 20, 2011 at 5:30 PM, Ville Syrj?l?
wrote:
> On Tue, Dec 20, 2011 at 04:58:51PM -0600, Rob Clark wrote:
>> +static const struct format formats[] = {
>> + ? ? /* 16bpp [A]RGB: */
>> + ? ? { OMAP_DSS_COLOR_RGB16, ? ? ? DRM_FORMAT_RGB565, ? {{2, 1}}, false },
>> /* RGB16-565 */
>> + ? ? {
Most architectures define virt_to_page() as a macro that casts its
argument such that an argument of type unsigned long will be accepted
without complaint. However, the proper type is void *, and passing
unsigned long results in a warning on MIPS.
Signed-off-by: Ben Hutchings
---
drivers/gpu/dr
By definition, the page offset will not affect the result.
Compile-tested only.
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/drm_vm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 8c03eaf..98c3922 100644
-
On Tue, Dec 20, 2011 at 12:09:39AM +, Ben Hutchings wrote:
> [Re-sent to the right address, I hope.]
>
> Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not
> leak kernel addresses via /proc/dri/*/vma") you changed the logging of
> high_memory:
>
> - seq_printf(m, "vm
This series fixes compiler warnings on some architectures about implicit
conversions and narrowing conversions between pointer and integer types.
Please apply these to the appropriate trees.
Ben.
Ben Hutchings (8):
IB/cxgb4: Fix formatting of physical address
farsync: Fix confusion about DMA
https://bugs.freedesktop.org/show_bug.cgi?id=43993
Bug #: 43993
Summary: 3d game in vmware workstation cause X hang up (ati
Gallium r600)
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
From: Rob Clark
Add support in framebuffer objects for other color formats and multi-
planar YUV (NV12). Since this requires changing the API between the
plane and fb for getting scanout information (paddr, etc), take
advantage of the opportunity and put in place a way to allow fb's to
be unpinn
From: Rob Clark
Because framebuffer layer and overlay scanout video pipes are basically
thing in OMAP display subsystem (the only difference being that the first
video pipe does not support scaling or YUV formats), much of the CRTC
code is pulled into the plane implementation, and a private plane
From: Rob Clark
Update to reflect changes in:
"drm: add an fb creation ioctl that takes a pixel format v5"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.h | 30 +-
drivers/staging/omapdrm/omap_fb.c| 103 ++
drivers/staging/omapdr
From: Rob Clark
The first patch updates omapdrm for API changes introduced when addfb2
support (for multi-planar fb's) was added (in drm-next). The next patch
adds drm plane (overlay) support, with CRTCs using private plane objects
to avoid code duplication between the CRTC and plane. (This dep
From: Rob Clark
Uncached/writecombine buffers need to be clean before creating uc/wc
userspace mappings, lest dirty cache lines fall down and corrupt the
contents of the buffer.
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_gem.c | 30 ++
1 files chang
On Tue, Dec 20, 2011 at 4:19 PM, Harald Judt wrote:
> Am 20.12.2011 21:20, schrieb Adam Jackson:
>>
>> On 12/20/11 1:38 PM, Harald Judt wrote:
>>>
>>> Hi,
>>>
>>> When using more than one monitor, the card uses higher clocks than in
>>> single-monitor mode and low-power profile. As a subjectively
On Tue, Dec 20, 2011 at 05:58:41PM -0600, Rob Clark wrote:
> On Tue, Dec 20, 2011 at 5:30 PM, Ville Syrjälä
> wrote:
> > On Tue, Dec 20, 2011 at 04:58:51PM -0600, Rob Clark wrote:
> >> +static const struct format formats[] = {
> >> + /* 16bpp [A]RGB: */
> >> + { OMAP_DSS_COLOR_RGB16,
On Tue, Dec 20, 2011 at 4:05 AM, Robert Morell wrote:
>
> One of the goals of this project is to unify the fragmented space of the
> ARM SoC memory managers so that each vendor doesn't implement their own,
> and they can all be closer to mainline.
That is a very good objective.
> I fear that res
On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie wrote:
>>>
>>> This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the
>>> changelog below.
>>>
>>> Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the
>>> need to have a common mechanism to share memory buff
Am 20.12.2011 22:50, schrieb Alex Deucher:
[...]
[drm:radeon_pm_print_states], 4 Power State(s)
[drm:radeon_pm_print_states], State 0: Default
[drm:radeon_pm_print_states], Default
[drm:radeon_pm_print_states], 16 PCIE Lanes
[drm:radeon_pm_print_states], 3 Clock Mode(s)
[drm:radeon_pm_pri
The previous commit didn't correctly fix the integer overflow issue.
http://git.kernel.org/linus/e133e737
- unsigned int required_size;
+ u64 required_size;
...
required_size = mode_cmd->pitch * mode_cmd->height;
- if (unlikely(required_size > dev_priv->vram_size
On Tue, Dec 20, 2011 at 5:30 PM, Ville Syrjälä
wrote:
> On Tue, Dec 20, 2011 at 04:58:51PM -0600, Rob Clark wrote:
>> +static const struct format formats[] = {
>> + /* 16bpp [A]RGB: */
>> + { OMAP_DSS_COLOR_RGB16, DRM_FORMAT_RGB565, {{2, 1}}, false },
>> /* RGB16-565 */
>> + {
On Monday 19 December 2011, Semwal, Sumit wrote:
> I didn't see a consensus on whether dma_buf should enforce some form
> of serialization within the API - so atleast for v1 of dma-buf, I
> propose to 'not' impose a restriction, and we can tackle it (add new
> ops or enforce as design?) whenever we
This message contains a list of some regressions from 3.0 and 3.1
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 3.0 and 3.1, please let us
know either and we'
On Tuesday 20 December 2011, Sakari Ailus wrote:
> (I'm jumping into the discussion in the middle, and might miss something
> that has already been talked about. I still hope what I'm about to say is
> relevant. :-))
It certainly is relevant.
> In subsystems such as V4L2 where drivers deal with s
[I'm sorry if you receive this message twice, I seem to have problems with
sending it.]
This message contains a list of some regressions from 3.0 and 3.1
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you kno
https://bugs.freedesktop.org/show_bug.cgi?id=38173
Alexandre Demers changed:
What|Removed |Added
CC||alexandre.f.dem...@gmail.co
https://bugs.freedesktop.org/show_bug.cgi?id=43954
Alexandre Demers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tue, Dec 20, 2011 at 04:58:51PM -0600, Rob Clark wrote:
> +static const struct format formats[] = {
> + /* 16bpp [A]RGB: */
> + { OMAP_DSS_COLOR_RGB16, DRM_FORMAT_RGB565, {{2, 1}}, false },
> /* RGB16-565 */
> + { OMAP_DSS_COLOR_RGB12U, DRM_FORMAT_RGBX, {{2, 1}}, fa
On 12/20/11 1:38 PM, Harald Judt wrote:
> Hi,
>
> When using more than one monitor, the card uses higher clocks than in
> single-monitor mode and low-power profile. As a subjectively negative
> side-effect, the fan on the card starts making more noise. Other cards I
> used before had no problem wit
On 12/7/11 6:26 PM, Adam Jackson wrote:
> There's no reason to force the first byte to be correct if we're already
> scoring how correct the header is.
Don't use this. The 00 check is needed to make sure we only attempt the
header fixup on the zeroth block (not extensions).
- ajax
From: Rob Clark
Add support in framebuffer objects for other color formats and multi-
planar YUV (NV12). Since this requires changing the API between the
plane and fb for getting scanout information (paddr, etc), take
advantage of the opportunity and put in place a way to allow fb's to
be unpinn
From: Rob Clark
Because framebuffer layer and overlay scanout video pipes are basically
thing in OMAP display subsystem (the only difference being that the first
video pipe does not support scaling or YUV formats), much of the CRTC
code is pulled into the plane implementation, and a private plane
From: Rob Clark
Update to reflect changes in:
"drm: add an fb creation ioctl that takes a pixel format v5"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.h | 30 +-
drivers/staging/omapdrm/omap_fb.c| 103 ++
drivers/staging/omapdr
From: Rob Clark
The first patch updates omapdrm for API changes introduced when addfb2
support (for multi-planar fb's) was added (in drm-next). The next patch
adds drm plane (overlay) support, with CRTCs using private plane objects
to avoid code duplication between the CRTC and plane. (This dep
From: Rob Clark
Uncached/writecombine buffers need to be clean before creating uc/wc
userspace mappings, lest dirty cache lines fall down and corrupt the
contents of the buffer.
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_gem.c | 30 ++
1 files chang
On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie wrote:
>>>
>>> This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the
>>> changelog below.
>>>
>>> Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the
>>> need to have a common mechanism to share memory buff
On Mon, Dec 19, 2011 at 4:33 PM, wrote:
> From: Ville Syrj?l?
>
> This function returns the number of planes used by a specific pixel
> format.
btw, I end up with a very similar util fxn in omapdrm driver.. would
be nice to have this in core to avoid duplicating in every driver
supporting multi
On Tue, Dec 20, 2011 at 4:19 PM, Harald Judt wrote:
> Am 20.12.2011 21:20, schrieb Adam Jackson:
>>
>> On 12/20/11 1:38 PM, Harald Judt wrote:
>>>
>>> Hi,
>>>
>>> When using more than one monitor, the card uses higher clocks than in
>>> single-monitor mode and low-power profile. As a subjectively
Am 20.12.2011 21:20, schrieb Adam Jackson:
On 12/20/11 1:38 PM, Harald Judt wrote:
Hi,
When using more than one monitor, the card uses higher clocks than in
single-monitor mode and low-power profile. As a subjectively negative
side-effect, the fan on the card starts making more noise. Other car
On Tue, Dec 20, 2011 at 7:55 PM, Rob Clark wrote:
> On Mon, Dec 19, 2011 at 4:33 PM, wrote:
>> From: Ville Syrjälä
>>
>> This function returns the number of planes used by a specific pixel
>> format.
>
> btw, I end up with a very similar util fxn in omapdrm driver.. would
> be nice to have this
On Mon, Dec 19, 2011 at 08:51:15PM +0100, Thomas Hellstrom wrote:
> On 12/13/2011 05:40 PM, Konrad Rzeszutek Wilk wrote:
> >On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote:
> >>On 12/13/2011 05:07 PM, Jerome Glisse wrote:
> >>>On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszu
On 12/20/11 1:38 PM, Harald Judt wrote:
Hi,
When using more than one monitor, the card uses higher clocks than in
single-monitor mode and low-power profile. As a subjectively negative
side-effect, the fan on the card starts making more noise. Other cards I
used before had no problem with staying
>>
>> This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the
>> changelog below.
>>
>> Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the
>> need to have a common mechanism to share memory buffers across different
>> devices - ARM, video hardware, GPU.
On 12/7/11 6:26 PM, Adam Jackson wrote:
There's no reason to force the first byte to be correct if we're already
scoring how correct the header is.
Don't use this. The 00 check is needed to make sure we only attempt the
header fixup on the zeroth block (not extensions).
- ajax
On Mon, Dec 19, 2011 at 4:33 PM, wrote:
> From: Ville Syrjälä
>
> This function returns the number of planes used by a specific pixel
> format.
btw, I end up with a very similar util fxn in omapdrm driver.. would
be nice to have this in core to avoid duplicating in every driver
supporting multi
https://bugs.freedesktop.org/show_bug.cgi?id=43954
--- Comment #1 from Michel D?nzer 2011-12-20 03:52:48
PST ---
Could be bug 38173. Does it work better with the environment variable
MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_compression_s3tc ?
--
Configure bugmail: https://bugs.freedesktop.org/u
From: Dave Airlie
If the bpc is set from the connector is 0, we then use it later to adjust
in a special case the HDMI pixel clock, however if the bpc is 0, we end up
passing a 0 pixel clock into the code.
I'm not sure if this is the correct answer or if we should avoid the HDMI
clock adjustment
On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
> This is the first step in defining a dma buffer sharing mechanism.
>
> A new buffer object dma_buf is added, with operations and API to allow easy
> sharing of this buffer object across devices.
>
> The framework allows:
> - differen
On Mon, Dec 19, 2011 at 02:03:28PM +0530, Sumit Semwal wrote:
> Hello Everyone,
>
> This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the
> changelog below.
>
> Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the
> need to have a common mechanism to
On Tue, Dec 20, 2011 at 10:36 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>>
>> A new buffer object dma_buf is added, with operations and API to allow easy
>> sharing of this
On Tue, Dec 20, 2011 at 05:32:13PM +0100, Daniel Vetter wrote:
> On Tue, Dec 20, 2011 at 12:09:39AM +, Ben Hutchings wrote:
> > [Re-sent to the right address, I hope.]
> >
> > Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not
> > leak kernel addresses via /proc/dri/*/vma")
Hi Arnd,
On Fri, Dec 09, 2011 at 02:13:03PM +, Arnd Bergmann wrote:
> On Thursday 08 December 2011, Daniel Vetter wrote:
> > > c) only allowing streaming mappings, even if those are non-coherent
> > > (requiring strict serialization between CPU (in-kernel) and dma users of
> > > the buffer)
>
On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann wrote:
> On Monday 19 December 2011, Semwal, Sumit wrote:
>> I didn't see a consensus on whether dma_buf should enforce some form
>> of serialization within the API - so atleast for v1 of dma-buf, I
>> propose to 'not' impose a restriction, and we can
https://bugs.freedesktop.org/show_bug.cgi?id=43964
--- Comment #3 from Ian Romanick 2011-12-20 10:40:59 PST
---
(In reply to comment #0)
> CG: 'PostEffect_Motion_fp.cg' using profile: 'arbfp1'
> CG ERROR : "The compile returned an error."
> ---
> core/programs/
Hi,
When using more than one monitor, the card uses higher clocks than in
single-monitor mode and low-power profile. As a subjectively negative
side-effect, the fan on the card starts making more noise. Other cards I
used before had no problem with staying quiet even when more monitors
were a
From: Ville Syrjälä
Using sizeof() on a function parameter with an array type does not
work. sizeof() treats such parameters as pointers.
Signed-off-by: Ville Syrjälä
---
xf86drmMode.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xf86drmMode.c b/xf86drmMode.c
i
From: Ville Syrjälä
This function was missing.
Signed-off-by: Ville Syrjälä
---
xf86drmMode.c |9 +
xf86drmMode.h |1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index e67ed4a..473e734 100644
--- a/xf86drmMode.c
+++ b/xf86drmM
From: Ville Syrjälä
drmModeFreeResources() always leaked some memory.
drmModeGetPlaneResources() and drmModeGetPlane() leaked in one error
path.
Signed-off-by: Ville Syrjälä
---
xf86drmMode.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/xf86drmMode.c b/xf86drmM
On Tue, Dec 20, 2011 at 8:32 AM, Daniel Vetter wrote:
> On Tue, Dec 20, 2011 at 12:09:39AM +, Ben Hutchings wrote:
>> [Re-sent to the right address, I hope.]
>>
>> Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not
>> leak kernel addresses via /proc/dri/*/vma") you changed
On Tue, Dec 20, 2011 at 6:47 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> If the bpc is set from the connector is 0, we then use it later to adjust
> in a special case the HDMI pixel clock, however if the bpc is 0, we end up
> passing a 0 pixel clock into the code.
>
> I'm not sure if this is t
On Mon, Dec 19, 2011 at 08:51:15PM +0100, Thomas Hellstrom wrote:
> On 12/13/2011 05:40 PM, Konrad Rzeszutek Wilk wrote:
> >On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote:
> >>On 12/13/2011 05:07 PM, Jerome Glisse wrote:
> >>>On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszu
On Tue, Dec 20, 2011 at 10:41:45AM -0600, Rob Clark wrote:
> On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann wrote:
> > On Monday 19 December 2011, Semwal, Sumit wrote:
> >> I didn't see a consensus on whether dma_buf should enforce some form
> >> of serialization within the API - so atleast for v1
On Tue, Dec 20, 2011 at 10:36 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>>
>> A new buffer object dma_buf is added, with operations and API to allow easy
>> sharing of this
On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann wrote:
> On Monday 19 December 2011, Semwal, Sumit wrote:
>> I didn't see a consensus on whether dma_buf should enforce some form
>> of serialization within the API - so atleast for v1 of dma-buf, I
>> propose to 'not' impose a restriction, and we can
On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote:
> This is the first step in defining a dma buffer sharing mechanism.
>
> A new buffer object dma_buf is added, with operations and API to allow easy
> sharing of this buffer object across devices.
>
> The framework allows:
> - differen
On Tue, Dec 20, 2011 at 12:09:39AM +, Ben Hutchings wrote:
> [Re-sent to the right address, I hope.]
>
> Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not
> leak kernel addresses via /proc/dri/*/vma") you changed the logging of
> high_memory:
>
> - seq_printf(m, "vm
https://bugs.freedesktop.org/show_bug.cgi?id=43964
Laurent carlier changed:
What|Removed |Added
Summary|A script fail to build in |Rendering is distorded in
On Monday 19 December 2011, Semwal, Sumit wrote:
> I didn't see a consensus on whether dma_buf should enforce some form
> of serialization within the API - so atleast for v1 of dma-buf, I
> propose to 'not' impose a restriction, and we can tackle it (add new
> ops or enforce as design?) whenever we
On Tuesday 20 December 2011, Sakari Ailus wrote:
> (I'm jumping into the discussion in the middle, and might miss something
> that has already been talked about. I still hope what I'm about to say is
> relevant. :-))
It certainly is relevant.
> In subsystems such as V4L2 where drivers deal with s
On Tue, Dec 20, 2011 at 6:47 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> If the bpc is set from the connector is 0, we then use it later to adjust
> in a special case the HDMI pixel clock, however if the bpc is 0, we end up
> passing a 0 pixel clock into the code.
>
> I'm not sure if this is t
On Tue, Dec 20, 2011 at 4:05 AM, Robert Morell wrote:
>
> One of the goals of this project is to unify the fragmented space of the
> ARM SoC memory managers so that each vendor doesn't implement their own,
> and they can all be closer to mainline.
That is a very good objective.
> I fear that res
- 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.
>
>
what you mean now. This is, as you say, only a
> problem "in theory". Is it worth fixing currently?
I don't know.
> If so, we probably need to add the "K" option to %x in some fashion.
Something like that, yes.
Ben.
--
Ben Hutchings
Humans are not rational being
https://bugs.freedesktop.org/show_bug.cgi?id=43954
--- Comment #1 from Michel Dänzer 2011-12-20 03:52:48 PST
---
Could be bug 38173. Does it work better with the environment variable
MESA_EXTENSION_OVERRIDE=-GL_EXT_texture_compression_s3tc ?
--
Configure bugmail: https://bugs.freedesktop.org/u
From: Dave Airlie
If the bpc is set from the connector is 0, we then use it later to adjust
in a special case the HDMI pixel clock, however if the bpc is 0, we end up
passing a 0 pixel clock into the code.
I'm not sure if this is the correct answer or if we should avoid the HDMI
clock adjustment
https://bugs.freedesktop.org/show_bug.cgi?id=43771
Stephane Marchesin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
g physical addresses,
because they are not pointers.
Ben.
--
Ben Hutchings
Humans are not rational beings; they are rationalising beings.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111220/9027c103/attachment.pgp>
- Original Message -
> From: "ville syrjala"
> To: dri-devel@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.
>
> I
Hi Arnd,
On Fri, Dec 09, 2011 at 02:13:03PM +, Arnd Bergmann wrote:
> On Thursday 08 December 2011, Daniel Vetter wrote:
> > > c) only allowing streaming mappings, even if those are non-coherent
> > > (requiring strict serialization between CPU (in-kernel) and dma users of
> > > the buffer)
>
From: Ville Syrj?l?
This function is is there to help driver writers.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 47 +
include/drm/drm_crtc_helper.h |3 ++
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/dr
From: Ville Syrj?l?
Add a new ioctl DRM_IOCTL_MODE_PLANE_OPTS which is used to configure
various settings for the plane.
I left out gamma correction thinking that it could be added using a
separate ioctl, since there's already a gamma ioctl for CRTCs.
Signed-off-by: Ville Syrj?l?
---
drivers/
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 102 +
include/drm/drm_crtc_helper.h |4 ++
2 files changed, 106 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm
From: Ville Syrj?l?
struct drm_region represents a two dimensional region. The utility
functions are there to help driver writers.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 156 +
include/drm/drm_crtc_helper.h | 24 ++
2
From: Ville Syrj?l?
This function performs a battery of sanity checks on the requested
framebuffer layout. Drivers can call it from their fb_create hook.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 85 +
include/drm/drm_crtc_helper
From: Ville Syrj?l?
These functions return the chroma subsampling factors for the specified
pixel format.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 60 +
include/drm/drm_crtc_helper.h |2 +
2 files changed, 62 insertions(
From: Ville Syrj?l?
This function returns the bytes per pixel value based on the pixel
format and plane index.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 45 +
include/drm/drm_crtc_helper.h |1 +
2 files changed, 46 insert
From: Ville Syrj?l?
This function returns the number of planes used by a specific pixel
format.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 33 +
include/drm/drm_crtc_helper.h |3 +++
2 files changed, 36 insertions(+), 0 deleti
1 - 100 of 116 matches
Mail list logo
