[Bug 46796] [X800SE] Mouse cursor corruption when switching users

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=46796

--- Comment #6 from Michel D?nzer  2012-03-06 09:30:19 
PST ---
Created attachment 58066
  --> https://bugs.freedesktop.org/attachment.cgi?id=58066
Verbose test patch

In order to facilitate testing, here's another version of the fix which prints
a message

[drm] Fixing large cursor offset 0x >= 0x0800

when the suspected problem would have occurred. So if such a message appears in
dmesg but the cursor is unharmed, we know this is indeed the proper fix.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
> On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen  
> wrote:

> > Can there be more than one omapdrm device? I guess not. If so, the id
> > should be -1.
> 
> in the past, we have used multiple devices (using the platform-data to
> divide up the dss resources), although this was sort of a
> special-case.  But in theory you could have multiple.  (Think of a
> multi-seat scenario, where multiple compositors need to run and each
> need to be drm-master of their own device to do mode-setting on their
> corresponding display.)
> 
> I think if we use .id = -1, then we'd end up with a funny looking
> bus-id for the device: "platform:omapdrm:-1"

I don't know about that, but it's the way platform devices are meant to
be used if there can be only one instance. If the case where there are
multiple omapdrm devices is rather theoretical, or only used for certain
debugging scenarios or such, I think having the id as -1 in the mainline
is cleaner.

> >> +};
> >> +
> >> +static int __init omap_init_gpu(void)
> >> +{
> >> + struct omap_hwmod *oh = NULL;
> >> + struct platform_device *pdev;
> >> +
> >> + /* lookup and populate the DMM information, if present - OMAP4+ */
> >> + oh = omap_hwmod_lookup("dmm");
> >> +
> >> + if (oh) {
> >> + pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
> >> + false);
> >> + WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
> >> + oh->name);
> >> + }
> >> +
> >> + return platform_device_register(_drm_device);
> >> +
> >> +}
> >
> > The function is called omap_init_gpu(), but it doesn't do anything
> > related to the gpu... And aren't DMM and DRM totally separate things,
> > why are they bunched together like that?
> 
> only legacy.. product branches also have sgx initialization here.  But
> I can change that to omap_init_drm()
> 
> DMM is managed by the drm driver (and exposed to userspace as drm/gem
> buffers, shared with other devices via dma-buf, etc).  It is only
> split out to a separate device to play along with hwmod.

I have to say I don't know much about DMM, but my understanding is that
DMM is a bigger entity, of which TILER is only a small part, and DMM
manages all memory accesses.

Can there be other users for the DMM than DRM? I know there could be
other users for the TILER, and I know you want to combine that with the
DRM driver, but I'm wondering about the other parts of DMM than the
TILER.

Somehow having a DMM driver inside omapdrm sounds strange.

> >> +arch_initcall(omap_init_gpu);
> >> +
> >> +void omapdrm_reserve_vram(void)
> >> +{
> >> +#ifdef CONFIG_CMA
> >> + /*
> >> +  * Create private 32MiB contiguous memory area for omapdrm.0 device
> >> +  * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
> >> +  * then the amount of memory we need goes up..
> >> +  */
> >> + dma_declare_contiguous(_drm_device.dev, 32 * SZ_1M, 0, 0);
> >
> > What does this actually do? Does it reserve the memory, i.e. it's not
> > usable for others? If so, shouldn't there be a way for the user to
> > configure it?
> 
> It can be re-used by others.. see http://lwn.net/Articles/479297/

The link didn't tell much. I looked at the patches, and
dma_declare_contiguous allocates the memory with memblock_alloc. So is
that allocated memory available for any users? If so, why does the
function want a device pointer as an argument...

Is the memory available for normal kmalloc, or only available via the
CMA functions? Surely there must be some downside to the above? =) And
if so, it should be configurable. You could have a board with no display
at all, and you probably don't want to have 32MB allocated for DRM in
that case.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120306/f1d494f2/attachment-0001.pgp>

Test application for DMABUF sharing between V4L2 and DRM

[Tomasz Stanislawski]

Hi Everyone,
This email contains a test application showing DMABUF sharing
between DRM/KMS display and camera capture node. It show simple
camera preview on LCD display. The similar application showing
DMABUF sharing between two V4L devices is available at link:

http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/43793/focus=43952

The program is written in C99 and it was tested using Exynos/DRM
and FIMC capture for M5MOLS and S5K6AAFX sensors on UniversalC210 board.

This application shows how buffer sharing between V4L2/DRM may look like.
Please let me know if/where I use DRM/V4L2 incorrectly.

The application was tested against 3.3-rc5 kernel with patches:
http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
[redesign of DMA mapping]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/43793/focus=43803
[support for dma_get_pages, PoC generic API for transforming DMA object 
into list of pages]
http://thread.gmane.org/gmane.comp.video.dri.devel/65583/focus=65703
[DRM prime support]
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm-dmabuf
[DRM prime support for Exynos DRM]
http://thread.gmane.org/gmane.comp.video.dri.devel/65992
[fix to DRM prime in Exynos DRM]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42966/focus=42968
[support for DMABUF importing in V4L2]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/45394
[integrate V4L2 with DMABUF]

Regards,
Tomasz Stanislawski

---
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 

#define ERRSTR strerror(errno)

#define BYE_ON(cond, ...) \
do { \
if (cond) { \
int errsv = errno; \
fprintf(stderr, "ERROR(%s:%d) : ", \
__FILE__, __LINE__); \
errno = errsv; \
fprintf(stderr,  __VA_ARGS__); \
abort(); \
} \
} while(0)

static inline int warn(const char *file, int line, const char *fmt, ...)
{
int errsv = errno;
va_list va;
va_start(va, fmt);
fprintf(stderr, "WARN(%s:%d): ", file, line);
vfprintf(stderr, fmt, va);
va_end(va);
errno = errsv;
return 1;
}

#define WARN_ON(cond, ...) \
((cond) ? warn(__FILE__, __LINE__, __VA_ARGS__) : 0)

struct setup {
char module[32];
uint32_t conId;
uint32_t crtId;
char modestr[32];
char video[32];
unsigned int w, h;
unsigned int use_wh : 1;
unsigned int in_fourcc;
unsigned int out_fourcc;
unsigned int buffer_count;
unsigned int use_crop : 1;
unsigned int use_compose : 1;
struct v4l2_rect crop;
struct v4l2_rect compose;
};

struct buffer {
unsigned int bo_handle;
unsigned int fb_handle;
int dbuf_fd;
};

struct stream {
int v4lfd;
int current_buffer;
int buffer_count;
struct buffer *buffer;
} stream;

static void usage(char *name)
{
fprintf(stderr, "usage: %s [-Moisth]\n", name);
fprintf(stderr, "\t-M \tset DRM module\n");
fprintf(stderr, "\t-o ::\tset a mode\n");
fprintf(stderr, "\t-i \tset video node like /dev/video*\n");
fprintf(stderr, "\t-S \tset input resolution\n");
fprintf(stderr, "\t-f \tset input format using 4cc\n");
fprintf(stderr, "\t-F \tset output format using 4cc\n");
fprintf(stderr, "\t-s @\tset crop area\n");
fprintf(stderr, "\t-t @\tset compose area\n");
fprintf(stderr, "\t-b buffer_count\tset number of buffers\n");
fprintf(stderr, "\t-h\tshow this help\n");
fprintf(stderr, "\n\tDefault is to dump all info.\n");
}

static inline int parse_rect(char *s, struct v4l2_rect *r)
{
return sscanf(s, "%d,%d@%d,%d", >width, >height,
>top, >left) != 4;
}

static int parse_args(int argc, char *argv[], struct setup *s)
{
if (argc <= 1)
usage(argv[0]);

int c, ret;
memset(s, 0, sizeof(*s));

while ((c = getopt(argc, argv, "M:o:i:S:f:F:s:t:b:h")) != -1) {
switch (c) {
case 'M':
strncpy(s->module, optarg, 31);
break;
case 'o':
ret = sscanf(optarg, "%u:%u:%31s", >conId, >crtId,
s->modestr);
if (WARN_ON(ret != 3, "incorrect mode description\n"))
return -1;
break;
case 'i':
strncpy(s->video, optarg, 31);
break;
case 'S':
ret 

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

--- Comment #5 from Tvrtko Ursulin  2012-03-06 
08:15:32 PST ---
(In reply to comment #1)
> Please attach your xorg log and dmesg output.  Unless the OEM forgot to wire 
> up
> the hotplug pin, the driver shouldn't be polling.  Check to make sure your
> desktop environment is not manually polling (gnome power manager or the kde
> equivalent, etc.).

Also, there are no stalls when the VGA output is used (HDMI disconnected).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

--- Comment #4 from Tvrtko Ursulin  2012-03-06 
08:13:20 PST ---

(In reply to comment #1)
> Please attach your xorg log and dmesg output.  Unless the OEM forgot to wire 
> up

Attached.

> the hotplug pin, the driver shouldn't be polling.  Check to make sure your
> desktop environment is not manually polling (gnome power manager or the kde
> equivalent, etc.).

There is no desktop environment running. What would this polling be in terms of
X calls?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

--- Comment #3 from Tvrtko Ursulin  2012-03-06 
08:12:04 PST ---
Created attachment 58064
  --> https://bugs.freedesktop.org/attachment.cgi?id=58064
Xorg.log, as the name says.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

--- Comment #2 from Tvrtko Ursulin  2012-03-06 
08:11:28 PST ---
Created attachment 58063
  --> https://bugs.freedesktop.org/attachment.cgi?id=58063
DRM related kernel messages

With my debug I have a problem with the kernel log buffer filling to quickly.
Is this DRM related subset of dmesg sufficient or you want me to collect
something more?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 2/3] dma-buf: add support for kernel cpu access

[Semwal, Sumit]

Hi Daniel,
On Tue, Mar 6, 2012 at 12:27 AM, Daniel Vetter  
wrote:
> On Fri, Mar 2, 2012 at 23:24, Rob Clark  wrote:
>> Perhaps we should check somewhere for required dmabuf ops fxns (like
>> kmap_atomic here), rather than just calling unconditionally what might
>> be a null ptr. ?At least put it in the WARN_ON(), but it might be
>> nicer to catch a missing required fxns at export time, rather than
>> waiting for an importer to try and call it. ?Less likely that way, for
>> newly added required functions go unnoticed.
>>
>> (same comment applies below for the non-atomic variant.. and possibly
>> some other existing dmabuf ops)
>
> Agreed, I'll rework the patch to do that when rebasing onto Sumit's latest 
> tree.
In addition, you'd not need to check for !dmabuf->ops since the export
should already catch it.

As I sent in the other mail a while back, could you please rebase on
for-next at git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git

Best regards,
~Sumit.
> -Daniel
> --

dma-buf feature tree: working model

[Sumit Semwal]

Hi all,

Since the inclusion of dma-buf buffer sharing framework in 3.3 (thanks
to Dave Airlie primarily), I have been volunteered to be its
maintainer.

Obviously there is a need for some simple rules about the dma-buf
feature tree, so here we are:

- there will be a 'for-next' branch for (N+1), which will open around
-Nrc1, and close about 1-2 weeks before the (N+1)merge opens.

- there will be a 'fixes' branch, which will take fixes after the
for-next pull request is sent upstream.
  - after -rc2, regression fixes only.
  - after -rc4/5, only revert and disable patches. The real fix should
then be targeted at for-next.

- to stop me from pushing useless stuff, I will merge my own patches
only after sufficient review on our mailing lists. If you see me
breaking this rule, please shout out at me _publicly_ at the top of
your voice.


Being a 'first-time-maintainer', I am very willing to learn
on-the-job, though I might still take cover under the
'first-time-maintainer' umbrella [for sometime :)] for any stupid acts
I might commit.


The tree resides at: git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git

At present, the mailing lists are: linux-media at vger.kernel.org,
dri-devel at lists.freedesktop.org, linaro-mm-sig at lists.linaro.org, in
addition to lkml.

Comments, flames and suggestions highly welcome.

(I have been 'influenced' quite a bit from Daniel Vetter's model for
the drm/i915 -next tree [thank you, DanVet!], but any errors/omissions
are entirely mine.)

Thanks and regards,
~Sumit.

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

--- Comment #1 from Alex Deucher  2012-03-06 07:56:58 PST 
---
Please attach your xorg log and dmesg output.  Unless the OEM forgot to wire up
the hotplug pin, the driver shouldn't be polling.  Check to make sure your
desktop environment is not manually polling (gnome power manager or the kde
equivalent, etc.).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 47007] New: HDMI monitor polling causing 100ms rendering stalls

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

 Bug #: 47007
   Summary: HDMI monitor polling causing 100ms rendering stalls
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: tvrtko.ursulin at onelan.co.uk


I am experiencing rendering stalls every ten seconds (drm_kms_helper output
connector poll interval) on a AMD G-T56N (Radeon HD 6310) box connected to the
monitor via HDMI connector.

Kernel is kernel.org's 3.3.0-rc6 kernel.

I've delved into the code a bit, sprayed some printks around, and found that
the culprit is the drm_get_edid call from radeon_dvi_detect where the former
takes more than 100ms. I suspect I2C transfers there are disabling interrupts
because I don't see any locks other than drm_device mode mutex being help at
that at least sounds harmless.

This function (radeon_dvi_detect) is a bit advanced for a newcomer in this
area, but, looking at the accompanying comment and the code, I am not sure it
could not be improved?

For example if monitor is connected, and we know it is a digital monitor, do we
need to discard and re-fetch complete EDID every time? Couldn't we just do a
quick probe to check for disconnection instead?

This is if I understand correctly that EDID probing must be done for
disconnection check?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[korg]help: How to submit a kernel driver on kernel.org.

[Paul Menzel]

Dear Aaron,


Am Dienstag, den 06.03.2012, 08:47 -0500 schrieb Alex Deucher:
> On Mon, Mar 5, 2012 at 11:13 PM, Aaron.Chen  ??? wrote:

> > Thank you very much for your guide. It's a great help for me.
> >
> > But I still have a little problem with the patch thing. I'm not familiar 
> > with the git.
> > 1.Shall I need to do the clone and get the source location and target 
> > directory first?
> > 2.Where is the source location and target directory?
> > 3.Our driver has pass the customer's test from kernel version 2.6.5 to 
> > 3.0.0, So what shall I do to submit a driver cover all these kernel version.

you can only get new features included upstream in the latest Linux
kernel. So earliest version would be 3.4. You have to maintain you own
repository for earlier version. But backporting should be not so much
trouble if you have it included upstream.

> > 4.or just email you the source code and tell you the changes?
> >
> > I'm looking forward your re-guide. Thank you so much.
> 
> Your best bet it to clone Linus' git tree and then apply your patches:
> 
> 1. clone Linus' git tree:
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

you can do this in between.

cd linux
git config --global user.name "??? (Aaron Chen)"
git config --global user.email aaron.chen at siliconmotion.com

> 2.a) apply your first patch
>b)  if you patch adds new files to the source tree, add them:
> git add path/to/files/file.c
> git add path/to/files/file.h
> etc.  if the patch only modifies patches that are already
> in the tree, you do not need to add them.
>c) when the patch is applied commit it:
>git commit -a -s
>d) when you run the commit command you will be prompted to
> enter a commit message.  The commit message has the following format:
> 
> subsystem: patch description
> 
> description of what the patch does.
> 
> Signed-off-by: Your name 
> 
> E.g.,
> 
> fb: add initial code for video 5000 graphics
> 
> This adds the initial support for the video 5000
> graphics adapter.  It supports vga and lcd connectors.
> 
> Signed-off-by: Joe Developer 
> 
> e) repeat steps a-d for all of your patches
> 3. generate patches:
> git format-patch -n
> 
> where n is the number of patches you committed.  E.g., if your driver
> consists of 5 patches:
> git format-patch -5
> 
> 4. Send the patches to the list.

