https://bugs.freedesktop.org/show_bug.cgi?id=43655
--- Comment #3 from Alexandre Demers 2011-12-12
01:03:23 PST ---
OK, so after testing first all RCs, I narrowed the problem between RC3 and RC4.
So, bisecting gave me the following culprit:
commit 9b5a4d4f65e260a109eaeea8bbc8062a7c58b55e
Merge:
https://bugs.freedesktop.org/show_bug.cgi?id=43739
Bug #: 43739
Summary: Startx fails for Fusion Wrestler 9809
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=43739
--- Comment #1 from samit vats 2011-12-12 01:17:20 PST ---
Created attachment 54351
--> https://bugs.freedesktop.org/attachment.cgi?id=54351
xorg.conf
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=43739
--- Comment #2 from samit vats 2011-12-12 01:17:49 PST ---
Created attachment 54352
--> https://bugs.freedesktop.org/attachment.cgi?id=54352
dmesg.txt
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=43739
--- Comment #3 from samit vats 2011-12-12 01:18:15 PST ---
Created attachment 54353
--> https://bugs.freedesktop.org/attachment.cgi?id=54353
lspci
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rece
https://bugs.freedesktop.org/show_bug.cgi?id=43739
samit vats changed:
What|Removed |Added
Priority|medium |high
--
Configure bugmail: https://bugs.fr
From: Alex Deucher
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=43739
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
include/drm/drm_pciids.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
ind
https://bugs.freedesktop.org/show_bug.cgi?id=43739
--- Comment #4 from Alex Deucher 2011-12-12 06:50:42 PST ---
You'll need the following patches:
Mesa:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=23895cc006f3dbf96a502ddd15e291e071aff25a
xf86-video-ati:
http://cgit.freedesktop.org/xorg/dri
On Fri, Dec 09, 2011 at 09:25:43PM -0500, Jerome Glisse wrote:
> Hi Konrad i stumble on this after a long period of test :
>
> Dec 9 12:00:37 homer kernel: [ cut here ]
> Dec 9 12:00:37 homer kernel: WARNING: at lib/dma-debug.c:894
> check_unmap+0x262/0x7e0()
> Dec 9 12:
On Mon, 12 Dec 2011 09:51:19 -0500, Alex Villacís Lasso
wrote:
> Ran kernel with reverted patch for 6 hours without issues so far. Will
> keep testing after work (issue happens with my home machine).
Thanks much. Let me know if it's still stable this evening; I can send a
revert along if you d
On Saturday 10 December 2011, Daniel Vetter wrote:
> If userspace (through some driver calls)
> tries to do stupid things, it'll just get garbage. See
> Message-ID:
>
> for my reasons why it think this is the right way to go forward. So in
> essence I'm really interested in the reasons why you wa
> > Any ideas ?
>
> The only way to do that would be to modify the 'struct dma_page' vaddr and dma
> variables from what they had in __ttm_dma_alloc_page. But I am not seeing any
> willfull modifications. We do pass in to dma_free_coherent the _same_ values!
>
>
> Hm, it might be worth adding in
Jerome pointed me to some accounting error in the DMA API debugging code and
while I can't figure it out yet, I did notice some extreme slowness - which
is due to the nouveau driver calling the unpopulate (now that unbind +
unpopulate are squashed) quite a lot (this is using Gnome Shell - I think G
Otherwise we are doing redundant work. Especially since the 'unbind'
and 'unpopulate' have been merged and nouveau driver ends up calling
it quite excessivly. On a GeForce 8600 GT with Gnome Shell (GNOME 3)
we end up spending about 54% CPU time in __change_page_attr_set_clr
checking the page flags
We would free the page pool - even if it was for cached pages
(which are deleted from the pool - so there are no free pages).
Also we also missed the opportunity to batch the amount of pages
to free (similar to how ttm_page_alloc.c does it). This reintroduces
the code that was lost during rebasing
The code to figure out how many pages to shrink the pool
ends up capping the 'count' at _manager->options.max_size - which is OK.
Except that the 'count' is also used when accounting for how many pages
are recycled - which we end up with the invalid values. This fixes
it by using a different value
Hey,
When I use the drm-next tree without the patch it works fine.
(albeit slowly - but I posted the patches for that).
With the patch mentioned I get this:
00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 6150SE
nForce 430] (rev a2)
sh-4.1# cd :00:0d.0
sh-4.1# cd driver
On Mon, Dec 12, 2011 at 12:37:43PM -0500, Konrad Rzeszutek Wilk wrote:
> > > Any ideas ?
> >
> > The only way to do that would be to modify the 'struct dma_page' vaddr and
> > dma
> > variables from what they had in __ttm_dma_alloc_page. But I am not seeing
> > any
> > willfull modifications. We
On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
> From: Joonyoung Shim
>
> The exynos fimd supports 5 window overlays. Only one window overlay of
> fimd is used by the crtc, so we need plane feature to use the rest
> window overlays.
>
> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_S
On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
> +static int
> +exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
> + struct drm_framebuffer *fb, int crtc_x, int crtc_y,
> + unsigned int crtc_w, unsigned int crtc_h,
> + ui
On Wed, Dec 07, 2011 at 04:28:45PM +, James Simmons wrote:
>
> > Chris Wilson rightly complained that this doesn't explain the list_del
> > magic going on. New commit msg reads:
> >
> > To make the transition in a piece-wise and bisectable way possible,
> > I've hijacked the ->owner_l
On Fri, Dec 9, 2011 at 18:44, Dave Airlie wrote:
> On Fri, Dec 9, 2011 at 5:40 PM, Rob Clark wrote:
>> On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter wrote:
+static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
+{
+ struct drm_device *dev = fb->dev;
+ stru
On 12/13/2011 07:48 AM, Rob Clark wrote:
On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
+static int
+exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+unsigned int crtc_w, unsigned i
On Sun, Dec 11, 2011 at 03:13:17PM -0600, Rob Clark wrote:
> From: Rob Clark
>
> The connector's dpms fxn is only triggered by userspace. When the
> driver is loaded and detected displays configured, drm core only
> calls the crtc and encoder's dpms functions.
>
> Signed-off-by: Rob Clark
> --
On 12/13/2011 06:59 AM, Rob Clark wrote:
On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
From: Joonyoung Shim
The exynos fimd supports 5 window overlays. Only one window overlay of
fimd is used by the crtc, so we need plane feature to use the rest
window overlays.
This creates one ioctl exyno
https://bugs.freedesktop.org/show_bug.cgi?id=43768
Bug #: 43768
Summary: [i915g]
src/gallium/drivers/i915/i915_fpc_translate.c:1101:i91
5_translate_token: Assertion `ifs->constant_flags[i]
== 0x0' failed.
Class
On Mon, Dec 12, 2011 at 6:41 PM, Joonyoung Shim wrote:
> On 12/13/2011 06:59 AM, Rob Clark wrote:
>>
>> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
>>>
>>> From: Joonyoung Shim
>>>
>>> The exynos fimd supports 5 window overlays. Only one window overlay of
>>> fimd is used by the crtc, so we n
https://bugs.freedesktop.org/show_bug.cgi?id=43769
Bug #: 43769
Summary: [i915g]
src/gallium/drivers/i915/i915_fpc_translate.c:658:i915
_translate_instruction: Assertion `0' failed.
Classification: Unclassified
Product:
From: Rob Clark
These two patches cover API changes that are currently in drm-next
for 3.3. The 2nd of which is the first part for enabling drm_plane
support (but doesn't yet enable the new overlay functionality). I'll
have another patchset, hopefully later this week, which adds the
remaining b
From: Rob Clark
Update to reflect changes in:
"Make the per-driver file_operations struct const"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
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 | 53 ++-
drivers/staging/omapdrm/omap_fb.c| 96 ++---
drivers/stagin
https://bugs.freedesktop.org/show_bug.cgi?id=38661
--- Comment #3 from Vinson Lee 2011-12-12 16:50:10 PST ---
mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master)
Assert still occurs.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this m
On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
> From: Rob Clark
>
> Update to reflect changes in:
> "Make the per-driver file_operations struct const"
This one I could take today, no need for me to rely on the drm api
changes, right?
greg k-h
___
On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
> From: Rob Clark
>
> Update to reflect changes in:
> "drm: add an fb creation ioctl that takes a pixel format v5"
This one I'm going to have to wait for the drm api merges to happen, so
I'll just wait for them to go into Linus's tree be
On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote:
> On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
>> From: Rob Clark
>>
>> Update to reflect changes in:
>> "Make the per-driver file_operations struct const"
>
> This one I could take today, no need for me to rely on the drm api
> change
On Mon, Dec 12, 2011 at 6:56 PM, Greg KH wrote:
> On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
>> From: Rob Clark
>>
>> Update to reflect changes in:
>> "drm: add an fb creation ioctl that takes a pixel format v5"
>
> This one I'm going to have to wait for the drm api merges to happ
On Mon, Dec 12, 2011 at 06:59:59PM -0600, Rob Clark wrote:
> On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote:
> > On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> Update to reflect changes in:
> >> "Make the per-driver file_operations struct const"
> >
> >
https://bugs.freedesktop.org/show_bug.cgi?id=43770
Bug #: 43770
Summary: [i915g]
src/gallium/drivers/i915/i915_fpc_emit.c:153:i915_emit
_arith: Assertion `(((dest)>>29)&0x7) != 2' failed.
Classification: Unclassified
Pr
On Mon, Dec 12, 2011 at 7:04 PM, Greg KH wrote:
> On Mon, Dec 12, 2011 at 06:59:59PM -0600, Rob Clark wrote:
>> On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote:
>> > On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
>> >> From: Rob Clark
>> >>
>> >> Update to reflect changes in:
>> >> "M
https://bugs.freedesktop.org/show_bug.cgi?id=43771
Bug #: 43771
Summary: [i915g]
src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821:
lp_build_sample_mipmap: Assertion `img_filter == 1'
failed.
Classification
Hi, Rob.
below is my answer.
> -Original Message-
> From: Rob Clark [mailto:robdcl...@gmail.com]
> Sent: Tuesday, December 13, 2011 9:48 AM
> To: Joonyoung Shim
> Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-
> de...@lists.freedesktop.org
> Subject: Re: [PATCH 5/5]
On Mon, Dec 12, 2011 at 8:39 PM, Inki Dae wrote:
> Hi, Rob.
> below is my answer.
>
>> -Original Message-
>> From: Rob Clark [mailto:robdcl...@gmail.com]
>> Sent: Tuesday, December 13, 2011 9:48 AM
>> To: Joonyoung Shim
>> Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dr
On Fri, Dec 09, 2011 at 03:53:49PM -0800, Keith Packard wrote:
> RC6 should always work on IVB, and should work on SNB whenever IO
> remapping is disabled. RC6 never works on Ironlake. Make the default
> value for the parameter follow these guidelines. Setting the value
> to either 0 or 1 will forc
El 11/12/11 16:29, Alex Villacís Lasso escribió:
El 11/12/11 15:46, Keith Packard escribió:
On Sun, 11 Dec 2011 13:36:30 -0500, Alex Villacís
Lasso wrote:
My system is a Fedora 16 x86_64 running self-compiled vanilla kernel
(.config attached for -rc5). I am getting an apparent memory corrupti
On Sat, Dec 10, 2011 at 03:13:06AM -0800, Mauro Carvalho Chehab wrote:
> On 09-12-2011 20:50, Robert Morell wrote:
> > On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote:
> >> On Friday 02 December 2011, Sumit Semwal wrote:
> >>> This is the first step in defining a dma buffer sharing me
https://bugs.freedesktop.org/show_bug.cgi?id=43655
--- Comment #3 from Alexandre Demers
2011-12-12 01:03:23 PST ---
OK, so after testing first all RCs, I narrowed the problem between RC3 and RC4.
So, bisecting gave me the following culprit:
commit 9b5a4d4f65e260a109eaeea8bbc8062a7c58b55e
Merge:
https://bugs.freedesktop.org/show_bug.cgi?id=43739
Bug #: 43739
Summary: Startx fails for Fusion Wrestler 9809
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=43739
--- Comment #1 from samit vats 2011-12-12 01:17:20 PST
---
Created attachment 54351
--> https://bugs.freedesktop.org/attachment.cgi?id=54351
xorg.conf
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=43739
--- Comment #2 from samit vats 2011-12-12 01:17:49 PST
---
Created attachment 54352
--> https://bugs.freedesktop.org/attachment.cgi?id=54352
dmesg.txt
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=43739
--- Comment #3 from samit vats 2011-12-12 01:18:15 PST
---
Created attachment 54353
--> https://bugs.freedesktop.org/attachment.cgi?id=54353
lspci
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=43739
samit vats changed:
What|Removed |Added
Priority|medium |high
--
Configure bugmail: https://bugs.fr
From: Alex Deucher
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=43739
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
include/drm/drm_pciids.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
https://bugs.freedesktop.org/show_bug.cgi?id=43739
--- Comment #4 from Alex Deucher 2011-12-12 06:50:42 PST
---
You'll need the following patches:
Mesa:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=23895cc006f3dbf96a502ddd15e291e071aff25a
xf86-video-ati:
http://cgit.freedesktop.org/xorg/dr
On Fri, Dec 09, 2011 at 09:25:43PM -0500, Jerome Glisse wrote:
> Hi Konrad i stumble on this after a long period of test :
>
> Dec 9 12:00:37 homer kernel: [ cut here ]
> Dec 9 12:00:37 homer kernel: WARNING: at lib/dma-debug.c:894
> check_unmap+0x262/0x7e0()
> Dec 9 12:
long if you don't find any problems.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/a
On Saturday 10 December 2011, Daniel Vetter wrote:
> If userspace (through some driver calls)
> tries to do stupid things, it'll just get garbage. See
> Message-ID: mail.gmail.com>
> for my reasons why it think this is the right way to go forward. So in
> essence I'm really interested in the reaso
> > Any ideas ?
>
> The only way to do that would be to modify the 'struct dma_page' vaddr and dma
> variables from what they had in __ttm_dma_alloc_page. But I am not seeing any
> willfull modifications. We do pass in to dma_free_coherent the _same_ values!
>
>
> Hm, it might be worth adding in
Jerome pointed me to some accounting error in the DMA API debugging code and
while I can't figure it out yet, I did notice some extreme slowness - which
is due to the nouveau driver calling the unpopulate (now that unbind +
unpopulate are squashed) quite a lot (this is using Gnome Shell - I think G
Otherwise we are doing redundant work. Especially since the 'unbind'
and 'unpopulate' have been merged and nouveau driver ends up calling
it quite excessivly. On a GeForce 8600 GT with Gnome Shell (GNOME 3)
we end up spending about 54% CPU time in __change_page_attr_set_clr
checking the page flags
We would free the page pool - even if it was for cached pages
(which are deleted from the pool - so there are no free pages).
Also we also missed the opportunity to batch the amount of pages
to free (similar to how ttm_page_alloc.c does it). This reintroduces
the code that was lost during rebasing
The code to figure out how many pages to shrink the pool
ends up capping the 'count' at _manager->options.max_size - which is OK.
Except that the 'count' is also used when accounting for how many pages
are recycled - which we end up with the invalid values. This fixes
it by using a different value
Hey,
When I use the drm-next tree without the patch it works fine.
(albeit slowly - but I posted the patches for that).
With the patch mentioned I get this:
00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 6150SE
nForce 430] (rev a2)
sh-4.1# cd :00:0d.0
sh-4.1# cd driver
On Mon, Dec 12, 2011 at 12:37:43PM -0500, Konrad Rzeszutek Wilk wrote:
> > > Any ideas ?
> >
> > The only way to do that would be to modify the 'struct dma_page' vaddr and
> > dma
> > variables from what they had in __ttm_dma_alloc_page. But I am not seeing
> > any
> > willfull modifications. We
On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
> From: Joonyoung Shim
>
> The exynos fimd supports 5 window overlays. Only one window overlay of
> fimd is used by the crtc, so we need plane feature to use the rest
> window overlays.
>
> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_S
On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
> +static int
> +exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
> + ? ? ? ? ? ? ? ? ? ?struct drm_framebuffer *fb, int crtc_x, int crtc_y,
> + ? ? ? ? ? ? ? ? ? ?unsigned int crtc_w, unsigned int crtc_h,
> + ? ? ? ? ? ? ? ? ? ?ui
On Wed, Dec 07, 2011 at 04:28:45PM +, James Simmons wrote:
>
> > Chris Wilson rightly complained that this doesn't explain the list_del
> > magic going on. New commit msg reads:
> >
> > To make the transition in a piece-wise and bisectable way possible,
> > I've hijacked the ->owner_l
On Sun, Dec 11, 2011 at 03:13:17PM -0600, Rob Clark wrote:
> From: Rob Clark
>
> The connector's dpms fxn is only triggered by userspace. When the
> driver is loaded and detected displays configured, drm core only
> calls the crtc and encoder's dpms functions.
>
> Signed-off-by: Rob Clark
> --
On Mon, Dec 12, 2011 at 6:41 PM, Joonyoung Shim
wrote:
> On 12/13/2011 06:59 AM, Rob Clark wrote:
>>
>> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae ?wrote:
>>>
>>> From: Joonyoung Shim
>>>
>>> The exynos fimd supports 5 window overlays. Only one window overlay of
>>> fimd is used by the crtc, so we
From: Rob Clark
These two patches cover API changes that are currently in drm-next
for 3.3. The 2nd of which is the first part for enabling drm_plane
support (but doesn't yet enable the new overlay functionality). I'll
have another patchset, hopefully later this week, which adds the
remaining b
From: Rob Clark
Update to reflect changes in:
"Make the per-driver file_operations struct const"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
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 | 53 ++-
drivers/staging/omapdrm/omap_fb.c| 96 ++---
drivers/stagin
On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
> From: Rob Clark
>
> Update to reflect changes in:
> "Make the per-driver file_operations struct const"
This one I could take today, no need for me to rely on the drm api
changes, right?
greg k-h
On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
> From: Rob Clark
>
> Update to reflect changes in:
> "drm: add an fb creation ioctl that takes a pixel format v5"
This one I'm going to have to wait for the drm api merges to happen, so
I'll just wait for them to go into Linus's tree be
On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote:
> On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
>> From: Rob Clark
>>
>> Update to reflect changes in:
>> "Make the per-driver file_operations struct const"
>
> This one I could take today, no need for me to rely on the drm api
> change
On Mon, Dec 12, 2011 at 6:56 PM, Greg KH wrote:
> On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote:
>> From: Rob Clark
>>
>> Update to reflect changes in:
>> "drm: add an fb creation ioctl that takes a pixel format v5"
>
> This one I'm going to have to wait for the drm api merges to happ
On Mon, Dec 12, 2011 at 06:59:59PM -0600, Rob Clark wrote:
> On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote:
> > On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> Update to reflect changes in:
> >> "Make the per-driver file_operations struct const"
> >
> >
On Mon, Dec 12, 2011 at 7:04 PM, Greg KH wrote:
> On Mon, Dec 12, 2011 at 06:59:59PM -0600, Rob Clark wrote:
>> On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote:
>> > On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote:
>> >> From: Rob Clark
>> >>
>> >> Update to reflect changes in:
>> >> "M
On Mon, Dec 12, 2011 at 8:39 PM, Inki Dae wrote:
> Hi, Rob.
> below is my answer.
>
>> -Original Message-
>> From: Rob Clark [mailto:robdclark at gmail.com]
>> Sent: Tuesday, December 13, 2011 9:48 AM
>> To: Joonyoung Shim
>> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsun
El 11/12/11 16:29, Alex Villac?s Lasso escribi?:
> El 11/12/11 15:46, Keith Packard escribi?:
>> On Sun, 11 Dec 2011 13:36:30 -0500, Alex Villac?s Lasso> palosanto.com> wrote:
>>> My system is a Fedora 16 x86_64 running self-compiled vanilla kernel
>>> (.config attached for -rc5). I am getting an
On Sat, Dec 10, 2011 at 03:13:06AM -0800, Mauro Carvalho Chehab wrote:
> On 09-12-2011 20:50, Robert Morell wrote:
> > On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote:
> >> On Friday 02 December 2011, Sumit Semwal wrote:
> >>> This is the first step in defining a dma buffer sharing me
80 matches
Mail list logo
