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
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)
>
- 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
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=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
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 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 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 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 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
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 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 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 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 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
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
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ä
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
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
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 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")
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 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 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
>>
>> 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/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
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
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 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 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
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
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
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
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
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
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
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.dem...@gmail.co
[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
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 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 */
>> + {
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
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,
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)
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
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
-
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
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
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
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
From: Ville Syrj?l?
The code happened to compile because the flag wasn't actually used yet.
Signed-off-by: Ville Syrj?l?
---
include/drm/drm_mode.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 95d7aad..966fe7d 1
From: Ville Syrj?l?
Unlock the mode_config mutex if drm_plane_init() fails.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2556589..7cb02f6 100644
From: Ville Syrj?l?
Several pointers and casts were missing __user annotations.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 30 +++---
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_c
From: Ville Syrj?l?
These are the only indication to user space that the plane was disabled.
Signed-off-by: Ville Syrj?l?
Acked-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/dr
From: Ville Syrj?l?
Make sure the source coordinates stay within the buffer.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index
I rebased this set on top of drm-next.
I updated some of the error values based on what Jesse suggested.
I also added a few patches to fix various issues that came up
since I last posted the patches.
Since the patch to drop the planar formats with YVU plane order wasn't
applied to drm-next, I
From: Ville Syrj?l?
Userspace needs this header.
Signed-off-by: Ville Syrj?l?
---
include/drm/Kbuild |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/drm/Kbuild b/include/drm/Kbuild
index 3a60ac8..a5c0e10 100644
--- a/include/drm/Kbuild
+++ b/include/drm/Kbuild
From: Ville Syrj?l?
drm_fourcc.h can be included from user space so use the appropriate types.
Signed-off-by: Ville Syrj?l?
---
include/drm/drm_fourcc.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index bb75249
From: Ville Syrj?l?
Help drivers a little by guaranteeing that crtc_x+crtc_w and
crtc_y+crtc_h don't overflow.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/g
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |2 +-
include/drm/drm_crtc.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b98e491..80cfe1c 100644
--- a/drivers/gpu
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 80cfe1c..66a165d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/driver
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 75
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 66a165d..07d78e2 100644
--- a/driver
From: Ville Syrj?l?
Otherwise each driver would need to keep the information inside
their own framebuffer object structure. Also add offsets[]. BOs
on the other hand are driver specific, so those can be kept in
driver specific structures.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_cr
Here are the utility functions again. Rebased and updated slightly.
I adapted drm_framebuffer_check() to handle multiple handles, and I changed
some of the error values it returns.
The plane options ioctl is a bit of an open question. I started by adding
separate ioctls for some subsets of the fu
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
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?
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 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?
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?
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?
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 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
[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, "vma use count: %d, high_memory = %p, 0x%08llx\n",
+ seq_printf(m, "vma us
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>
https://bugs.freedesktop.org/show_bug.cgi?id=43771
Stephane Marchesin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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=43964
Laurent carlier changed:
What|Removed |Added
Summary|A script fail to build in |Rendering is distorded in
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)
>
- 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.
>
>
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=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
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 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 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 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 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
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 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 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 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 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
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
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?
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
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
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 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")
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 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 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
1 - 100 of 116 matches
Mail list logo