Aaron, Git is nowadays documented pretty well. So just use

git help command

(like `git help commit`) to read the manual. Additionally you can just
search for it using your favorite search engine. Interesting reads
should be [1][2][3].


Thanks,

Paul


[1] http://schacon.github.com/git/user-manual.html#cleaning-up-history
[2] http://git-scm.com/documentation
[3] http://progit.org/book/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120306/763150c8/attachment.pgp>

drm: i915 hangcheck/GPU errors

[Eugeni Dodonov]

On Tue, Mar 6, 2012 at 10:47, Randy Dunlap  wrote:

> Hi,
>
> My Toshiba Portege (Intel Core i5) hangs every few days.
> Sometimes I can see no log messages/reasons for it.
> Sometimes there are messages about X receiving potentially
> fatal signals.
>
> Today's hang appears to have some useful info (maybe).
>
> Mar  6 09:01:45 dragon kernel: [137308.704424]
> [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
> Mar  6 09:01:45 dragon kernel: [137308.704552] [drm] capturing error
> event; look for more information in /debug/dri/0/i915_error_state
> Mar  6 09:01:45 dragon kernel: [137308.718950] [drm:i915_wait_request]
> *ERROR* i915_wait_request returns -11 (awaiting 16513584 at 16513581, next
> 16513585)
> Mar  6 09:02:13 dragon kernel: [137336.754647]
> [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
> Mar  6 09:02:13 dragon kernel: [137336.754698] [drm:i915_wait_request]
> *ERROR* i915_wait_request returns -11 (awaiting 16517081 at 16517078, next
> 16517082)
>

This error state file is in debugfs, usually in /sys/kernel/debug/dri/0/
directory.

Could you please report it into our bugzilla, attaching the files and
information mentioned at
http://intellinuxgraphics.org/how_to_report_bug.html please?

-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120306/a2e51e15/attachment.htm>

[PATCH] omap2+: add drm device

[Tomi Valkeinen]

 CMA pages
> +  * then the amount of memory we need goes up..
> +  */
> + dma_declare_contiguous(_drm_device.dev, 32 * SZ_1M, 0, 0);

What does this actually do? Does it reserve the memory, i.e. it's not
usable for others? If so, shouldn't there be a way for the user to
configure it?

> +#else
> +#  warning "CMA is not enabled, there may be limitations about scanout 
> buffer allocations on OMAP3 and earlier"
> +#endif
> +}
> +
> +#endif
> diff --git a/arch/arm/plat-omap/include/plat/drm.h 
> b/arch/arm/plat-omap/include/plat/drm.h
> new file mode 100644
> index 000..df9bc41
> --- /dev/null
> +++ b/arch/arm/plat-omap/include/plat/drm.h
> @@ -0,0 +1,64 @@
> +/*
> + * DRM/KMS device registration for TI OMAP platforms
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Author: Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __PLAT_OMAP_DRM_H__
> +#define __PLAT_OMAP_DRM_H__
> +
> +/*
> + * Optional platform data to configure the default configuration of which
> + * pipes/overlays/CRTCs are used.. if this is not provided, then instead the
> + * first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected to
> + * one manager, with priority given to managers that are connected to
> + * detected devices.  Remaining overlays are used as video planes.  This
> + * should be a good default behavior for most cases, but yet there still
> + * might be times when you wish to do something different.
> + */
> +struct omap_kms_platform_data {
> + /* overlays to use as CRTCs: */
> + int ovl_cnt;
> + const int *ovl_ids;
> +
> + /* overlays to use as video planes: */
> + int pln_cnt;
> + const int *pln_ids;
> +
> + int mgr_cnt;
> + const int *mgr_ids;
> +
> + int dev_cnt;
> + const char **dev_names;
> +};
> +
> +struct omap_drm_platform_data {
> + struct omap_kms_platform_data *kms_pdata;
> +};

I don't know if there's need to add these... With device tree the
plaform data will not be usable anyway.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120306/a01a5424/attachment.pgp>

[korg]help: How to submit a kernel driver on kernel.org.

[Aaron.Chen 陈俊杰]

Hi Paul,

Our driver is a frambuffer driver and there's no DRM functions.

Regards
Aaron

--
???: Aaron.Chen ??? 
: 2012?3?6? 12:14
???: 'Paul Menzel'; Jerome Glisse
??: dri-devel at lists.freedesktop.org; caesar.qiu ???
??: Re: [korg]help: How to submit a kernel driver on kernel.org.

Hi Paul,

Thank you very much for your guide. It's a great help for me.

But I still have a little problem with the patch thing. I'm not familiar with 
the git.
1.Shall I need to do the clone and get the source location and target directory 
first? 
2.Where is the source location and target directory?
3.Our driver has pass the customer's test from kernel version 2.6.5 to 3.0.0, 
So what shall I do to submit a driver cover all these kernel version.
4.or just email you the source code and tell you the changes?

I'm looking forward your re-guide. Thank you so much.

Regards
Aaron


--
???: Paul Menzel [mailto:paulepanter at users.sourceforge.net] 
: 2012?3?2? 5:50
???: Jerome Glisse
??: Aaron.Chen ???; dri-devel at lists.freedesktop.org
??: Re: [korg]help: How to submit a kernel driver on kernel.org.

Dear Aaron,


thank you for contacting the list. We are looking forward to your patches.

Am Donnerstag, den 01.03.2012, 14:05 -0500 schrieb Jerome Glisse:
> On Thu, 2012-03-01 at 14:28 +0800, Aaron.Chen ??? wrote:

> > I?m from Silicon Motion Technology Corporation (NasdaqGS:SIMO) Shanghai 
> > Office. We have developed a kernel driver for all our graphics chips. We 
> > really want to know the way to submit a kernel driver to kernel.org. I have 
> > received a document file which is on 
> > http://kernel.org/doc/Documentation/SubmittingDrivers, but I still cannot 
> > find out a place to where our drivers should be uploaded. The document say 
> > ?please submit it to the maintainer listed in MAINTAINERS in the kernel 
> > file.?So where can I find the maintainer and what to do next. Would you 
> > please help me. Thank you so much.

> All you need to do is send the kernel patch to 
> dri-devel at lists.freedesktop.org
> 
> So they can get reviewed. Once they are reviewed, and if they comply 
> with the requirement, the DRM maintainer (aka Dave) will integrate 
> your patch in his tree and at some point ask Linus to pull them.
> 
> There is no ftp, or http web submission, everything is done through 
> public mailing list.

if you are familiar with Git you should send a patch formatted using `git 
format-patch -15`. Replace the 15 by the number of commits you need patches for.

You can take a look in the archive. drm/exynos and drm/omap are good examples ? 
I think ? on how to get new drivers submitted.


Thanks,

Paul


PS: Please also try to follow the netiquette when posting to lists [1].
Especially just send plain text messages (no HTML).


[1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette

[PATCH] drm: exynos: fix gem-prime support

[Tomasz Stanislawski]

From: Tomasz Stanislawski 

Fix error handling of dma_buf_export in exynos-drm driver.

Signed-off-by: Tomasz Stanislawski 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index cbb6ad4..5f41de5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -200,7 +200,8 @@ int exynos_dmabuf_prime_handle_to_fd(struct drm_device 
*drm_dev,
 */
obj->export_dma_buf = dma_buf_export(obj, _dmabuf_ops,
obj->size, 0600);
-   if (!obj->export_dma_buf) {
+   if (IS_ERR(obj->export_dma_buf)) {
+   DRM_DEBUG_KMS("failed to export dmabuf.\n");
ret = PTR_ERR(obj->export_dma_buf);
goto err2;
}
-- 
1.7.5.4

[Bug 42876] New: System doesn't boot with GTX 550 Ti

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=42876

   Summary: System doesn't boot with GTX 550 Ti
   Product: Drivers
   Version: 2.5
Kernel Version: >3.2
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: blocking
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: artkun at guitarplayer.ru
Regression: Yes


My hardware is:
ASUS P5KPL-AM SE, C2D E8500, GeForce GTX 550 Ti.

The problem is that with kernel newer than 3.2 (including 3.3 in Fedora 17), my
system doesn't boot at all. I'm using nouveau and have no proprietary nvidia
modules installed.
With 3.2, I'm getting nothing but "Loading initial ramdisk" on the screen, but
HDD LED is blinking and when I press the Power button on my PC, the system
turns off as it's supposed to.
But with 3.3 (in Fedora 17 and Ubuntu 12.04 with Canonical patched kernel), the
system doesn't boot at all. After "Loading initial ramdisk" the monitor turns
off, and nothing happens. HDD doesn't do anything.
This happens even without xf86-video-nouveau installed (i've tried Arch).

With kernel 3.1.9, my graphics card still works perfect, with a good 3D
acceleration. GNOME 3 works perfect too.

I'm sorry for my English.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH] xf86-video-modesetting generic colormap handling

[James Simmons]

This patch replaces drmmode_load_palette with a very generic function
that removes the need of drmmode_crtc_private_rec to carry around 
color indexes. Also have the xorg driver actually call 
the xf86HandleColormaps function.

Signed-off-by: James Simmons 

diff --git a/src/driver.c b/src/driver.c
index 87431ff..a825f35 100644
--- a/src/driver.c
+++ b/src/driver.c
@@ -42,6 +42,7 @@
 #include "xf86Pci.h"
 #include "mipointer.h"
 #include "micmap.h"
+#include "xf86cmap.h"
 #include 
 #include "fb.h"
 #include "edid.h"
@@ -540,6 +541,62 @@ PreInit(ScrnInfoPtr pScrn, int flags)
 return FALSE;
 }

+static void
+LoadPalette(ScrnInfoPtr pScrn, int numColors, int *indices,
+LOCO * colors, VisualPtr pVisual)
+{
+xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
+CARD16 lut_r[256], lut_g[256], lut_b[256];
+int i, j, k, index;
+
+for (k = 0; k < xf86_config->num_crtc; k++) {
+xf86CrtcPtr crtc = xf86_config->crtc[k];
+
+switch (pScrn->depth) {
+case 15:
+for (i = 0; i < numColors; i++) {
+index = indices[i];
+for (j = 0; j < 8; j++) {
+lut_r[index * 8 + j] = colors[index].red << 8;
+lut_g[index * 8 + j] = colors[index].green << 8;
+lut_b[index * 8 + j] = colors[index].blue << 8;
+}
+}
+break;
+case 16:
+for (i = 0; i < numColors; i++) {
+index = indices[i];
+
+if (index <= 31) {
+for (j = 0; j < 8; j++) {
+lut_r[index * 8 + j] = colors[index].red << 8;
+lut_b[index * 8 + j] = colors[index].blue << 8;
+}
+}
+
+for (j = 0; j < 4; j++)
+lut_g[index * 4 + j] = colors[index].green << 8;
+}
+break;
+default:
+for (i = 0; i < numColors; i++) {
+index = indices[i];
+lut_r[index] = colors[index].red << 8;
+lut_g[index] = colors[index].green << 8;
+lut_b[index] = colors[index].blue << 8;
+}
+break;
+}
+
+/* Make the change through RandR */
+#ifdef RANDR_12_INTERFACE
+RRCrtcGammaSet(crtc->randr_crtc, lut_r, lut_g, lut_b);
+#else /*RANDR_12_INTERFACE*/
+crtc->funcs->gamma_set(crtc, lut_r, lut_g, lut_b, 256);
+#endif
+}
+}
+
 static void *
 msShadowWindow(ScreenPtr screen, CARD32 row, CARD32 offset, int mode,
   CARD32 *size, void *closure)
@@ -716,7 +773,12 @@ ScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, 
char **argv)
return FALSE;

 if (!miCreateDefColormap(pScreen))
-   return FALSE;
+return FALSE;
+
+if (!xf86HandleColormaps(pScreen, 256, 8, LoadPalette, NULL,
+ CMAP_RELOAD_ON_MODE_SWITCH
+ | CMAP_PALETTED_TRUECOLOR))
+return FALSE;

 xf86DPMSInit(pScreen, xf86DPMSSet, 0);

diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 7fa933a..d1da19a 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1134,89 +1132,6 @@ Bool drmmode_set_desired_modes(ScrnInfoPtr pScrn, 
drmmode_ptr drmmode)
return TRUE;
 }

-static void drmmode_load_palette(ScrnInfoPtr pScrn, int numColors,
- int *indices, LOCO *colors, VisualPtr pVisual)
-{
-xf86CrtcConfigPtr   xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
-uint16_t   lut_r[256], lut_g[256], lut_b[256];
-int index, j, i;
-int c;
-
-for (c = 0; c < xf86_config->num_crtc; c++) {
-xf86CrtcPtr crtc = xf86_config->crtc[c];
-   drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
-
-for (i = 0 ; i < 256; i++) {
-lut_r[i] = drmmode_crtc->lut_r[i] << 6;
-lut_g[i] = drmmode_crtc->lut_g[i] << 6;
-lut_b[i] = drmmode_crtc->lut_b[i] << 6;
-}
-
-switch(pScrn->depth) {
-case 15:
-for (i = 0; i < numColors; i++) {
-index = indices[i];
-for (j = 0; j < 8; j++) {
-lut_r[index * 8 + j] = colors[index].red << 6;
-lut_g[index * 8 + j] = colors[index].green << 6;
-lut_b[index * 8 + j] = colors[index].blue << 6;
-}
-}
- break;
- case 16:
- for (i = 0; i < numColors; i++) {
- index = indices[i];
-
-  if (i <= 31) {
-  for (j = 0; j < 8; j++) {
-  lut_r[index * 8 + j] = colors[index].red << 6;
-  lut_b[index * 8 + j] = colors[index].blue << 6;
-  }
-  }
-
-  for (j = 0; j < 4; j++) {
-  lut_g[index * 4 + j] = colors[index].green << 6;
-

[PATCH] xf86-video-modesetting cursor reload

[James Simmons]

Enable after a resolution change reload the cursor image.

Signed-off-by: James Simmons 

diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 7fa933a..8a49103 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -361,11 +361,9 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr 
mode,
}
}

-#if 0
-   if (pScrn->pScreen &&
-   !xf86ReturnOptValBool(info->Options, OPTION_SW_CURSOR, FALSE))
+   if (pScrn->pScreen && !drmmode->sw_cursor)
xf86_reload_cursors(pScrn->pScreen);
-#endif
+
 done:
if (!ret) {
crtc->x = saved_x;

[korg]help: How to submit a kernel driver on kernel.org.

[Aaron.Chen 陈俊杰]

Hi Paul,

Thank you very much for your guide. It's a great help for me.

But I still have a little problem with the patch thing. I'm not familiar with 
the git.
1.Shall I need to do the clone and get the source location and target directory 
first? 
2.Where is the source location and target directory?
3.Our driver has pass the customer's test from kernel version 2.6.5 to 3.0.0, 
So what shall I do to submit a driver cover all these kernel version.
4.or just email you the source code and tell you the changes?

I'm looking forward your re-guide. Thank you so much.

Regards
Aaron


--
???: Paul Menzel [mailto:paulepanter at users.sourceforge.net] 
: 2012?3?2? 5:50
???: Jerome Glisse
??: Aaron.Chen ???; dri-devel at lists.freedesktop.org
??: Re: [korg]help: How to submit a kernel driver on kernel.org.

Dear Aaron,


thank you for contacting the list. We are looking forward to your patches.

Am Donnerstag, den 01.03.2012, 14:05 -0500 schrieb Jerome Glisse:
> On Thu, 2012-03-01 at 14:28 +0800, Aaron.Chen ??? wrote:

> > I?m from Silicon Motion Technology Corporation (NasdaqGS:SIMO) Shanghai 
> > Office. We have developed a kernel driver for all our graphics chips. We 
> > really want to know the way to submit a kernel driver to kernel.org. I have 
> > received a document file which is on 
> > http://kernel.org/doc/Documentation/SubmittingDrivers, but I still cannot 
> > find out a place to where our drivers should be uploaded. The document say 
> > ?please submit it to the maintainer listed in MAINTAINERS in the kernel 
> > file.?So where can I find the maintainer and what to do next. Would you 
> > please help me. Thank you so much.

> All you need to do is send the kernel patch to 
> dri-devel at lists.freedesktop.org
> 
> So they can get reviewed. Once they are reviewed, and if they comply 
> with the requirement, the DRM maintainer (aka Dave) will integrate 
> your patch in his tree and at some point ask Linus to pull them.
> 
> There is no ftp, or http web submission, everything is done through 
> public mailing list.

if you are familiar with Git you should send a patch formatted using `git 
format-patch -15`. Replace the 15 by the number of commits you need patches for.

You can take a look in the archive. drm/exynos and drm/omap are good examples ? 
I think ? on how to get new drivers submitted.


Thanks,

Paul


PS: Please also try to follow the netiquette when posting to lists [1].
Especially just send plain text messages (no HTML).


[1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette

[PATCH] drm/radeon: deal with errors from framebuffer init path.

[Dave Airlie]

From: Dave Airlie 

We've been seeing a very occasional oops on a 32-bit rn50 platform running EL6
kernels at boot. It seems to be due to one of these functions failing and
us then accessing a NULL-300 pointer.

This should prevent the oops and give some info in the logs as to what is going 
on.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/radeon_display.c |   18 +++---
 drivers/gpu/drm/radeon/radeon_fb.c  |   11 ++-
 drivers/gpu/drm/radeon/radeon_mode.h|2 +-
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 8c49fef..3d31433 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1078,15 +1078,21 @@ static const struct drm_framebuffer_funcs 
radeon_fb_funcs = {
.create_handle = radeon_user_framebuffer_create_handle,
 };

-void
+int
 radeon_framebuffer_init(struct drm_device *dev,
struct radeon_framebuffer *rfb,
struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object *obj)
 {
+   int ret;
rfb->obj = obj;
-   drm_framebuffer_init(dev, >base, _fb_funcs);
+   ret = drm_framebuffer_init(dev, >base, _fb_funcs);
+   if (ret) {
+   rfb->obj = NULL;
+   return ret;
+   }
drm_helper_mode_fill_fb_struct(>base, mode_cmd);
+   return 0;
 }

 static struct drm_framebuffer *
@@ -1096,6 +1102,7 @@ radeon_user_framebuffer_create(struct drm_device *dev,
 {
struct drm_gem_object *obj;
struct radeon_framebuffer *radeon_fb;
+   int ret;

obj = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
if (obj ==  NULL) {
@@ -1108,7 +1115,12 @@ radeon_user_framebuffer_create(struct drm_device *dev,
if (radeon_fb == NULL)
return ERR_PTR(-ENOMEM);

-   radeon_framebuffer_init(dev, radeon_fb, mode_cmd, obj);
+   ret = radeon_framebuffer_init(dev, radeon_fb, mode_cmd, obj);
+   if (ret) {
+   kfree(radeon_fb);
+   drm_gem_object_unreference_unlocked(obj);
+   return NULL;
+   }

return _fb->base;
 }
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index cf2bf35..195471c 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -209,6 +209,11 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,
  sizes->surface_depth);

ret = radeonfb_create_pinned_object(rfbdev, _cmd, );
+   if (ret) {
+   DRM_ERROR("failed to create fbcon object %d\n", ret);
+   return ret;
+   }
+
rbo = gem_to_radeon_bo(gobj);

/* okay we have an object now allocate the framebuffer */
@@ -220,7 +225,11 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,

info->par = rfbdev;

-   radeon_framebuffer_init(rdev->ddev, >rfb, _cmd, gobj);
+   ret = radeon_framebuffer_init(rdev->ddev, >rfb, _cmd, 
gobj);
+   if (ret) {
+   DRM_ERROR("failed to initalise framebuffer %d\n", ret);
+   goto out_unref;
+   }

fb = >rfb.base;

diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index 4330e32..8a85598 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -649,7 +649,7 @@ extern void radeon_crtc_fb_gamma_set(struct drm_crtc *crtc, 
u16 red, u16 green,
 u16 blue, int regno);
 extern void radeon_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 
*green,
 u16 *blue, int regno);
-void radeon_framebuffer_init(struct drm_device *dev,
+int radeon_framebuffer_init(struct drm_device *dev,
 struct radeon_framebuffer *rfb,
 struct drm_mode_fb_cmd2 *mode_cmd,
 struct drm_gem_object *obj);
-- 
1.7.7.6

drm: i915 hangcheck/GPU errors

[Randy Dunlap]

Hi,

My Toshiba Portege (Intel Core i5) hangs every few days.
Sometimes I can see no log messages/reasons for it.
Sometimes there are messages about X receiving potentially
fatal signals.

Today's hang appears to have some useful info (maybe).

Mar  6 09:01:45 dragon kernel: [137308.704424] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:01:45 dragon kernel: [137308.704552] [drm] capturing error event; 
look for more information in /debug/dri/0/i915_error_state
Mar  6 09:01:45 dragon kernel: [137308.718950] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16513584 at 16513581, next 16513585)
Mar  6 09:02:13 dragon kernel: [137336.754647] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:02:13 dragon kernel: [137336.754698] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16517081 at 16517078, next 16517082)

...

Mar  6 09:05:44 dragon kernel: [137548.071904] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:05:44 dragon kernel: [137548.071951] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16550939 at 16550936, next 16550940)
Mar  6 09:05:57 dragon kernel: [137560.924459] X/1399: potentially unexpected 
fatal signal 6.
Mar  6 09:05:57 dragon kernel: [137560.924463] 
Mar  6 09:05:57 dragon kernel: [137560.924466] CPU 1 
Mar  6 09:05:57 dragon kernel: [137560.924468] Modules linked in: usblp 
snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq 
snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 af_packet acpi_cpufreq mperf lp 
ppdev parport_pc parport snd_hda_codec_hdmi snd_hda_codec_realtek uvcvideo 
videobuf2_core videobuf2_vmalloc videobuf2_memops usbhid hid mousedev 
snd_hda_codec arc4 snd_hwdep iwlwifi toshiba_acpi psmouse snd_pcm snd_timer 
sparse_keymap ehci_hcd battery serio_raw mac80211 evdev thermal ac xhci_hcd 
snd_page_alloc wmi power_supply e1000e mei(C) sdhci_pci sdhci mmc_core 
firmware_class cfg80211 rfkill processor sg rtc_cmos loop unix [last unloaded: 
snd_hda_intel]
Mar  6 09:05:57 dragon kernel: [137560.924560] 
Mar  6 09:05:58 dragon kernel: [137560.924564] Pid: 1399, comm: X Tainted: G
 C   3.3.0-rc5 #2 TOSHIBA PORTEGE R835/Portable PC
Mar  6 09:05:58 dragon kernel: [137560.924572] RIP: 0033:[<7f57463c7035>]  
[<7f57463c7035>] 0x7f57463c7034
Mar  6 09:05:58 dragon kernel: [137560.924581] RSP: 002b:7fff0ac33758  
EFLAGS: 3206
Mar  6 09:05:58 dragon kernel: [137560.924585] RAX:  RBX: 
 RCX: 
Mar  6 09:05:58 dragon kernel: [137560.924589] RDX: 0006 RSI: 
0577 RDI: 0577
Mar  6 09:05:58 dragon kernel: [137560.924593] RBP: 7fff0ac341a0 R08: 
7f57464ee8e0 R09: 00411e40
Mar  6 09:05:59 dragon kernel: [137560.924597] R10: 0008 R11: 
3206 R12: 0037
Mar  6 09:06:00 dragon kernel: [137560.924600] R13: 7fff0ac33a80 R14: 
004f R15: 0007
Mar  6 09:06:00 dragon kernel: [137560.924604] FS:  7f57487a18a0() 
GS:88014a60() knlGS:
Mar  6 09:06:02 dragon kernel: [137560.924609] CS:  0010 DS:  ES:  CR0: 
80050033
Mar  6 09:06:02 dragon kernel: [137560.924612] CR2: 00418ff0 CR3: 
00013d059000 CR4: 000406e0
Mar  6 09:06:02 dragon kernel: [137560.924616] DR0:  DR1: 
 DR2: 
Mar  6 09:06:02 dragon kernel: [137560.924620] DR3:  DR6: 
0ff0 DR7: 0400
Mar  6 09:06:03 dragon kernel: [137560.924624] Process X (pid: 1399, threadinfo 
88013e9cc000, task 88012412)
Mar  6 09:06:03 dragon kernel: [137560.924627] 
Mar  6 09:06:03 dragon kernel: [137560.924630] Call Trace:




Any ideas/suggestions?



"look for more information in /debug/dri/0/i915_error_state"

Where is that file?  in debugfs or somewhere else?

thanks,
-- 
~Randy

[PATCH] drm: cope with platformdev->id == -1

[Rob Clark]

From: Rob Clark 

If there are not multiple instances of a platform device, the id
should apparently be set to -1.  Which results in a odd looking
bus-id like "platform:foodrm:-1".  Probably we should just treat
this case as id 0.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_platform.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index ae9db5e..82431dc 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -122,7 +122,7 @@ static const char *drm_platform_get_name(struct drm_device 
*dev)

 static int drm_platform_set_busid(struct drm_device *dev, struct drm_master 
*master)
 {
-   int len, ret;
+   int len, ret, id;

master->unique_len = 13 + strlen(dev->platformdev->name);
master->unique_size = master->unique_len;
@@ -131,8 +131,16 @@ static int drm_platform_set_busid(struct drm_device *dev, 
struct drm_master *mas
if (master->unique == NULL)
return -ENOMEM;

+   id = dev->platformdev->id;
+
+   /* if only a single instance of the platform device, id will be
+* set to -1.. use 0 instead to avoid a funny looking bus-id:
+*/
+   if (id == -1)
+   id = 0;
+
len = snprintf(master->unique, master->unique_len,
-   "platform:%s:%02d", dev->platformdev->name, 
dev->platformdev->id);
+   "platform:%s:%02d", dev->platformdev->name, id);

if (len > master->unique_len) {
DRM_ERROR("Unique buffer overflowed\n");
-- 
1.7.5.4

[git pull] drm gma500 fix

[Dave Airlie]

> On Mon, Mar 5, 2012 at 2:36 PM, Keith Packard  wrote:
> > <#part sign=pgpmime>
> > On Mon, 5 Mar 2012 14:09:13 -0800, Linus Torvalds  > linux-foundation.org> wrote:
> >> Hmm. Is freedesktop.org having trouble?
> >
> > ECC memory errors -- we're moving this stuff to a new machine as quickly
> > as rsync can run...
> 
> Ok. I'll just take Alan's patch directly as a patch.
> 
> No worries.

Hi Linus,

cool, I've pushed out drm-fixes again to the new annarchy, seems to be 
working from here.

Dave.

[PATCH] omap2+: add drm device

[Gross, Andy]

On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen wrote:
>
>
> I have to say I don't know much about DMM, but my understanding is that
> DMM is a bigger entity, of which TILER is only a small part, and DMM
> manages all memory accesses.
>
> Can there be other users for the DMM than DRM? I know there could be
> other users for the TILER, and I know you want to combine that with the
> DRM driver, but I'm wondering about the other parts of DMM than the
> TILER.
>
> Somehow having a DMM driver inside omapdrm sounds strange.


The DMM does indeed contain a number of entities.  However, the TILER
portion is the only part that requires a driver.  All other register
modifications (LISA map settings, EMIF, etc) are done statically in the
loader or u-boot and never changed again.  As such, DMM has become
synonymous with TILER.

Regards,

Andy
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120306/3e2bf685/attachment.htm>

[PATCH] omap2+: add drm device

[Rob Clark]

On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen  wrote:
> On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
>> On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen  
>> wrote:
>
>> > Can there be more than one omapdrm device? I guess not. If so, the id
>> > should be -1.
>>
>> in the past, we have used multiple devices (using the platform-data to
>> divide up the dss resources), although this was sort of a
>> special-case. ?But in theory you could have multiple. ?(Think of a
>> multi-seat scenario, where multiple compositors need to run and each
>> need to be drm-master of their own device to do mode-setting on their
>> corresponding display.)
>>
>> I think if we use .id = -1, then we'd end up with a funny looking
>> bus-id for the device: "platform:omapdrm:-1"
>
> I don't know about that, but it's the way platform devices are meant to
> be used if there can be only one instance. If the case where there are
> multiple omapdrm devices is rather theoretical, or only used for certain
> debugging scenarios or such, I think having the id as -1 in the mainline
> is cleaner.

well, I don't care much one way or another, but need to check if there
is a small patch needed in drm core code that generates the bus-id for
.id = -1..

>> >> +};
>> >> +
>> >> +static int __init omap_init_gpu(void)
>> >> +{
>> >> + ? ? struct omap_hwmod *oh = NULL;
>> >> + ? ? struct platform_device *pdev;
>> >> +
>> >> + ? ? /* lookup and populate the DMM information, if present - OMAP4+ */
>> >> + ? ? oh = omap_hwmod_lookup("dmm");
>> >> +
>> >> + ? ? if (oh) {
>> >> + ? ? ? ? ? ? pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
>> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? false);
>> >> + ? ? ? ? ? ? WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
>> >> + ? ? ? ? ? ? ? ? ? ? oh->name);
>> >> + ? ? }
>> >> +
>> >> + ? ? return platform_device_register(_drm_device);
>> >> +
>> >> +}
>> >
>> > The function is called omap_init_gpu(), but it doesn't do anything
>> > related to the gpu... And aren't DMM and DRM totally separate things,
>> > why are they bunched together like that?
>>
>> only legacy.. product branches also have sgx initialization here. ?But
>> I can change that to omap_init_drm()
>>
>> DMM is managed by the drm driver (and exposed to userspace as drm/gem
>> buffers, shared with other devices via dma-buf, etc). ?It is only
>> split out to a separate device to play along with hwmod.
>
> I have to say I don't know much about DMM, but my understanding is that
> DMM is a bigger entity, of which TILER is only a small part, and DMM
> manages all memory accesses.

when most people refer to TILER they actually refer to DMM..

DMM is the piece which is basically a GART, it is what omapdrm is
programming and managing.

> Can there be other users for the DMM than DRM? I know there could be
> other users for the TILER, and I know you want to combine that with the
> DRM driver, but I'm wondering about the other parts of DMM than the
> TILER.

yes, clearly there are other users.. we pass gem buffers allocated
from omapdrm to (for example, video decoder).  But it is omapdrm which
is managing the allocation, keeping track of which buffers are pinned
and which can be evicted, dealing with the complications of userspace
mmap'ing of tiled buffers, etc.  That stuff you don't want littered
throughout the kernel.

> Somehow having a DMM driver inside omapdrm sounds strange.
>
>> >> +arch_initcall(omap_init_gpu);
>> >> +
>> >> +void omapdrm_reserve_vram(void)
>> >> +{
>> >> +#ifdef CONFIG_CMA
>> >> + ? ? /*
>> >> + ? ? ?* Create private 32MiB contiguous memory area for omapdrm.0 device
>> >> + ? ? ?* TODO revisit size.. if uc/wc buffers are allocated from CMA pages
>> >> + ? ? ?* then the amount of memory we need goes up..
>> >> + ? ? ?*/
>> >> + ? ? dma_declare_contiguous(_drm_device.dev, 32 * SZ_1M, 0, 0);
>> >
>> > What does this actually do? Does it reserve the memory, i.e. it's not
>> > usable for others? If so, shouldn't there be a way for the user to
>> > configure it?
>>
>> It can be re-used by others.. see http://lwn.net/Articles/479297/
>
> The link didn't tell much. I looked at the patches, and
> dma_declare_contiguous allocates the memory with memblock_alloc. So is
> that allocated memory available for any users? If so, why does the
> function want a device pointer as an argument...
>
> Is the memory available for normal kmalloc, or only available via the
> CMA functions? Surely there must be some downside to the above? =) And
> if so, it should be configurable. You could have a board with no display
> at all, and you probably don't want to have 32MB allocated for DRM in
> that case.

Basically the short version is memory from a CMA carveout can be
re-used for unpinnable memory.  Not kmalloc, but it can be used for
anon userspace pages, for example.  Userspace needs memory too.

BR,
-R

> ?Tomi
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> 

[PATCH] xf86-video-modesetting cursor reload

[Alex Deucher]

On Tue, Mar 6, 2012 at 8:55 AM, James Simmons  wrote:
>
> Enable after a resolution change reload the cursor image.
>
> Signed-off-by: James Simmons 

Reviewed-by: Alex Deucher 

>
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index 7fa933a..8a49103 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> @@ -361,11 +361,9 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr 
> mode,
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
>
> -#if 0
> - ? ? ? if (pScrn->pScreen &&
> - ? ? ? ? ? ? ? !xf86ReturnOptValBool(info->Options, OPTION_SW_CURSOR, FALSE))
> + ? ? ? if (pScrn->pScreen && !drmmode->sw_cursor)
> ? ? ? ? ? ? ? ?xf86_reload_cursors(pScrn->pScreen);
> -#endif
> +
> ?done:
> ? ? ? ?if (!ret) {
> ? ? ? ? ? ? ? ?crtc->x = saved_x;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[korg]help: How to submit a kernel driver on kernel.org.

[Alex Deucher]

On Mon, Mar 5, 2012 at 11:13 PM, Aaron.Chen  ??
 wrote:
> Hi Paul,
>
> Thank you very much for your guide. It's a great help for me.
>
> But I still have a little problem with the patch thing. I'm not familiar with 
> the git.
> 1.Shall I need to do the clone and get the source location and target 
> directory first?
> 2.Where is the source location and target directory?
> 3.Our driver has pass the customer's test from kernel version 2.6.5 to 3.0.0, 
> So what shall I do to submit a driver cover all these kernel version.
> 4.or just email you the source code and tell you the changes?
>
> I'm looking forward your re-guide. Thank you so much.

Your best bet it to clone Linus' git tree and then apply your patches:

1. clone Linus' git tree:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
2.a) apply your first patch
   b)  if you patch adds new files to the source tree, add them:
git add path/to/files/file.c
git add path/to/files/file.h
etc.  if the patch only modifies patches that are already
in the tree, you do not need to add them.
   c) when the patch is applied commit it:
   git commit -a -s
   d) when you run the commit command you will be prompted to
enter a commit message.  The commit message has the following format:

subsystem: patch description

description of what the patch does.

Signed-off-by: Your name 

E.g.,

fb: add initial code for video 5000 graphics

This adds the initial support for the video 5000
graphics adapter.  It supports vga and lcd connectors.

Signed-off-by: Joe Developer 

e) repeat steps a-d for all of your patches
3. generate patches:
git format-patch -n

where n is the number of patches you committed.  E.g., if your driver
consists of 5 patches:
git format-patch -5

4. Send the patches to the list.

Alex

>
> Regards
> Aaron
>
>
> --
> ??: Paul Menzel [mailto:paulepanter at users.sourceforge.net]
> : 2012??3??2?? 5:50
> ??: Jerome Glisse
> : Aaron.Chen ??; dri-devel at lists.freedesktop.org
> : Re: [korg]help: How to submit a kernel driver on kernel.org.
>
> Dear Aaron,
>
>
> thank you for contacting the list. We are looking forward to your patches.
>
> Am Donnerstag, den 01.03.2012, 14:05 -0500 schrieb Jerome Glisse:
>> On Thu, 2012-03-01 at 14:28 +0800, Aaron.Chen ?? wrote:
>
>> > I??m from Silicon Motion Technology Corporation (NasdaqGS:SIMO) Shanghai 
>> > Office. We have developed a kernel driver for all our graphics chips. We 
>> > really want to know the way to submit a kernel driver to kernel.org. I 
>> > have received a document file which is on 
>> > http://kernel.org/doc/Documentation/SubmittingDrivers, but I still cannot 
>> > find out a place to where our drivers should be uploaded. The document say 
>> > ??please submit it to the maintainer listed in MAINTAINERS in the kernel 
>> > file.??So where can I find the maintainer and what to do next. Would you 
>> > please help me. Thank you so much.
>
>> All you need to do is send the kernel patch to
>> dri-devel at lists.freedesktop.org
>>
>> So they can get reviewed. Once they are reviewed, and if they comply
>> with the requirement, the DRM maintainer (aka Dave) will integrate
>> your patch in his tree and at some point ask Linus to pull them.
>>
>> There is no ftp, or http web submission, everything is done through
>> public mailing list.
>
> if you are familiar with Git you should send a patch formatted using `git 
> format-patch -15`. Replace the 15 by the number of commits you need patches 
> for.
>
> You can take a look in the archive. drm/exynos and drm/omap are good examples 
> ?C I think ?C on how to get new drivers submitted.
>
>
> Thanks,
>
> Paul
>
>
> PS: Please also try to follow the netiquette when posting to lists [1].
> Especially just send plain text messages (no HTML).
>
>
> [1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: deal with errors from framebuffer init path.

[Alex Deucher]

On Tue, Mar 6, 2012 at 5:48 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> We've been seeing a very occasional oops on a 32-bit rn50 platform running EL6
> kernels at boot. It seems to be due to one of these functions failing and
> us then accessing a NULL-300 pointer.
>
> This should prevent the oops and give some info in the logs as to what is 
> going on.
>
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 

> ---
> ?drivers/gpu/drm/radeon/radeon_display.c | ? 18 +++---
> ?drivers/gpu/drm/radeon/radeon_fb.c ? ? ?| ? 11 ++-
> ?drivers/gpu/drm/radeon/radeon_mode.h ? ?| ? ?2 +-
> ?3 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 8c49fef..3d31433 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -1078,15 +1078,21 @@ static const struct drm_framebuffer_funcs 
> radeon_fb_funcs = {
> ? ? ? ?.create_handle = radeon_user_framebuffer_create_handle,
> ?};
>
> -void
> +int
> ?radeon_framebuffer_init(struct drm_device *dev,
> ? ? ? ? ? ? ? ? ? ? ? ?struct radeon_framebuffer *rfb,
> ? ? ? ? ? ? ? ? ? ? ? ?struct drm_mode_fb_cmd2 *mode_cmd,
> ? ? ? ? ? ? ? ? ? ? ? ?struct drm_gem_object *obj)
> ?{
> + ? ? ? int ret;
> ? ? ? ?rfb->obj = obj;
> - ? ? ? drm_framebuffer_init(dev, >base, _fb_funcs);
> + ? ? ? ret = drm_framebuffer_init(dev, >base, _fb_funcs);
> + ? ? ? if (ret) {
> + ? ? ? ? ? ? ? rfb->obj = NULL;
> + ? ? ? ? ? ? ? return ret;
> + ? ? ? }
> ? ? ? ?drm_helper_mode_fill_fb_struct(>base, mode_cmd);
> + ? ? ? return 0;
> ?}
>
> ?static struct drm_framebuffer *
> @@ -1096,6 +1102,7 @@ radeon_user_framebuffer_create(struct drm_device *dev,
> ?{
> ? ? ? ?struct drm_gem_object *obj;
> ? ? ? ?struct radeon_framebuffer *radeon_fb;
> + ? ? ? int ret;
>
> ? ? ? ?obj = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
> ? ? ? ?if (obj == ?NULL) {
> @@ -1108,7 +1115,12 @@ radeon_user_framebuffer_create(struct drm_device *dev,
> ? ? ? ?if (radeon_fb == NULL)
> ? ? ? ? ? ? ? ?return ERR_PTR(-ENOMEM);
>
> - ? ? ? radeon_framebuffer_init(dev, radeon_fb, mode_cmd, obj);
> + ? ? ? ret = radeon_framebuffer_init(dev, radeon_fb, mode_cmd, obj);
> + ? ? ? if (ret) {
> + ? ? ? ? ? ? ? kfree(radeon_fb);
> + ? ? ? ? ? ? ? drm_gem_object_unreference_unlocked(obj);
> + ? ? ? ? ? ? ? return NULL;
> + ? ? ? }
>
> ? ? ? ?return _fb->base;
> ?}
> diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
> b/drivers/gpu/drm/radeon/radeon_fb.c
> index cf2bf35..195471c 100644
> --- a/drivers/gpu/drm/radeon/radeon_fb.c
> +++ b/drivers/gpu/drm/radeon/radeon_fb.c
> @@ -209,6 +209,11 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> ?sizes->surface_depth);
>
> ? ? ? ?ret = radeonfb_create_pinned_object(rfbdev, _cmd, );
> + ? ? ? if (ret) {
> + ? ? ? ? ? ? ? DRM_ERROR("failed to create fbcon object %d\n", ret);
> + ? ? ? ? ? ? ? return ret;
> + ? ? ? }
> +
> ? ? ? ?rbo = gem_to_radeon_bo(gobj);
>
> ? ? ? ?/* okay we have an object now allocate the framebuffer */
> @@ -220,7 +225,11 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,
>
> ? ? ? ?info->par = rfbdev;
>
> - ? ? ? radeon_framebuffer_init(rdev->ddev, >rfb, _cmd, gobj);
> + ? ? ? ret = radeon_framebuffer_init(rdev->ddev, >rfb, _cmd, 
> gobj);
> + ? ? ? if (ret) {
> + ? ? ? ? ? ? ? DRM_ERROR("failed to initalise framebuffer %d\n", ret);
> + ? ? ? ? ? ? ? goto out_unref;
> + ? ? ? }
>
> ? ? ? ?fb = >rfb.base;
>
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 4330e32..8a85598 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -649,7 +649,7 @@ extern void radeon_crtc_fb_gamma_set(struct drm_crtc 
> *crtc, u16 red, u16 green,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u16 blue, int regno);
> ?extern void radeon_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 
> *green,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u16 *blue, int regno);
> -void radeon_framebuffer_init(struct drm_device *dev,
> +int radeon_framebuffer_init(struct drm_device *dev,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct radeon_framebuffer *rfb,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct drm_mode_fb_cmd2 *mode_cmd,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct drm_gem_object *obj);
> --
> 1.7.7.6
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] omap2+: add drm device

[Rob Clark]

On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen  wrote:
> On Mon, 2012-03-05 at 10:54 -0600, Rob Clark wrote:
>> From: Andy Gross 
>>
>> Register OMAP DRM/KMS platform device, and reserve a CMA region for
>> the device to use for buffer allocation. ?DMM is split into a
>> separate device using hwmod.
>>
>> Signed-off-by: Andy Gross 
>> Signed-off-by: Rob Clark 
>> ---
>> ?arch/arm/plat-omap/Makefile ? ? ? ? ? | ? ?2 +-
>> ?arch/arm/plat-omap/common.c ? ? ? ? ? | ? ?3 +-
>> ?arch/arm/plat-omap/drm.c ? ? ? ? ? ? ?| ? 83 
>> +
>> ?arch/arm/plat-omap/include/plat/drm.h | ? 64 +
>> ?4 files changed, 150 insertions(+), 2 deletions(-)
>> ?create mode 100644 arch/arm/plat-omap/drm.c
>> ?create mode 100644 arch/arm/plat-omap/include/plat/drm.h
>>
>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
>> index 9a58461..b86e6cb 100644
>> --- a/arch/arm/plat-omap/Makefile
>> +++ b/arch/arm/plat-omap/Makefile
>> @@ -4,7 +4,7 @@
>>
>> ?# Common support
>> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
>> - ? ? ?usb.o fb.o counter_32k.o
>> + ? ? ?usb.o fb.o counter_32k.o drm.o
>> ?obj-m :=
>> ?obj-n :=
>> ?obj- ?:=
>> diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
>> index 06383b5..0d87dab 100644
>> --- a/arch/arm/plat-omap/common.c
>> +++ b/arch/arm/plat-omap/common.c
>> @@ -21,10 +21,10 @@
>> ?#include 
>> ?#include 
>> ?#include 
>> +#include 
>>
>> ?#include 
>>
>> -
>> ?#define NO_LENGTH_CHECK 0x
>>
>> ?struct omap_board_config_kernel *omap_board_config __initdata;
>> @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t 
>> *len)
>>
>> ?void __init omap_reserve(void)
>> ?{
>> + ? ? omapdrm_reserve_vram();
>> ? ? ? omapfb_reserve_sdram_memblock();
>> ? ? ? omap_vram_reserve_sdram_memblock();
>> ? ? ? omap_dsp_reserve_sdram_memblock();
>> diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c
>
> As Tony said, mach-omap2 is probably a better place. fb.c is in
> plat-omap because it supports both OMAP1 and OMAP2+.
>
>> new file mode 100644
>> index 000..28279df
>> --- /dev/null
>> +++ b/arch/arm/plat-omap/drm.c
>> @@ -0,0 +1,83 @@
>> +/*
>> + * DRM/KMS device registration for TI OMAP platforms
>> + *
>> + * Copyright (C) 2012 Texas Instruments
>> + * Author: Rob Clark 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published 
>> by
>> + * the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but 
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along 
>> with
>> + * this program. ?If not, see .
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#ifdef CONFIG_CMA
>> +# ?include 
>> +#endif
>> +
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
>> +
>> +static struct omap_drm_platform_data omapdrm_platdata;
>> +
>> +static struct platform_device omap_drm_device = {
>> + ? ? ? ? ? ? .dev = {
>> + ? ? ? ? ? ? ? ? ? ? .coherent_dma_mask = DMA_BIT_MASK(32),
>> + ? ? ? ? ? ? ? ? ? ? .platform_data = _platdata,
>> + ? ? ? ? ? ? },
>> + ? ? ? ? ? ? .name = "omapdrm",
>> + ? ? ? ? ? ? .id = 0,
>
> Can there be more than one omapdrm device? I guess not. If so, the id
> should be -1.

in the past, we have used multiple devices (using the platform-data to
divide up the dss resources), although this was sort of a
special-case.  But in theory you could have multiple.  (Think of a
multi-seat scenario, where multiple compositors need to run and each
need to be drm-master of their own device to do mode-setting on their
corresponding display.)

I think if we use .id = -1, then we'd end up with a funny looking
bus-id for the device: "platform:omapdrm:-1"

>> +};
>> +
>> +static int __init omap_init_gpu(void)
>> +{
>> + ? ? struct omap_hwmod *oh = NULL;
>> + ? ? struct platform_device *pdev;
>> +
>> + ? ? /* lookup and populate the DMM information, if present - OMAP4+ */
>> + ? ? oh = omap_hwmod_lookup("dmm");
>> +
>> + ? ? if (oh) {
>> + ? ? ? ? ? ? pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? false);
>> + ? ? ? ? ? ? WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
>> + ? ? ? ? ? ? ? ? ? ? oh->name);
>> + ? ? }
>> +
>> + ? ? return platform_device_register(_drm_device);
>> +
>> +}
>
> The function is called omap_init_gpu(), but it doesn't do anything
> related to the gpu... And aren't DMM and DRM totally separate things,
> why are they bunched together like that?

