On Wed, Apr 17, 2013 at 6:43 AM, Arnd Bergmann wrote:
>> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c:#ifdef __linux__
>> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h:#ifdef __linux__
>> drivers/scsi/dpt/osd_defs.h:#if (defined(__linux__))
>> drivers/staging/ced1401/machine.h:#if (defined(__linux__)
oh, cool :-)
On Mon, Feb 11, 2013 at 9:33 PM, Thomas Gall wrote:
> It's already a session at Linaro Connect in March. ;-)
>
> Regards
> Tom
>
> On Feb 11, 2013, at 8:16 PM, Rob Clark wrote:
>
>> http://www.phoronix.com/scan.php?page=news_item&px=MTI5OTM
>
http://www.phoronix.com/scan.php?page=news_item&px=MTI5OTM
just sayin.. linaro has the right people w/ toolchain and neon
expertise. We may be getting closer to the point of viable opensrc 3d
drivers, but having a decent fallback when no opensrc 3d driver and no
blob driver is available still se
On Mon, Jan 21, 2013 at 12:11 PM, John Stultz wrote:
> On 01/20/2013 06:57 AM, Rob Clark wrote:
>>
>> Btw, not sure if any of you have seen the 0-day kbuild setup that intel
>> has..
>>
>> https://lists.01.org/mailman/listinfo/kbuild
>>
>> runs vario
Btw, not sure if any of you have seen the 0-day kbuild setup that intel has..
https://lists.01.org/mailman/listinfo/kbuild
runs various builds for different archs on every commit with different
configs, randconfig, etc. And various checks with sparse, smatch,
etc. Seems kinda useful, and would
On Sat, Mar 31, 2012 at 6:58 PM, Linus Torvalds
wrote:
> - drm dma-buf prime support. Dave Airlie sent me the pull request but
> didn't push very hard for it, it's in my "ok, I can still pull it for
> 3.4 if individual DRM driver people tell me that it will make their
> lives easier." So this is
On Mon, Sep 19, 2011 at 10:39 AM, Will Deacon wrote:
> Arnd,
>
> On Mon, Sep 19, 2011 at 08:15:45AM +0100, Arnd Bergmann wrote:
>> Assuming that we can prevent any funny stuff from going into such an ABI,
>> we only need to worry about the warts of the current ABI for ARM specific
>> consideration
On Mon, Sep 19, 2011 at 2:15 AM, Arnd Bergmann wrote:
> On Sunday 18 September 2011 15:24:37 Rob Clark wrote:
>> I don't suppose there are any guidelines from ARM about compatibility
>> between 32bit userspace and 64bit kernel on some hypothetical future
>> version of t
On Sun, Sep 18, 2011 at 5:23 PM, Alan Cox wrote:
>> This would leave us with the issue of controlling formats and other
>> parameters
>> on the pipelines. We could keep separate DRM, KMS, FB and V4L APIs for that,
>
> There are some other differences that matter. The exact state and
> behaviour o
R,
-R
-- Forwarded message --
From: Rob Clark
Date: Sun, Sep 18, 2011 at 3:15 PM
Subject: Re: [PATCH] RFCv2: omapdrm DRM/KMS driver for TI OMAP platforms
To: Thomas Hellstrom
Cc: Inki Dae , dri-de...@lists.freedesktop.org,
patc...@linaro.org
On Sun, Sep 18, 2011 at 3:00 PM, Thomas Hell
On Sat, Sep 17, 2011 at 6:12 PM, Laurent Pinchart
wrote:
> Hi everybody,
>
> On Thursday 15 September 2011 20:39:21 Florian Tobias Schandinat wrote:
>> On 09/15/2011 05:52 PM, Alex Deucher wrote:
>> >
>> > Please don't claim that the DRM developers do not want to cooperate.
>> > I realize that peo
On Sat, Sep 17, 2011 at 11:11 AM, Florian Tobias Schandinat
wrote:
> On 09/17/2011 03:16 PM, Rob Clark wrote:
>>>From userspace perspective, fbdev doesn't go away. It is just a
>> legacy interface provided on top of DRM/KMS driver mostly via helper
>> functions. Wi
On Sat, Sep 17, 2011 at 9:44 AM, Felipe Contreras
wrote:
> On Thu, Sep 15, 2011 at 9:58 PM, Alan Cox wrote:
>>> One of my biggest problems with KMS is that it has (naturally) a lot more
>>> complexity than the fb API which leads to instability. Basically it's very
>>
>> It shouldn't do - and a sa
On Thu, Sep 15, 2011 at 12:21 PM, Tomi Valkeinen wrote:
> On Thu, 2011-09-15 at 10:50 -0500, Keith Packard wrote:
>> On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
>> wrote:
>>
>> > 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
>> > the plan is to make DRM the core Li
On Wed, Sep 14, 2011 at 12:44 AM, Inki Dae wrote:
> Hello Rob.
> Sorry for being late. here was a national holiday.
>
>
>> -Original Message-
>> From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob
>> Clark
>> Sent: Thursday, Septem
On Mon, Sep 12, 2011 at 2:21 PM, Rob Clark wrote:
> From: Rob Clark
>
> This factors out common code from psb_gtt_attach_pages()/
> i915_gem_object_get_pages_gtt() and psb_gtt_detach_pages()/
> i915_gem_object_put_pages_gtt().
>
> Signed-off-by: Rob Clark
> ---
>
On Mon, Sep 12, 2011 at 3:31 PM, Alan Cox wrote:
> On Mon, 12 Sep 2011 14:21:26 -0500
> Rob Clark wrote:
>
>> From: Rob Clark
>>
>> Signed-off-by: Rob Clark
>
> Generally looks sensible but:
>
> 1. This is a staging driver, so good practise is to cc the
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_gem.c | 51 +++---
1 files changed, 10 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ee59f31..6b49b4e 100644
--- a
From: Rob Clark
In the process of adding GEM support for omapdrm driver, I noticed that
I was adding code for creating/freeing mmap offsets which was virtually
identical to what was already duplicated in i915 and gma500 drivers.
And the code for attach/detatch_pages was quite similar as well
From: Rob Clark
This factors out common code from psb_gtt_attach_pages()/
i915_gem_object_get_pages_gtt() and psb_gtt_detach_pages()/
i915_gem_object_put_pages_gtt().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 68 +
include/drm
From: Rob Clark
Signed-off-by: Rob Clark
Signed-off-by: Alan Cox
---
drivers/staging/gma500/gem.c |2 +-
drivers/staging/gma500/gem_glue.c | 61 +
drivers/staging/gma500/gem_glue.h |1 -
3 files changed, 2 insertions(+), 62 deletions(-)
diff
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_gem.c | 85 +--
1 files changed, 2 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a546a71..ee59f31 100644
--- a
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 88 +
include/drm/drmP.h|3 ++
2 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 186d62e
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/staging/gma500/gtt.c | 47 ++---
1 files changed, 12 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/gma500/gtt.c b/drivers/staging/gma500/gtt.c
index 461ead2..f453321 100644
--- a/drivers
On Fri, Sep 2, 2011 at 1:27 PM, Christian Robottom Reis wrote:
> On Tue, Aug 30, 2011 at 11:24:59AM -0500, Zach Pfeffer wrote:
>> I'd like you to meet Jim who did the initial hardfloat work. This
>> email contains the results that Jim produced.
>
> Hmm, but the email seems to not actually contain
On Wed, Sep 7, 2011 at 1:00 AM, Inki Dae wrote:
> Hello, Rob.
>
[snip]
>> >> +static void page_flip_cb(void *arg)
>> >> +{
>> >> + struct drm_crtc *crtc = arg;
>> >> + struct drm_device *dev = crtc->dev;
>> >> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>> >> + struct drm_p
DBG("fbdev: set gamma");
>> +}
>> +
>> +static void omap_crtc_fb_gamma_get(struct drm_crtc *crtc,
>> + u16 *red, u16 *green, u16 *blue, int regno)
>> +{
>> + DBG("fbdev: get gamma");
>> +}
>> +
>> +static i
On Sun, Sep 4, 2011 at 2:49 PM, Daniel Vetter wrote:
> On Sun, Sep 04, 2011 at 11:29:43AM -0500, Rob Clark wrote:
>> > Above set of get/put functions seem to do very little. Drop them for the
>> > first round?
>>
>> The intention is to do attach/detach_pages here.
plugin layer ;-)
>
> Cheers, Daniel
>
> On Fri, Sep 02, 2011 at 03:07:27PM -0500, Rob Clark wrote:
>
>> [snip]
>
>> +int omap_connector_sync(struct drm_connector *connector)
>> +{
>> + struct omap_connector *omap_connector = to_omap_connector(connec
On Sat, Sep 3, 2011 at 1:57 AM, Dave Airlie wrote:
>>
>> A simple "plugin" mechanism is provided to allow integration with
>> external kernel modules (*cough* PVR), but also to keep the code more
>> modular as support is added for various other accelerator blocks that
>> exist in various different
2011/9/2 Christian König :
> Hi Rob,
>
>> + flipping between multiple back buffers, perhaps not in order (to
>> handle video formats with B-frames)
> Oh, yes please. The closed source drivers seems to do this also all the
> time, and I never really understood why DRI is limiting the buffers to
On Thu, Sep 1, 2011 at 5:22 PM, Younes Manton wrote:
> On Thu, Sep 1, 2011 at 4:52 PM, Rob Clark wrote:
>> To allow the potential use of overlays to display video content, a few
>> extra parameters are required:
>>
>> + source buffer in different format (for e
To allow the potential use of overlays to display video content, a few
extra parameters are required:
+ source buffer in different format (for example, various YUV formats)
and size as compared to destination drawable
+ multi-planar formats where discontiguous buffers are used for
differen
On Fri, Aug 19, 2011 at 5:18 AM, Pauli Nieminen
wrote:
> On Thu, Aug 18, 2011 at 09:58:07PM -0500, Rob Clark wrote:
>> From: Rob Clark
>>
>> To allow the potential use of overlays to display video content, a few
>> extra parameters are required:
>>
>> +
fwd'ing because my original reply from other account didn't seem to be
allowed by linaro-dev
-- Forwarded message ------
From: Rob Clark
Date: Fri, Aug 19, 2011 at 8:43 AM
Subject: Re: [PATCH dri2proto] RFC: video support for dri2
To: Pauli Nieminen
C
From: Rob Clark
To allow the potential use of overlays to display video content, a few
extra parameters are required:
+ source buffer in different format (for example, various YUV formats)
and size as compared to destination drawable
+ multi-planar formats where discontiguous buffers are
better support for cross development in linuxtools plugin would be nice, IMHO.
The oprofile/systemtap/etc support looks interesting, but when I looked at it
last those features were assuming that eclipse was running on the same machine
that oprofile/systemtap/etc was running on.
a simulated loc
37 matches
Mail list logo