only legacy.. product branches also have 

Re: [git pull] drm gma500 fix

[Dave Airlie]

 On Mon, Mar 5, 2012 at 2:36 PM, Keith Packard kei...@keithp.com wrote:
  #part sign=pgpmime
  On Mon, 5 Mar 2012 14:09:13 -0800, Linus Torvalds 
  torva...@linux-foundation.org wrote:
  Hmm. Is freedesktop.org having trouble?
 
  ECC memory errors -- we're moving this stuff to a new machine as quickly
  as rsync can run...
 
 Ok. I'll just take Alan's patch directly as a patch.
 
 No worries.

Hi Linus,

cool, I've pushed out drm-fixes again to the new annarchy, seems to be 
working from here.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] dma-buf: add support for kernel cpu access

[Semwal, Sumit]

Hi Daniel,
On Tue, Mar 6, 2012 at 12:27 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 On Fri, Mar 2, 2012 at 23:24, Rob Clark robdcl...@gmail.com wrote:
 Perhaps we should check somewhere for required dmabuf ops fxns (like
 kmap_atomic here), rather than just calling unconditionally what might
 be a null ptr.  At least put it in the WARN_ON(), but it might be
 nicer to catch a missing required fxns at export time, rather than
 waiting for an importer to try and call it.  Less likely that way, for
 newly added required functions go unnoticed.

 (same comment applies below for the non-atomic variant.. and possibly
 some other existing dmabuf ops)

 Agreed, I'll rework the patch to do that when rebasing onto Sumit's latest 
 tree.
In addition, you'd not need to check for !dmabuf-ops since the export
should already catch it.

As I sent in the other mail a while back, could you please rebase on
for-next at git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git

Best regards,
~Sumit.
 -Daniel
 --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: deal with errors from framebuffer init path.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

We've been seeing a very occasional oops on a 32-bit rn50 platform running EL6
kernels at boot. It seems to be due to one of these functions failing and
us then accessing a NULL-300 pointer.

This should prevent the oops and give some info in the logs as to what is going 
on.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/radeon/radeon_display.c |   18 +++---
 drivers/gpu/drm/radeon/radeon_fb.c  |   11 ++-
 drivers/gpu/drm/radeon/radeon_mode.h|2 +-
 3 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 8c49fef..3d31433 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1078,15 +1078,21 @@ static const struct drm_framebuffer_funcs 
radeon_fb_funcs = {
.create_handle = radeon_user_framebuffer_create_handle,
 };
 
-void
+int
 radeon_framebuffer_init(struct drm_device *dev,
struct radeon_framebuffer *rfb,
struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object *obj)
 {
+   int ret;
rfb-obj = obj;
-   drm_framebuffer_init(dev, rfb-base, radeon_fb_funcs);
+   ret = drm_framebuffer_init(dev, rfb-base, radeon_fb_funcs);
+   if (ret) {
+   rfb-obj = NULL;
+   return ret;
+   }
drm_helper_mode_fill_fb_struct(rfb-base, mode_cmd);
+   return 0;
 }
 
 static struct drm_framebuffer *
@@ -1096,6 +1102,7 @@ radeon_user_framebuffer_create(struct drm_device *dev,
 {
struct drm_gem_object *obj;
struct radeon_framebuffer *radeon_fb;
+   int ret;
 
obj = drm_gem_object_lookup(dev, file_priv, mode_cmd-handles[0]);
if (obj ==  NULL) {
@@ -1108,7 +1115,12 @@ radeon_user_framebuffer_create(struct drm_device *dev,
if (radeon_fb == NULL)
return ERR_PTR(-ENOMEM);
 
-   radeon_framebuffer_init(dev, radeon_fb, mode_cmd, obj);
+   ret = radeon_framebuffer_init(dev, radeon_fb, mode_cmd, obj);
+   if (ret) {
+   kfree(radeon_fb);
+   drm_gem_object_unreference_unlocked(obj);
+   return NULL;
+   }
 
return radeon_fb-base;
 }
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index cf2bf35..195471c 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -209,6 +209,11 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,
  sizes-surface_depth);
 
ret = radeonfb_create_pinned_object(rfbdev, mode_cmd, gobj);
+   if (ret) {
+   DRM_ERROR(failed to create fbcon object %d\n, ret);
+   return ret;
+   }
+
rbo = gem_to_radeon_bo(gobj);
 
/* okay we have an object now allocate the framebuffer */
@@ -220,7 +225,11 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,
 
info-par = rfbdev;
 
-   radeon_framebuffer_init(rdev-ddev, rfbdev-rfb, mode_cmd, gobj);
+   ret = radeon_framebuffer_init(rdev-ddev, rfbdev-rfb, mode_cmd, 
gobj);
+   if (ret) {
+   DRM_ERROR(failed to initalise framebuffer %d\n, ret);
+   goto out_unref;
+   }
 
fb = rfbdev-rfb.base;
 
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index 4330e32..8a85598 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -649,7 +649,7 @@ extern void radeon_crtc_fb_gamma_set(struct drm_crtc *crtc, 
u16 red, u16 green,
 u16 blue, int regno);
 extern void radeon_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 
*green,
 u16 *blue, int regno);
-void radeon_framebuffer_init(struct drm_device *dev,
+int radeon_framebuffer_init(struct drm_device *dev,
 struct radeon_framebuffer *rfb,
 struct drm_mode_fb_cmd2 *mode_cmd,
 struct drm_gem_object *obj);
-- 
1.7.7.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Mon, 2012-03-05 at 10:54 -0600, Rob Clark wrote:
 From: Andy Gross andy.gr...@ti.com
 
 Register OMAP DRM/KMS platform device, and reserve a CMA region for
 the device to use for buffer allocation.  DMM is split into a
 separate device using hwmod.
 
 Signed-off-by: Andy Gross andy.gr...@ti.com
 Signed-off-by: Rob Clark r...@ti.com
 ---
  arch/arm/plat-omap/Makefile   |2 +-
  arch/arm/plat-omap/common.c   |3 +-
  arch/arm/plat-omap/drm.c  |   83 
 +
  arch/arm/plat-omap/include/plat/drm.h |   64 +
  4 files changed, 150 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/plat-omap/drm.c
  create mode 100644 arch/arm/plat-omap/include/plat/drm.h
 
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@
  
  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -  usb.o fb.o counter_32k.o
 +  usb.o fb.o counter_32k.o drm.o
  obj-m :=
  obj-n :=
  obj-  :=
 diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
 index 06383b5..0d87dab 100644
 --- a/arch/arm/plat-omap/common.c
 +++ b/arch/arm/plat-omap/common.c
 @@ -21,10 +21,10 @@
  #include plat/board.h
  #include plat/vram.h
  #include plat/dsp.h
 +#include plat/drm.h
  
  #include plat/omap-secure.h
  
 -
  #define NO_LENGTH_CHECK 0x
  
  struct omap_board_config_kernel *omap_board_config __initdata;
 @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
  
  void __init omap_reserve(void)
  {
 + omapdrm_reserve_vram();
   omapfb_reserve_sdram_memblock();
   omap_vram_reserve_sdram_memblock();
   omap_dsp_reserve_sdram_memblock();
 diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c

As Tony said, mach-omap2 is probably a better place. fb.c is in
plat-omap because it supports both OMAP1 and OMAP2+.

 new file mode 100644
 index 000..28279df
 --- /dev/null
 +++ b/arch/arm/plat-omap/drm.c
 @@ -0,0 +1,83 @@
 +/*
 + * DRM/KMS device registration for TI OMAP platforms
 + *
 + * Copyright (C) 2012 Texas Instruments
 + * Author: Rob Clark rob.cl...@linaro.org
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License version 2 as published 
 by
 + * the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful, but 
 WITHOUT
 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 + * more details.
 + *
 + * You should have received a copy of the GNU General Public License along 
 with
 + * this program.  If not, see http://www.gnu.org/licenses/.
 + */
 +
 +#include linux/module.h
 +#include linux/kernel.h
 +#include linux/mm.h
 +#include linux/init.h
 +#include linux/platform_device.h
 +#include linux/dma-mapping.h
 +#ifdef CONFIG_CMA
 +#  include linux/dma-contiguous.h
 +#endif
 +
 +#include plat/omap_device.h
 +#include plat/omap_hwmod.h
 +
 +#include plat/drm.h
 +
 +#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
 +
 +static struct omap_drm_platform_data omapdrm_platdata;
 +
 +static struct platform_device omap_drm_device = {
 + .dev = {
 + .coherent_dma_mask = DMA_BIT_MASK(32),
 + .platform_data = omapdrm_platdata,
 + },
 + .name = omapdrm,
 + .id = 0,

Can there be more than one omapdrm device? I guess not. If so, the id
should be -1.

 +};
 +
 +static int __init omap_init_gpu(void)
 +{
 + struct omap_hwmod *oh = NULL;
 + struct platform_device *pdev;
 +
 + /* lookup and populate the DMM information, if present - OMAP4+ */
 + oh = omap_hwmod_lookup(dmm);
 +
 + if (oh) {
 + pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
 + false);
 + WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
 + oh-name);
 + }
 +
 + return platform_device_register(omap_drm_device);
 +
 +}

The function is called omap_init_gpu(), but it doesn't do anything
related to the gpu... And aren't DMM and DRM totally separate things,
why are they bunched together like that?

 +arch_initcall(omap_init_gpu);
 +
 +void omapdrm_reserve_vram(void)
 +{
 +#ifdef CONFIG_CMA
 + /*
 +  * Create private 32MiB contiguous memory area for omapdrm.0 device
 +  * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
 +  * then the amount of memory we need goes up..
 +  */
 + dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);

What does this actually do? Does it reserve the memory, i.e. it's not
usable for others? If so, shouldn't there be a way for the user to
configure it?

 +#else
 

Re: [PATCH] drm/radeon: deal with errors from framebuffer init path.

[Alex Deucher]

On Tue, Mar 6, 2012 at 5:48 AM, Dave Airlie airl...@gmail.com wrote:
 From: Dave Airlie airl...@redhat.com

 We've been seeing a very occasional oops on a 32-bit rn50 platform running EL6
 kernels at boot. It seems to be due to one of these functions failing and
 us then accessing a NULL-300 pointer.

 This should prevent the oops and give some info in the logs as to what is 
 going on.

 Signed-off-by: Dave Airlie airl...@redhat.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  drivers/gpu/drm/radeon/radeon_display.c |   18 +++---
  drivers/gpu/drm/radeon/radeon_fb.c      |   11 ++-
  drivers/gpu/drm/radeon/radeon_mode.h    |    2 +-
  3 files changed, 26 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
 b/drivers/gpu/drm/radeon/radeon_display.c
 index 8c49fef..3d31433 100644
 --- a/drivers/gpu/drm/radeon/radeon_display.c
 +++ b/drivers/gpu/drm/radeon/radeon_display.c
 @@ -1078,15 +1078,21 @@ static const struct drm_framebuffer_funcs 
 radeon_fb_funcs = {
        .create_handle = radeon_user_framebuffer_create_handle,
  };

 -void
 +int
  radeon_framebuffer_init(struct drm_device *dev,
                        struct radeon_framebuffer *rfb,
                        struct drm_mode_fb_cmd2 *mode_cmd,
                        struct drm_gem_object *obj)
  {
 +       int ret;
        rfb-obj = obj;
 -       drm_framebuffer_init(dev, rfb-base, radeon_fb_funcs);
 +       ret = drm_framebuffer_init(dev, rfb-base, radeon_fb_funcs);
 +       if (ret) {
 +               rfb-obj = NULL;
 +               return ret;
 +       }
        drm_helper_mode_fill_fb_struct(rfb-base, mode_cmd);
 +       return 0;
  }

  static struct drm_framebuffer *
 @@ -1096,6 +1102,7 @@ radeon_user_framebuffer_create(struct drm_device *dev,
  {
        struct drm_gem_object *obj;
        struct radeon_framebuffer *radeon_fb;
 +       int ret;

        obj = drm_gem_object_lookup(dev, file_priv, mode_cmd-handles[0]);
        if (obj ==  NULL) {
 @@ -1108,7 +1115,12 @@ radeon_user_framebuffer_create(struct drm_device *dev,
        if (radeon_fb == NULL)
                return ERR_PTR(-ENOMEM);

 -       radeon_framebuffer_init(dev, radeon_fb, mode_cmd, obj);
 +       ret = radeon_framebuffer_init(dev, radeon_fb, mode_cmd, obj);
 +       if (ret) {
 +               kfree(radeon_fb);
 +               drm_gem_object_unreference_unlocked(obj);
 +               return NULL;
 +       }

        return radeon_fb-base;
  }
 diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
 b/drivers/gpu/drm/radeon/radeon_fb.c
 index cf2bf35..195471c 100644
 --- a/drivers/gpu/drm/radeon/radeon_fb.c
 +++ b/drivers/gpu/drm/radeon/radeon_fb.c
 @@ -209,6 +209,11 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,
                                                          
 sizes-surface_depth);

        ret = radeonfb_create_pinned_object(rfbdev, mode_cmd, gobj);
 +       if (ret) {
 +               DRM_ERROR(failed to create fbcon object %d\n, ret);
 +               return ret;
 +       }
 +
        rbo = gem_to_radeon_bo(gobj);

        /* okay we have an object now allocate the framebuffer */
 @@ -220,7 +225,11 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,

        info-par = rfbdev;

 -       radeon_framebuffer_init(rdev-ddev, rfbdev-rfb, mode_cmd, gobj);
 +       ret = radeon_framebuffer_init(rdev-ddev, rfbdev-rfb, mode_cmd, 
 gobj);
 +       if (ret) {
 +               DRM_ERROR(failed to initalise framebuffer %d\n, ret);
 +               goto out_unref;
 +       }

        fb = rfbdev-rfb.base;

 diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
 b/drivers/gpu/drm/radeon/radeon_mode.h
 index 4330e32..8a85598 100644
 --- a/drivers/gpu/drm/radeon/radeon_mode.h
 +++ b/drivers/gpu/drm/radeon/radeon_mode.h
 @@ -649,7 +649,7 @@ extern void radeon_crtc_fb_gamma_set(struct drm_crtc 
 *crtc, u16 red, u16 green,
                                     u16 blue, int regno);
  extern void radeon_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 
 *green,
                                     u16 *blue, int regno);
 -void radeon_framebuffer_init(struct drm_device *dev,
 +int radeon_framebuffer_init(struct drm_device *dev,
                             struct radeon_framebuffer *rfb,
                             struct drm_mode_fb_cmd2 *mode_cmd,
                             struct drm_gem_object *obj);
 --
 1.7.7.6

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [korg]help: How to submit a kernel driver on kernel.org.

[Alex Deucher]

On Mon, Mar 5, 2012 at 11:13 PM, Aaron.Chen  陈俊杰
aaron.c...@siliconmotion.com wrote:
 Hi PaulJerome,

 Thank you very much for your guide. It's a great help for me.

 But I still have a little problem with the patch thing. I'm not familiar with 
 the git.
 1.Shall I need to do the clone and get the source location and target 
 directory first?
 2.Where is the source location and target directory?
 3.Our driver has pass the customer's test from kernel version 2.6.5 to 3.0.0, 
 So what shall I do to submit a driver cover all these kernel version.
 4.or just email you the source code and tell you the changes?

 I'm looking forward your re-guide. Thank you so much.

Your best bet it to clone Linus' git tree and then apply your patches:

1. clone Linus' git tree:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
2.a) apply your first patch
   b)  if you patch adds new files to the source tree, add them:
git add path/to/files/file.c
git add path/to/files/file.h
etc.  if the patch only modifies patches that are already
in the tree, you do not need to add them.
   c) when the patch is applied commit it:
   git commit -a -s
   d) when you run the commit command you will be prompted to
enter a commit message.  The commit message has the following format:

subsystem: patch description

description of what the patch does.

Signed-off-by: Your name your_em...@domain.com

E.g.,

fb: add initial code for video 5000 graphics

This adds the initial support for the video 5000
graphics adapter.  It supports vga and lcd connectors.

Signed-off-by: Joe Developer joe.develo...@example.com

e) repeat steps a-d for all of your patches
3. generate patches:
git format-patch -n

where n is the number of patches you committed.  E.g., if your driver
consists of 5 patches:
git format-patch -5

4. Send the patches to the list.

Alex


 Regards
 Aaron


 -邮件原件-
 发件人: Paul Menzel [mailto:paulepan...@users.sourceforge.net]
 发送时间: 2012年3月2日 5:50
 收件人: Jerome Glisse
 抄送: Aaron.Chen 陈俊杰; dri-devel@lists.freedesktop.org
 主题: Re: [korg]help: How to submit a kernel driver on kernel.org.

 Dear Aaron,


 thank you for contacting the list. We are looking forward to your patches.

 Am Donnerstag, den 01.03.2012, 14:05 -0500 schrieb Jerome Glisse:
 On Thu, 2012-03-01 at 14:28 +0800, Aaron.Chen 陈俊杰 wrote:

  I’m from Silicon Motion Technology Corporation (NasdaqGS:SIMO) Shanghai 
  Office. We have developed a kernel driver for all our graphics chips. We 
  really want to know the way to submit a kernel driver to kernel.org. I 
  have received a document file which is on 
  http://kernel.org/doc/Documentation/SubmittingDrivers, but I still cannot 
  find out a place to where our drivers should be uploaded. The document say 
  “please submit it to the maintainer listed in MAINTAINERS in the kernel 
  file.”So where can I find the maintainer and what to do next. Would you 
  please help me. Thank you so much.

 All you need to do is send the kernel patch to
 dri-devel@lists.freedesktop.org

 So they can get reviewed. Once they are reviewed, and if they comply
 with the requirement, the DRM maintainer (aka Dave) will integrate
 your patch in his tree and at some point ask Linus to pull them.

 There is no ftp, or http web submission, everything is done through
 public mailing list.

 if you are familiar with Git you should send a patch formatted using `git 
 format-patch -15`. Replace the 15 by the number of commits you need patches 
 for.

 You can take a look in the archive. drm/exynos and drm/omap are good examples 
 �C I think �C on how to get new drivers submitted.


 Thanks,

 Paul


 PS: Please also try to follow the netiquette when posting to lists [1].
 Especially just send plain text messages (no HTML).


 [1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] xf86-video-modesetting cursor reload

[James Simmons]

Enable after a resolution change reload the cursor image.

Signed-off-by: James Simmons jsimm...@infradead.org

diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 7fa933a..8a49103 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -361,11 +361,9 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr 
mode,
}
}
 
-#if 0
-   if (pScrn-pScreen 
-   !xf86ReturnOptValBool(info-Options, OPTION_SW_CURSOR, FALSE))
+   if (pScrn-pScreen  !drmmode-sw_cursor)
xf86_reload_cursors(pScrn-pScreen);
-#endif
+
 done:
if (!ret) {
crtc-x = saved_x;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] xf86-video-modesetting cursor reload

[Alex Deucher]

On Tue, Mar 6, 2012 at 8:55 AM, James Simmons jsimm...@infradead.org wrote:

 Enable after a resolution change reload the cursor image.

 Signed-off-by: James Simmons jsimm...@infradead.org

Reviewed-by: Alex Deucher alexander.deuc...@amd.com


 diff --git a/src/drmmode_display.c b/src/drmmode_display.c
 index 7fa933a..8a49103 100644
 --- a/src/drmmode_display.c
 +++ b/src/drmmode_display.c
 @@ -361,11 +361,9 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr 
 mode,
                }
        }

 -#if 0
 -       if (pScrn-pScreen 
 -               !xf86ReturnOptValBool(info-Options, OPTION_SW_CURSOR, FALSE))
 +       if (pScrn-pScreen  !drmmode-sw_cursor)
                xf86_reload_cursors(pScrn-pScreen);
 -#endif
 +
  done:
        if (!ret) {
                crtc-x = saved_x;
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omap2+: add drm device

[Rob Clark]

On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On Mon, 2012-03-05 at 10:54 -0600, Rob Clark wrote:
 From: Andy Gross andy.gr...@ti.com

 Register OMAP DRM/KMS platform device, and reserve a CMA region for
 the device to use for buffer allocation.  DMM is split into a
 separate device using hwmod.

 Signed-off-by: Andy Gross andy.gr...@ti.com
 Signed-off-by: Rob Clark r...@ti.com
 ---
  arch/arm/plat-omap/Makefile           |    2 +-
  arch/arm/plat-omap/common.c           |    3 +-
  arch/arm/plat-omap/drm.c              |   83 
 +
  arch/arm/plat-omap/include/plat/drm.h |   64 +
  4 files changed, 150 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/plat-omap/drm.c
  create mode 100644 arch/arm/plat-omap/include/plat/drm.h

 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -      usb.o fb.o counter_32k.o
 +      usb.o fb.o counter_32k.o drm.o
  obj-m :=
  obj-n :=
  obj-  :=
 diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
 index 06383b5..0d87dab 100644
 --- a/arch/arm/plat-omap/common.c
 +++ b/arch/arm/plat-omap/common.c
 @@ -21,10 +21,10 @@
  #include plat/board.h
  #include plat/vram.h
  #include plat/dsp.h
 +#include plat/drm.h

  #include plat/omap-secure.h

 -
  #define NO_LENGTH_CHECK 0x

  struct omap_board_config_kernel *omap_board_config __initdata;
 @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t 
 *len)

  void __init omap_reserve(void)
  {
 +     omapdrm_reserve_vram();
       omapfb_reserve_sdram_memblock();
       omap_vram_reserve_sdram_memblock();
       omap_dsp_reserve_sdram_memblock();
 diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c

 As Tony said, mach-omap2 is probably a better place. fb.c is in
 plat-omap because it supports both OMAP1 and OMAP2+.

 new file mode 100644
 index 000..28279df
 --- /dev/null
 +++ b/arch/arm/plat-omap/drm.c
 @@ -0,0 +1,83 @@
 +/*
 + * DRM/KMS device registration for TI OMAP platforms
 + *
 + * Copyright (C) 2012 Texas Instruments
 + * Author: Rob Clark rob.cl...@linaro.org
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License version 2 as published 
 by
 + * the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful, but 
 WITHOUT
 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 + * more details.
 + *
 + * You should have received a copy of the GNU General Public License along 
 with
 + * this program.  If not, see http://www.gnu.org/licenses/.
 + */
 +
 +#include linux/module.h
 +#include linux/kernel.h
 +#include linux/mm.h
 +#include linux/init.h
 +#include linux/platform_device.h
 +#include linux/dma-mapping.h
 +#ifdef CONFIG_CMA
 +#  include linux/dma-contiguous.h
 +#endif
 +
 +#include plat/omap_device.h
 +#include plat/omap_hwmod.h
 +
 +#include plat/drm.h
 +
 +#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
 +
 +static struct omap_drm_platform_data omapdrm_platdata;
 +
 +static struct platform_device omap_drm_device = {
 +             .dev = {
 +                     .coherent_dma_mask = DMA_BIT_MASK(32),
 +                     .platform_data = omapdrm_platdata,
 +             },
 +             .name = omapdrm,
 +             .id = 0,

 Can there be more than one omapdrm device? I guess not. If so, the id
 should be -1.

in the past, we have used multiple devices (using the platform-data to
divide up the dss resources), although this was sort of a
special-case.  But in theory you could have multiple.  (Think of a
multi-seat scenario, where multiple compositors need to run and each
need to be drm-master of their own device to do mode-setting on their
corresponding display.)

I think if we use .id = -1, then we'd end up with a funny looking
bus-id for the device: platform:omapdrm:-1

 +};
 +
 +static int __init omap_init_gpu(void)
 +{
 +     struct omap_hwmod *oh = NULL;
 +     struct platform_device *pdev;
 +
 +     /* lookup and populate the DMM information, if present - OMAP4+ */
 +     oh = omap_hwmod_lookup(dmm);
 +
 +     if (oh) {
 +             pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
 +                                     false);
 +             WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
 +                     oh-name);
 +     }
 +
 +     return platform_device_register(omap_drm_device);
 +
 +}

 The function is called omap_init_gpu(), but it doesn't do anything
 related to the gpu... And aren't DMM and DRM totally separate things,
 why are they bunched together like that?

only 

[PATCH] drm: exynos: fix gem-prime support

[Tomasz Stanislawski]

From: Tomasz Stanislawski t.stanisl...@samsung.com

Fix error handling of dma_buf_export in exynos-drm driver.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index cbb6ad4..5f41de5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -200,7 +200,8 @@ int exynos_dmabuf_prime_handle_to_fd(struct drm_device 
*drm_dev,
 */
obj-export_dma_buf = dma_buf_export(obj, exynos_dmabuf_ops,
obj-size, 0600);
-   if (!obj-export_dma_buf) {
+   if (IS_ERR(obj-export_dma_buf)) {
+   DRM_DEBUG_KMS(failed to export dmabuf.\n);
ret = PTR_ERR(obj-export_dma_buf);
goto err2;
}
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] xf86-video-modesetting generic colormap handling

[James Simmons]

This patch replaces drmmode_load_palette with a very generic function
that removes the need of drmmode_crtc_private_rec to carry around 
color indexes. Also have the xorg driver actually call 
the xf86HandleColormaps function.

Signed-off-by: James Simmons jsimm...@infradead.org

diff --git a/src/driver.c b/src/driver.c
index 87431ff..a825f35 100644
--- a/src/driver.c
+++ b/src/driver.c
@@ -42,6 +42,7 @@
 #include xf86Pci.h
 #include mipointer.h
 #include micmap.h
+#include xf86cmap.h
 #include X11/extensions/randr.h
 #include fb.h
 #include edid.h
@@ -540,6 +541,62 @@ PreInit(ScrnInfoPtr pScrn, int flags)
 return FALSE;
 }
 
+static void
+LoadPalette(ScrnInfoPtr pScrn, int numColors, int *indices,
+LOCO * colors, VisualPtr pVisual)
+{
+xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
+CARD16 lut_r[256], lut_g[256], lut_b[256];
+int i, j, k, index;
+
+for (k = 0; k  xf86_config-num_crtc; k++) {
+xf86CrtcPtr crtc = xf86_config-crtc[k];
+
+switch (pScrn-depth) {
+case 15:
+for (i = 0; i  numColors; i++) {
+index = indices[i];
+for (j = 0; j  8; j++) {
+lut_r[index * 8 + j] = colors[index].red  8;
+lut_g[index * 8 + j] = colors[index].green  8;
+lut_b[index * 8 + j] = colors[index].blue  8;
+}
+}
+break;
+case 16:
+for (i = 0; i  numColors; i++) {
+index = indices[i];
+
+if (index = 31) {
+for (j = 0; j  8; j++) {
+lut_r[index * 8 + j] = colors[index].red  8;
+lut_b[index * 8 + j] = colors[index].blue  8;
+}
+}
+
+for (j = 0; j  4; j++)
+lut_g[index * 4 + j] = colors[index].green  8;
+}
+break;
+default:
+for (i = 0; i  numColors; i++) {
+index = indices[i];
+lut_r[index] = colors[index].red  8;
+lut_g[index] = colors[index].green  8;
+lut_b[index] = colors[index].blue  8;
+}
+break;
+}
+
+/* Make the change through RandR */
+#ifdef RANDR_12_INTERFACE
+RRCrtcGammaSet(crtc-randr_crtc, lut_r, lut_g, lut_b);
+#else /*RANDR_12_INTERFACE*/
+crtc-funcs-gamma_set(crtc, lut_r, lut_g, lut_b, 256);
+#endif
+}
+}
+
 static void *
 msShadowWindow(ScreenPtr screen, CARD32 row, CARD32 offset, int mode,
   CARD32 *size, void *closure)
@@ -716,7 +773,12 @@ ScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, 
char **argv)
return FALSE;
 
 if (!miCreateDefColormap(pScreen))
-   return FALSE;
+return FALSE;
+
+if (!xf86HandleColormaps(pScreen, 256, 8, LoadPalette, NULL,
+ CMAP_RELOAD_ON_MODE_SWITCH
+ | CMAP_PALETTED_TRUECOLOR))
+return FALSE;
 
 xf86DPMSInit(pScreen, xf86DPMSSet, 0);
 
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 7fa933a..d1da19a 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1134,89 +1132,6 @@ Bool drmmode_set_desired_modes(ScrnInfoPtr pScrn, 
drmmode_ptr drmmode)
return TRUE;
 }
 
-static void drmmode_load_palette(ScrnInfoPtr pScrn, int numColors,
- int *indices, LOCO *colors, VisualPtr pVisual)
-{
-xf86CrtcConfigPtr   xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
-uint16_t   lut_r[256], lut_g[256], lut_b[256];
-int index, j, i;
-int c;
-
-for (c = 0; c  xf86_config-num_crtc; c++) {
-xf86CrtcPtr crtc = xf86_config-crtc[c];
-   drmmode_crtc_private_ptr drmmode_crtc = crtc-driver_private;
-
-for (i = 0 ; i  256; i++) {
-lut_r[i] = drmmode_crtc-lut_r[i]  6;
-lut_g[i] = drmmode_crtc-lut_g[i]  6;
-lut_b[i] = drmmode_crtc-lut_b[i]  6;
-}
-
-switch(pScrn-depth) {
-case 15:
-for (i = 0; i  numColors; i++) {
-index = indices[i];
-for (j = 0; j  8; j++) {
-lut_r[index * 8 + j] = colors[index].red  6;
-lut_g[index * 8 + j] = colors[index].green  6;
-lut_b[index * 8 + j] = colors[index].blue  6;
-}
-}
- break;
- case 16:
- for (i = 0; i  numColors; i++) {
- index = indices[i];
-
-  if (i = 31) {
-  for (j = 0; j  8; j++) {
-  lut_r[index * 8 + j] = colors[index].red  6;
-  lut_b[index * 8 + j] = colors[index].blue  6;
-  }
-  }
-
-  for (j = 0; j  4; j++) {
-  lut_g[index * 4 + j] = colors[index].green  6;
-  }
-  

Re: [PATCH] omap2+: add drm device

[Tomi Valkeinen]

On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
 On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:

  Can there be more than one omapdrm device? I guess not. If so, the id
  should be -1.
 
 in the past, we have used multiple devices (using the platform-data to
 divide up the dss resources), although this was sort of a
 special-case.  But in theory you could have multiple.  (Think of a
 multi-seat scenario, where multiple compositors need to run and each
 need to be drm-master of their own device to do mode-setting on their
 corresponding display.)
 
 I think if we use .id = -1, then we'd end up with a funny looking
 bus-id for the device: platform:omapdrm:-1

I don't know about that, but it's the way platform devices are meant to
be used if there can be only one instance. If the case where there are
multiple omapdrm devices is rather theoretical, or only used for certain
debugging scenarios or such, I think having the id as -1 in the mainline
is cleaner.

  +};
  +
  +static int __init omap_init_gpu(void)
  +{
  + struct omap_hwmod *oh = NULL;
  + struct platform_device *pdev;
  +
  + /* lookup and populate the DMM information, if present - OMAP4+ */
  + oh = omap_hwmod_lookup(dmm);
  +
  + if (oh) {
  + pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
  + false);
  + WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
  + oh-name);
  + }
  +
  + return platform_device_register(omap_drm_device);
  +
  +}
 
  The function is called omap_init_gpu(), but it doesn't do anything
  related to the gpu... And aren't DMM and DRM totally separate things,
  why are they bunched together like that?
 
 only legacy.. product branches also have sgx initialization here.  But
 I can change that to omap_init_drm()
 
 DMM is managed by the drm driver (and exposed to userspace as drm/gem
 buffers, shared with other devices via dma-buf, etc).  It is only
 split out to a separate device to play along with hwmod.

I have to say I don't know much about DMM, but my understanding is that
DMM is a bigger entity, of which TILER is only a small part, and DMM
manages all memory accesses.

Can there be other users for the DMM than DRM? I know there could be
other users for the TILER, and I know you want to combine that with the
DRM driver, but I'm wondering about the other parts of DMM than the
TILER.

Somehow having a DMM driver inside omapdrm sounds strange.

  +arch_initcall(omap_init_gpu);
  +
  +void omapdrm_reserve_vram(void)
  +{
  +#ifdef CONFIG_CMA
  + /*
  +  * Create private 32MiB contiguous memory area for omapdrm.0 device
  +  * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
  +  * then the amount of memory we need goes up..
  +  */
  + dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
 
  What does this actually do? Does it reserve the memory, i.e. it's not
  usable for others? If so, shouldn't there be a way for the user to
  configure it?
 
 It can be re-used by others.. see http://lwn.net/Articles/479297/

The link didn't tell much. I looked at the patches, and
dma_declare_contiguous allocates the memory with memblock_alloc. So is
that allocated memory available for any users? If so, why does the
function want a device pointer as an argument...

Is the memory available for normal kmalloc, or only available via the
CMA functions? Surely there must be some downside to the above? =) And
if so, it should be configurable. You could have a board with no display
at all, and you probably don't want to have 32MB allocated for DRM in
that case.

 Tomi



signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [korg]help: How to submit a kernel driver on kernel.org.

[Paul Menzel]

Dear Aaron,


Am Dienstag, den 06.03.2012, 08:47 -0500 schrieb Alex Deucher:
 On Mon, Mar 5, 2012 at 11:13 PM, Aaron.Chen  陈俊杰 wrote:

  Thank you very much for your guide. It's a great help for me.
 
  But I still have a little problem with the patch thing. I'm not familiar 
  with the git.
  1.Shall I need to do the clone and get the source location and target 
  directory first?
  2.Where is the source location and target directory?
  3.Our driver has pass the customer's test from kernel version 2.6.5 to 
  3.0.0, So what shall I do to submit a driver cover all these kernel version.

you can only get new features included upstream in the latest Linux
kernel. So earliest version would be 3.4. You have to maintain you own
repository for earlier version. But backporting should be not so much
trouble if you have it included upstream.

  4.or just email you the source code and tell you the changes?
 
  I'm looking forward your re-guide. Thank you so much.
 
 Your best bet it to clone Linus' git tree and then apply your patches:
 
 1. clone Linus' git tree:
 git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

you can do this in between.

cd linux
git config --global user.name 陈俊杰 (Aaron Chen)
git config --global user.email aaron.c...@siliconmotion.com

 2.a) apply your first patch
b)  if you patch adds new files to the source tree, add them:
 git add path/to/files/file.c
 git add path/to/files/file.h
 etc.  if the patch only modifies patches that are already
 in the tree, you do not need to add them.
c) when the patch is applied commit it:
git commit -a -s
d) when you run the commit command you will be prompted to
 enter a commit message.  The commit message has the following format:
 
 subsystem: patch description
 
 description of what the patch does.
 
 Signed-off-by: Your name your_em...@domain.com
 
 E.g.,
 
 fb: add initial code for video 5000 graphics
 
 This adds the initial support for the video 5000
 graphics adapter.  It supports vga and lcd connectors.
 
 Signed-off-by: Joe Developer joe.develo...@example.com
 
 e) repeat steps a-d for all of your patches
 3. generate patches:
 git format-patch -n
 
 where n is the number of patches you committed.  E.g., if your driver
 consists of 5 patches:
 git format-patch -5
 
 4. Send the patches to the list.

Aaron, Git is nowadays documented pretty well. So just use

git help command

(like `git help commit`) to read the manual. Additionally you can just
search for it using your favorite search engine. Interesting reads
should be [1][2][3].


Thanks,

Paul


[1] http://schacon.github.com/git/user-manual.html#cleaning-up-history
[2] http://git-scm.com/documentation
[3] http://progit.org/book/


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42876] New: System doesn't boot with GTX 550 Ti

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42876

   Summary: System doesn't boot with GTX 550 Ti
   Product: Drivers
   Version: 2.5
Kernel Version: 3.2
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: blocking
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: art...@guitarplayer.ru
Regression: Yes


My hardware is:
ASUS P5KPL-AM SE, C2D E8500, GeForce GTX 550 Ti.

The problem is that with kernel newer than 3.2 (including 3.3 in Fedora 17), my
system doesn't boot at all. I'm using nouveau and have no proprietary nvidia
modules installed.
With 3.2, I'm getting nothing but Loading initial ramdisk on the screen, but
HDD LED is blinking and when I press the Power button on my PC, the system
turns off as it's supposed to.
But with 3.3 (in Fedora 17 and Ubuntu 12.04 with Canonical patched kernel), the
system doesn't boot at all. After Loading initial ramdisk the monitor turns
off, and nothing happens. HDD doesn't do anything.
This happens even without xf86-video-nouveau installed (i've tried Arch).

With kernel 3.1.9, my graphics card still works perfect, with a good 3D
acceleration. GNOME 3 works perfect too.

I'm sorry for my English.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Test application for DMABUF sharing between V4L2 and DRM

[Tomasz Stanislawski]

Hi Everyone,
This email contains a test application showing DMABUF sharing
between DRM/KMS display and camera capture node. It show simple
camera preview on LCD display. The similar application showing
DMABUF sharing between two V4L devices is available at link:

http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/43793/focus=43952

The program is written in C99 and it was tested using Exynos/DRM
and FIMC capture for M5MOLS and S5K6AAFX sensors on UniversalC210 board.

This application shows how buffer sharing between V4L2/DRM may look like.
Please let me know if/where I use DRM/V4L2 incorrectly.

The application was tested against 3.3-rc5 kernel with patches:
http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
[redesign of DMA mapping]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/43793/focus=43803
[support for dma_get_pages, PoC generic API for transforming DMA object 
into list of pages]
http://thread.gmane.org/gmane.comp.video.dri.devel/65583/focus=65703
[DRM prime support]
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm-dmabuf
[DRM prime support for Exynos DRM]
http://thread.gmane.org/gmane.comp.video.dri.devel/65992
[fix to DRM prime in Exynos DRM]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42966/focus=42968
[support for DMABUF importing in V4L2]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/45394
[integrate V4L2 with DMABUF]

Regards,
Tomasz Stanislawski

---
#include errno.h
#include fcntl.h
#include linux/videodev2.h
#include math.h
#include poll.h
#include stdio.h
#include stdint.h
#include stdlib.h
#include string.h
#include sys/ioctl.h
#include sys/mman.h
#include sys/stat.h
#include sys/types.h
#include unistd.h

#include xf86drm.h
#include xf86drmMode.h
#include exynos_drm.h

#define ERRSTR strerror(errno)

#define BYE_ON(cond, ...) \
do { \
if (cond) { \
int errsv = errno; \
fprintf(stderr, ERROR(%s:%d) : , \
__FILE__, __LINE__); \
errno = errsv; \
fprintf(stderr,  __VA_ARGS__); \
abort(); \
} \
} while(0)

static inline int warn(const char *file, int line, const char *fmt, ...)
{
int errsv = errno;
va_list va;
va_start(va, fmt);
fprintf(stderr, WARN(%s:%d): , file, line);
vfprintf(stderr, fmt, va);
va_end(va);
errno = errsv;
return 1;
}

#define WARN_ON(cond, ...) \
((cond) ? warn(__FILE__, __LINE__, __VA_ARGS__) : 0)

struct setup {
char module[32];
uint32_t conId;
uint32_t crtId;
char modestr[32];
char video[32];
unsigned int w, h;
unsigned int use_wh : 1;
unsigned int in_fourcc;
unsigned int out_fourcc;
unsigned int buffer_count;
unsigned int use_crop : 1;
unsigned int use_compose : 1;
struct v4l2_rect crop;
struct v4l2_rect compose;
};

struct buffer {
unsigned int bo_handle;
unsigned int fb_handle;
int dbuf_fd;
};

struct stream {
int v4lfd;
int current_buffer;
int buffer_count;
struct buffer *buffer;
} stream;

static void usage(char *name)
{
fprintf(stderr, usage: %s [-Moisth]\n, name);
fprintf(stderr, \t-M drm-module\tset DRM module\n);
fprintf(stderr, \t-o connector_id:crtc_id:mode\tset a mode\n);
fprintf(stderr, \t-i video-node\tset video node like /dev/video*\n);
fprintf(stderr, \t-S width,height\tset input resolution\n);
fprintf(stderr, \t-f fourcc\tset input format using 4cc\n);
fprintf(stderr, \t-F fourcc\tset output format using 4cc\n);
fprintf(stderr, \t-s width,height@left,top\tset crop area\n);
fprintf(stderr, \t-t width,height@left,top\tset compose area\n);
fprintf(stderr, \t-b buffer_count\tset number of buffers\n);
fprintf(stderr, \t-h\tshow this help\n);
fprintf(stderr, \n\tDefault is to dump all info.\n);
}

static inline int parse_rect(char *s, struct v4l2_rect *r)
{
return sscanf(s, %d,%d@%d,%d, r-width, r-height,
r-top, r-left) != 4;
}

static int parse_args(int argc, char *argv[], struct setup *s)
{
if (argc = 1)
usage(argv[0]);

int c, ret;
memset(s, 0, sizeof(*s));

while ((c = getopt(argc, argv, M:o:i:S:f:F:s:t:b:h)) != -1) {
switch (c) {
case 'M':
strncpy(s-module, optarg, 31);
break;
case 'o':
ret = sscanf(optarg, %u:%u:%31s, s-conId, s-crtId,
s-modestr);
if (WARN_ON(ret != 3, incorrect mode description\n))
return -1;

Re: [PATCH] omap2+: add drm device

[Rob Clark]

On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
 On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:

  Can there be more than one omapdrm device? I guess not. If so, the id
  should be -1.

 in the past, we have used multiple devices (using the platform-data to
 divide up the dss resources), although this was sort of a
 special-case.  But in theory you could have multiple.  (Think of a
 multi-seat scenario, where multiple compositors need to run and each
 need to be drm-master of their own device to do mode-setting on their
 corresponding display.)

 I think if we use .id = -1, then we'd end up with a funny looking
 bus-id for the device: platform:omapdrm:-1

 I don't know about that, but it's the way platform devices are meant to
 be used if there can be only one instance. If the case where there are
 multiple omapdrm devices is rather theoretical, or only used for certain
 debugging scenarios or such, I think having the id as -1 in the mainline
 is cleaner.

well, I don't care much one way or another, but need to check if there
is a small patch needed in drm core code that generates the bus-id for
.id = -1..

  +};
  +
  +static int __init omap_init_gpu(void)
  +{
  +     struct omap_hwmod *oh = NULL;
  +     struct platform_device *pdev;
  +
  +     /* lookup and populate the DMM information, if present - OMAP4+ */
  +     oh = omap_hwmod_lookup(dmm);
  +
  +     if (oh) {
  +             pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
  +                                     false);
  +             WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
  +                     oh-name);
  +     }
  +
  +     return platform_device_register(omap_drm_device);
  +
  +}
 
  The function is called omap_init_gpu(), but it doesn't do anything
  related to the gpu... And aren't DMM and DRM totally separate things,
  why are they bunched together like that?

 only legacy.. product branches also have sgx initialization here.  But
 I can change that to omap_init_drm()

 DMM is managed by the drm driver (and exposed to userspace as drm/gem
 buffers, shared with other devices via dma-buf, etc).  It is only
 split out to a separate device to play along with hwmod.

 I have to say I don't know much about DMM, but my understanding is that
 DMM is a bigger entity, of which TILER is only a small part, and DMM
 manages all memory accesses.

when most people refer to TILER they actually refer to DMM..

DMM is the piece which is basically a GART, it is what omapdrm is
programming and managing.

 Can there be other users for the DMM than DRM? I know there could be
 other users for the TILER, and I know you want to combine that with the
 DRM driver, but I'm wondering about the other parts of DMM than the
 TILER.

yes, clearly there are other users.. we pass gem buffers allocated
from omapdrm to (for example, video decoder).  But it is omapdrm which
is managing the allocation, keeping track of which buffers are pinned
and which can be evicted, dealing with the complications of userspace
mmap'ing of tiled buffers, etc.  That stuff you don't want littered
throughout the kernel.

 Somehow having a DMM driver inside omapdrm sounds strange.

  +arch_initcall(omap_init_gpu);
  +
  +void omapdrm_reserve_vram(void)
  +{
  +#ifdef CONFIG_CMA
  +     /*
  +      * Create private 32MiB contiguous memory area for omapdrm.0 device
  +      * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
  +      * then the amount of memory we need goes up..
  +      */
  +     dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
 
  What does this actually do? Does it reserve the memory, i.e. it's not
  usable for others? If so, shouldn't there be a way for the user to
  configure it?

 It can be re-used by others.. see http://lwn.net/Articles/479297/

 The link didn't tell much. I looked at the patches, and
 dma_declare_contiguous allocates the memory with memblock_alloc. So is
 that allocated memory available for any users? If so, why does the
 function want a device pointer as an argument...

 Is the memory available for normal kmalloc, or only available via the
 CMA functions? Surely there must be some downside to the above? =) And
 if so, it should be configurable. You could have a board with no display
 at all, and you probably don't want to have 32MB allocated for DRM in
 that case.

Basically the short version is memory from a CMA carveout can be
re-used for unpinnable memory.  Not kmalloc, but it can be used for
anon userspace pages, for example.  Userspace needs memory too.

BR,
-R

  Tomi


 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH] omap2+: add drm device

[Gross, Andy]

On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.comwrote:


 I have to say I don't know much about DMM, but my understanding is that
 DMM is a bigger entity, of which TILER is only a small part, and DMM
 manages all memory accesses.

 Can there be other users for the DMM than DRM? I know there could be
 other users for the TILER, and I know you want to combine that with the
 DRM driver, but I'm wondering about the other parts of DMM than the
 TILER.

 Somehow having a DMM driver inside omapdrm sounds strange.


The DMM does indeed contain a number of entities.  However, the TILER
portion is the only part that requires a driver.  All other register
modifications (LISA map settings, EMIF, etc) are done statically in the
loader or u-boot and never changed again.  As such, DMM has become
synonymous with TILER.

Regards,

Andy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 47007] New: HDMI monitor polling causing 100ms rendering stalls

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

 Bug #: 47007
   Summary: HDMI monitor polling causing 100ms rendering stalls
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: tvrtko.ursu...@onelan.co.uk


I am experiencing rendering stalls every ten seconds (drm_kms_helper output
connector poll interval) on a AMD G-T56N (Radeon HD 6310) box connected to the
monitor via HDMI connector.

Kernel is kernel.org's 3.3.0-rc6 kernel.

I've delved into the code a bit, sprayed some printks around, and found that
the culprit is the drm_get_edid call from radeon_dvi_detect where the former
takes more than 100ms. I suspect I2C transfers there are disabling interrupts
because I don't see any locks other than drm_device mode mutex being help at
that at least sounds harmless.

This function (radeon_dvi_detect) is a bit advanced for a newcomer in this
area, but, looking at the accompanying comment and the code, I am not sure it
could not be improved?

For example if monitor is connected, and we know it is a digital monitor, do we
need to discard and re-fetch complete EDID every time? Couldn't we just do a
quick probe to check for disconnection instead?

This is if I understand correctly that EDID probing must be done for
disconnection check?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

--- Comment #1 from Alex Deucher ag...@yahoo.com 2012-03-06 07:56:58 PST ---
Please attach your xorg log and dmesg output.  Unless the OEM forgot to wire up
the hotplug pin, the driver shouldn't be polling.  Check to make sure your
desktop environment is not manually polling (gnome power manager or the kde
equivalent, etc.).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

--- Comment #2 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-06 
08:11:28 PST ---
Created attachment 58063
  -- https://bugs.freedesktop.org/attachment.cgi?id=58063
DRM related kernel messages

With my debug I have a problem with the kernel log buffer filling to quickly.
Is this DRM related subset of dmesg sufficient or you want me to collect
something more?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

--- Comment #3 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-06 
08:12:04 PST ---
Created attachment 58064
  -- https://bugs.freedesktop.org/attachment.cgi?id=58064
Xorg.log, as the name says.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

--- Comment #4 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-06 
08:13:20 PST ---

(In reply to comment #1)
 Please attach your xorg log and dmesg output.  Unless the OEM forgot to wire 
 up

Attached.

 the hotplug pin, the driver shouldn't be polling.  Check to make sure your
 desktop environment is not manually polling (gnome power manager or the kde
 equivalent, etc.).

There is no desktop environment running. What would this polling be in terms of
X calls?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

--- Comment #5 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-06 
08:15:32 PST ---
(In reply to comment #1)
 Please attach your xorg log and dmesg output.  Unless the OEM forgot to wire 
 up
 the hotplug pin, the driver shouldn't be polling.  Check to make sure your
 desktop environment is not manually polling (gnome power manager or the kde
 equivalent, etc.).

Also, there are no stalls when the VGA output is used (HDMI disconnected).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: cope with platformdev-id == -1

[Rob Clark]

From: Rob Clark r...@ti.com

If there are not multiple instances of a platform device, the id
should apparently be set to -1.  Which results in a odd looking
bus-id like platform:foodrm:-1.  Probably we should just treat
this case as id 0.

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/gpu/drm/drm_platform.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index ae9db5e..82431dc 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -122,7 +122,7 @@ static const char *drm_platform_get_name(struct drm_device 
*dev)
 
 static int drm_platform_set_busid(struct drm_device *dev, struct drm_master 
*master)
 {
-   int len, ret;
+   int len, ret, id;
 
master-unique_len = 13 + strlen(dev-platformdev-name);
master-unique_size = master-unique_len;
@@ -131,8 +131,16 @@ static int drm_platform_set_busid(struct drm_device *dev, 
struct drm_master *mas
if (master-unique == NULL)
return -ENOMEM;
 
+   id = dev-platformdev-id;
+
+   /* if only a single instance of the platform device, id will be
+* set to -1.. use 0 instead to avoid a funny looking bus-id:
+*/
+   if (id == -1)
+   id = 0;
+
len = snprintf(master-unique, master-unique_len,
-   platform:%s:%02d, dev-platformdev-name, 
dev-platformdev-id);
+   platform:%s:%02d, dev-platformdev-name, id);
 
if (len  master-unique_len) {
DRM_ERROR(Unique buffer overflowed\n);
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46796] [X800SE] Mouse cursor corruption when switching users

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=46796

--- Comment #6 from Michel Dänzer mic...@daenzer.net 2012-03-06 09:30:19 PST 
---
Created attachment 58066
  -- https://bugs.freedesktop.org/attachment.cgi?id=58066
Verbose test patch

In order to facilitate testing, here's another version of the fix which prints
a message

[drm] Fixing large cursor offset 0x = 0x0800

when the suspected problem would have occurred. So if such a message appears in
dmesg but the cursor is unharmed, we know this is indeed the proper fix.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm: i915 hangcheck/GPU errors

[Randy Dunlap]

Hi,

My Toshiba Portege (Intel Core i5) hangs every few days.
Sometimes I can see no log messages/reasons for it.
Sometimes there are messages about X receiving potentially
fatal signals.

Today's hang appears to have some useful info (maybe).

Mar  6 09:01:45 dragon kernel: [137308.704424] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:01:45 dragon kernel: [137308.704552] [drm] capturing error event; 
look for more information in /debug/dri/0/i915_error_state
Mar  6 09:01:45 dragon kernel: [137308.718950] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16513584 at 16513581, next 16513585)
Mar  6 09:02:13 dragon kernel: [137336.754647] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:02:13 dragon kernel: [137336.754698] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16517081 at 16517078, next 16517082)

...

Mar  6 09:05:44 dragon kernel: [137548.071904] [drm:i915_hangcheck_elapsed] 
*ERROR* Hangcheck timer elapsed... GPU hung
Mar  6 09:05:44 dragon kernel: [137548.071951] [drm:i915_wait_request] *ERROR* 
i915_wait_request returns -11 (awaiting 16550939 at 16550936, next 16550940)
Mar  6 09:05:57 dragon kernel: [137560.924459] X/1399: potentially unexpected 
fatal signal 6.
Mar  6 09:05:57 dragon kernel: [137560.924463] 
Mar  6 09:05:57 dragon kernel: [137560.924466] CPU 1 
Mar  6 09:05:57 dragon kernel: [137560.924468] Modules linked in: usblp 
snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq 
snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 af_packet acpi_cpufreq mperf lp 
ppdev parport_pc parport snd_hda_codec_hdmi snd_hda_codec_realtek uvcvideo 
videobuf2_core videobuf2_vmalloc videobuf2_memops usbhid hid mousedev 
snd_hda_codec arc4 snd_hwdep iwlwifi toshiba_acpi psmouse snd_pcm snd_timer 
sparse_keymap ehci_hcd battery serio_raw mac80211 evdev thermal ac xhci_hcd 
snd_page_alloc wmi power_supply e1000e mei(C) sdhci_pci sdhci mmc_core 
firmware_class cfg80211 rfkill processor sg rtc_cmos loop unix [last unloaded: 
snd_hda_intel]
Mar  6 09:05:57 dragon kernel: [137560.924560] 
Mar  6 09:05:58 dragon kernel: [137560.924564] Pid: 1399, comm: X Tainted: G
 C   3.3.0-rc5 #2 TOSHIBA PORTEGE R835/Portable PC
Mar  6 09:05:58 dragon kernel: [137560.924572] RIP: 0033:[7f57463c7035]  
[7f57463c7035] 0x7f57463c7034
Mar  6 09:05:58 dragon kernel: [137560.924581] RSP: 002b:7fff0ac33758  
EFLAGS: 3206
Mar  6 09:05:58 dragon kernel: [137560.924585] RAX:  RBX: 
 RCX: 
Mar  6 09:05:58 dragon kernel: [137560.924589] RDX: 0006 RSI: 
0577 RDI: 0577
Mar  6 09:05:58 dragon kernel: [137560.924593] RBP: 7fff0ac341a0 R08: 
7f57464ee8e0 R09: 00411e40
Mar  6 09:05:59 dragon kernel: [137560.924597] R10: 0008 R11: 
3206 R12: 0037
Mar  6 09:06:00 dragon kernel: [137560.924600] R13: 7fff0ac33a80 R14: 
004f R15: 0007
Mar  6 09:06:00 dragon kernel: [137560.924604] FS:  7f57487a18a0() 
GS:88014a60() knlGS:
Mar  6 09:06:02 dragon kernel: [137560.924609] CS:  0010 DS:  ES:  CR0: 
80050033
Mar  6 09:06:02 dragon kernel: [137560.924612] CR2: 00418ff0 CR3: 
00013d059000 CR4: 000406e0
Mar  6 09:06:02 dragon kernel: [137560.924616] DR0:  DR1: 
 DR2: 
Mar  6 09:06:02 dragon kernel: [137560.924620] DR3:  DR6: 
0ff0 DR7: 0400
Mar  6 09:06:03 dragon kernel: [137560.924624] Process X (pid: 1399, threadinfo 
88013e9cc000, task 88012412)
Mar  6 09:06:03 dragon kernel: [137560.924627] 
Mar  6 09:06:03 dragon kernel: [137560.924630] Call Trace:

/end


Any ideas/suggestions?



look for more information in /debug/dri/0/i915_error_state

Where is that file?  in debugfs or somewhere else?

thanks,
-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

dma-buf feature tree: working model

[Sumit Semwal]

Hi all,

Since the inclusion of dma-buf buffer sharing framework in 3.3 (thanks
to Dave Airlie primarily), I have been volunteered to be its
maintainer.

Obviously there is a need for some simple rules about the dma-buf
feature tree, so here we are:

- there will be a 'for-next' branch for (N+1), which will open around
-Nrc1, and close about 1-2 weeks before the (N+1)merge opens.

- there will be a 'fixes' branch, which will take fixes after the
for-next pull request is sent upstream.
  - after -rc2, regression fixes only.
  - after -rc4/5, only revert and disable patches. The real fix should
then be targeted at for-next.

- to stop me from pushing useless stuff, I will merge my own patches
only after sufficient review on our mailing lists. If you see me
breaking this rule, please shout out at me _publicly_ at the top of
your voice.


Being a 'first-time-maintainer', I am very willing to learn
on-the-job, though I might still take cover under the
'first-time-maintainer' umbrella [for sometime :)] for any stupid acts
I might commit.


The tree resides at: git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git

At present, the mailing lists are: linux-me...@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-...@lists.linaro.org, in
addition to lkml.

Comments, flames and suggestions highly welcome.

(I have been 'influenced' quite a bit from Daniel Vetter's model for
the drm/i915 -next tree [thank you, DanVet!], but any errors/omissions
are entirely mine.)

Thanks and regards,
~Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm: i915 hangcheck/GPU errors

[Eugeni Dodonov]

On Tue, Mar 6, 2012 at 10:47, Randy Dunlap rdun...@xenotime.net wrote:

 Hi,

 My Toshiba Portege (Intel Core i5) hangs every few days.
 Sometimes I can see no log messages/reasons for it.
 Sometimes there are messages about X receiving potentially
 fatal signals.

 Today's hang appears to have some useful info (maybe).

 Mar  6 09:01:45 dragon kernel: [137308.704424]
 [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
 Mar  6 09:01:45 dragon kernel: [137308.704552] [drm] capturing error
 event; look for more information in /debug/dri/0/i915_error_state
 Mar  6 09:01:45 dragon kernel: [137308.718950] [drm:i915_wait_request]
 *ERROR* i915_wait_request returns -11 (awaiting 16513584 at 16513581, next
 16513585)
 Mar  6 09:02:13 dragon kernel: [137336.754647]
 [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
 Mar  6 09:02:13 dragon kernel: [137336.754698] [drm:i915_wait_request]
 *ERROR* i915_wait_request returns -11 (awaiting 16517081 at 16517078, next
 16517082)


This error state file is in debugfs, usually in /sys/kernel/debug/dri/0/
directory.

Could you please report it into our bugzilla, attaching the files and
information mentioned at
http://intellinuxgraphics.org/how_to_report_bug.html please?

-- 
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46796] [X800SE] Mouse cursor corruption when switching users

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=46796

--- Comment #7 from jonathan jonathan.v...@gmail.com 2012-03-06 19:41:29 PST 
---
This is a bit above my head I think. I got the source for
xserver-xorg-video-ati from the Ubuntu repositories and tried to apply the
patch to it. It looks like a lot of the right files are there, but there's no
radeon_gem.c. The package version is 6.14.99~git20111219.aacbd629-0ubuntu2,
which includes a date that I think indicates that it's not TOO old, however I
cloned the git repository at
git://anongit.freedesktop.org/xorg/driver/xf86-video-ati and had the same
problem. I've also never tested a kernel mod so I'm not sure what I would do if
I got the patch to compile.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=45018

--- Comment #39 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-03-06 
22:25:26 PST ---
(In reply to comment #38)
 Some news: today, I updated xserver and it seems I'm now able to boot under
 Gnome-Shell correctly.
 
 However, launching RenderFeatTest.bin64 still hangs exactly where it has been
 hanging for some time now and freeze my window manager. At least, it seems one
 of the problem was related to xserver.
 
 I'll hope I'll be able to find something new in the logs.

After one testing day, it happened again. It's just not happening at start as
it was doing, but more randomly. Too bad.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel