[drm] WARNING: at kernel/workqueue.c:1432 __queue_delayed_work()

[Fengguang Wu]

Greetings,

I got the below warning and the first bad commit is

commit be37835619fce22d3f46c5a591bbf0bbcb2288e4
Author: Daniel Vetter 
Date:   Thu Jun 6 00:17:25 2013 +0200

drm: kms_helper: don't lose hotplug event

There's a race window (small for hpd, 10s large for polled outputs)
where userspace could sneak in with an unrelated connnector probe
ioctl call and eat the hotplug event (since neither the hpd nor the
poll code see a state change).

To avoid this, check whether the connector state changes in all other
->detect calls (in the current helper code that's only probe_single)
and if that's the case, fire off a hotplug event. Note that we can't
directly call the hotplug event handler, since that expects that no
locks are held (due to reentrancy with the fb code to update the kms
console).

Also, this requires that drivers using the probe_single helper
function set up the poll work. All current drivers do that already,
and with the reworked hpd handling there'll be no downside to
unconditionally setting up the poll work any more.

Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie 

[3.829957] [TTM] Initializing pool allocator
[3.830706] [ cut here ]
[3.831240] WARNING: at /c/kernel-tests/src/linux/kernel/workqueue.c:1432 
__queue_delayed_work+0x81/0x247()
[3.832303] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
3.10.0-rc7-wl-01596-gb53e037 #1
[3.833158]    85429d24 798531bf 85429d3c 7906c42f 790831cf 
0201
[3.834185]  0001 7ea3ec14 85429d4c 7906c4d7 0009  85429d70 
790831cf
[3.835827]  8542b770 7ea3ec34 0020 0001 0246  0020 
85429d90
[3.836829] Call Trace:
[3.837115]  [<798531bf>] dump_stack+0x16/0x18
[3.837597]  [<7906c42f>] warn_slowpath_common+0x48/0x5f
[3.838154]  [<790831cf>] ? __queue_delayed_work+0x81/0x247
[3.838740]  [<7906c4d7>] warn_slowpath_null+0x14/0x18
[3.839278]  [<790831cf>] __queue_delayed_work+0x81/0x247
[3.839849]  [<79084358>] queue_delayed_work_on+0x42/0x59
[3.840437]  [<792d944c>] schedule_delayed_work+0x16/0x18
[3.840453]  [<792da72b>] drm_helper_probe_single_connector_modes+0xf5/0x2be
[3.840453]  [<792d7821>] drm_fb_helper_probe_connector_modes+0x3a/0x4e
[3.840453]  [<792d8fdc>] drm_fb_helper_initial_config+0x14d/0x3ae
[3.840453]  [<79110996>] ? __kmalloc_node+0x6a/0xd6
[3.840453]  [<792d9641>] ? drm_helper_disable_unused_functions+0xc3/0xdc
[3.840453]  [<7934cd7c>] cirrus_fbdev_init+0x7c/0x8d
[3.840453]  [<7934c623>] cirrus_modeset_init+0x145/0x186
[3.840453]  [<7934b925>] cirrus_driver_load+0x88/0xce
[3.840453]  [<792e4321>] drm_get_pci_dev+0x136/0x214
[3.840453]  [<7934c724>] cirrus_pci_probe+0x85/0x91
[3.840453]  [<791fbcfa>] pci_device_probe+0x5c/0x94
[3.840453]  [<793e4586>] driver_probe_device+0x97/0x1b1
[3.840453]  [<793e4724>] __driver_attach+0x53/0x6f
[3.840453]  [<793e31d4>] bus_for_each_dev+0x3e/0x69
[3.840453]  [<793e44a6>] driver_attach+0x19/0x1b
[3.840453]  [<793e46d1>] ? __device_attach+0x31/0x31
[3.840453]  [<793e382e>] bus_add_driver+0xb4/0x1bd
[3.840453]  [<793e4ef3>] driver_register+0x8c/0xe9
[3.840453]  [<791fbb2d>] __pci_register_driver+0x4a/0x4d
[3.840453]  [<792e4470>] drm_pci_init+0x71/0xc9
[3.840453]  [<79df7f16>] ? 
ftrace_define_fields_intel_gpu_freq_change+0x1c/0x1c
[3.840453]  [<79df7f31>] cirrus_init+0x1b/0x25
[3.840453]  [<79dcaa28>] do_one_initcall+0x6b/0x119
[3.840453]  [<79dcabc7>] kernel_init_freeable+0xf1/0x171
[3.840453]  [<7984161e>] kernel_init+0xd/0xb9
[3.840453]  [<79860cf7>] ret_from_kernel_thread+0x1b/0x28
[3.840453]  [<79841611>] ? rest_init+0xb1/0xb1
[3.840453] ---[ end trace 4a7136f8b8f4ca4a ]---

git bisect start b53e037930134d11fa6307162b41fb19b6c43643 
9e895ace5d82df8929b16f58e9f515f6d54ab82d --
git bisect  bad 3ef6fb0acbf846ec267c86b4b7841ca7cc1fd636  # 09:34  0-  
Merge remote-tracking branch 'vireshk/cpufreq-fix-notification' into 
devel-snb-i386-201306280352
git bisect  bad e26e8115c78ca2f7e104ad085343e37c544033ae  # 09:51  0-  alx 
builtin HACK
git bisect good 40ccc72b84a848e6fcbdb38fe716f0ac6939609e  # 12:39 20+  
drm/i915: release cursor when crtc is destroyed
git bisect good d5cfba1b9ce6f1f4add8f3c67fde5243e5549bbd  # 12:45 20+  
drm/ast: do not attempt to acquire a reservation while in an interrupt handler
git bisect  bad 395ba7ac59ac1aa4bb07c21e3211c2af04719f0a  # 12:50  0-  
drm/ttm: get rid of ttm_bo_is_reserved
git bisect good 1e876e3b1a9df25bb04682b0d48aaa7e8ae1fc82  # 12:55 20+  
Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
git bisect  bad 1fb4883ad4ae880d2ef100f00624ec7660018186  # 12:59  0-  
reservation: cross-device reservation support, v4
git bisect good 

drm-next status (or: drm-openchrome will not be in 3.11)

[James Simmons]

> Am Freitag, 28. Juni 2013, 13:31:50 schrieb Dave Airlie:
> > Okay drm-next is pretty big, possibly the biggest ever.
> > 
> > Outstanding things I know about, and will merge, if they arrive soon:
> > exynos -next
> > nouveau -next
> > 
> > Big things I've merged:
> > new rcar driver
> > intel next
> > radeon next
> > tegra next
> > shmob next
> > core/mutexes
> > ttm -> reservation conversion
> > tilcdc patches acked by Rob
> > mtrr reworking
> > prime + gem patches from samsung
> > Laurent's documentation updates
> > various mgag200 patches
> > 
> > Otherwise I'm sure I've missed some changes, please let me know of
> > anything you think has fallen down the cracks asap.
> > 
> > Slow down people :-P
> > 
> > Dave.
> 
> IRC #dri-devel:
> 
>  airlied: drm-openchrome will not be part of Kernel 3.11 because 
> jsimmons has not responded?
> 
>  jobermayr: seems likely, I don't merge just because someone posts 
> patchrs
> 
> 
> Tasks to do:
> http://lists.freedesktop.org/archives/dri-devel/2013-June/039695.html
> http://lists.freedesktop.org/archives/dri-devel/2013-June/039796.html

The VIA driver is pretty huge. Its going to take time to merge it. Plus 
I'm the new guy so I don't have the level of trust the other maintainers
have.

[Openchrome-devel] [RFC 1/21] Add VIA DRM driver

[James Simmons]

> > commit 1fcf23d361375645d586756d126b436796ba4fba
> > Author: James Simmons 
> > Date:   Sat Jun 8 09:31:57 2013 -0400
> >
> > via: New KMS ioctls and hardware to support.
> >
> > Add new VIA pci ids to support newer hardware. Cleanup userspace
> > api structs to remove kernel types and add the new KMS ioctls we
> > will be supporting.
> 
> why remove all the __u32? seems to just undo
> 1d7f83d5ad6c30b385ba549c1c3a287cc872b7ae
> 
> and definitely shouldn't be in this patch.

Attempting to sync my userland header in xorg with what is used in the 
kernel. Since we have BSD users I attempted to play nice. This weekend
I played with a new header format that should satisfy everyone.

> Also I don't think its really necessary to add all the pci ids there,
> just put them in the driver.

Would you be okay with the pci ids being in via_drm.h instead? I have to 
look but if I remember correctly some of those pci ids are for the north 
bridge bus which is used to detect how much VRAM we have.

> >
> >  #define DRM_IOCTL_VIA_ALLOCMEM   DRM_IOWR(DRM_COMMAND_BASE + 
> > DRM_VIA_ALLOCMEM, drm_via_mem_t)
> >  #define DRM_IOCTL_VIA_FREEMEMDRM_IOW( DRM_COMMAND_BASE + 
> > DRM_VIA_FREEMEM, drm_via_mem_t)
> > @@ -86,6 +89,7 @@
> >  #define DRM_IOCTL_VIA_FB_INITDRM_IOWR(DRM_COMMAND_BASE + 
> > DRM_VIA_FB_INIT, drm_via_fb_t)
> >  #define DRM_IOCTL_VIA_MAP_INIT   DRM_IOWR(DRM_COMMAND_BASE + 
> > DRM_VIA_MAP_INIT, drm_via_init_t)
> >  #define DRM_IOCTL_VIA_DEC_FUTEX   DRM_IOW( DRM_COMMAND_BASE + 
> > DRM_VIA_DEC_FUTEX, drm_via_futex_t)
> > +#define DRM_IOCTL_VIA_OLD_GEM_CREATE  DRM_IOWR(DRM_COMMAND_BASE + 
> > DRM_VIA_OLD_GEM_CREATE, struct drm_via_gem_create)
> >  #define DRM_IOCTL_VIA_DMA_INIT   DRM_IOWR(DRM_COMMAND_BASE + 
> > DRM_VIA_DMA_INIT, drm_via_dma_init_t)
> >  #define DRM_IOCTL_VIA_CMDBUFFER  DRM_IOW( DRM_COMMAND_BASE + 
> > DRM_VIA_CMDBUFFER, drm_via_cmdbuffer_t)
> >  #define DRM_IOCTL_VIA_FLUSH  DRM_IO(  DRM_COMMAND_BASE + DRM_VIA_FLUSH)
> > @@ -96,6 +100,13 @@
> >  #define DRM_IOCTL_VIA_DMA_BLITDRM_IOW(DRM_COMMAND_BASE + 
> > DRM_VIA_DMA_BLIT, drm_via_dmablit_t)
> >  #define DRM_IOCTL_VIA_BLIT_SYNC   DRM_IOW(DRM_COMMAND_BASE + 
> > DRM_VIA_BLIT_SYNC, drm_via_blitsync_t)
> >
> > +/* KMS ioctls */
> > +#define DRM_IOCTL_VIA_GETPARAMDRM_IOR(DRM_COMMAND_BASE + 
> > DRM_VIA_GETPARAM, struct drm_via_param)
> > +#define DRM_IOCTL_VIA_SETPARAMDRM_IOW(DRM_COMMAND_BASE + 
> > DRM_VIA_SETPARAM, struct drm_via_param)
> > +#define DRM_IOCTL_VIA_GEM_CREATE  DRM_IOWR(DRM_COMMAND_BASE + 
> > DRM_VIA_GEM_CREATE, struct drm_via_gem_create)
> > +#define DRM_IOCTL_VIA_GEM_WAITDRM_IOW(DRM_COMMAND_BASE + 
> > DRM_VIA_GEM_WAIT, struct drm_via_gem_wait)
> > +#define DRM_IOCTL_VIA_GEM_STATE   DRM_IOWR(DRM_COMMAND_BASE + 
> > DRM_VIA_GEM_STATE, struct drm_via_gem_create)
> 
> why does gem_state take a gem_create struct? is it the same info it returns?

Yes that same info is returned. Prehaps struct drm_via_gem_create is a 
poor name. Maybe struct drm_via_gem_object ?

> >  typedef struct drm_via_dmablit {
> > -   __u32 num_lines;
> > -   __u32 line_length;
> > +   uint32_t num_lines;
> > +   uint32_t line_length;
> >
> > -   __u32 fb_addr;
> > -   __u32 fb_stride;
> > +   uint32_t fb_addr;
> > +   uint32_t fb_stride;
> >
> > unsigned char *mem_addr;
> > -   __u32 mem_stride;
> > +   uint32_t  mem_stride;
> >
> > -   __u32 flags;
> > +   int bounce_buffer;
> 
> ^ totally wtf here? no explains.

Leftovers from older work that doesn't exist anymore. My bad.

> > int to_fb;
> >
> > drm_via_blitsync_t sync;
> >  } drm_via_dmablit_t;
> >
> > -struct via_file_private {
> > -   struct list_head obj_list;
> > +/* Ioctl to query kernel params:
> > + */
> > +#define VIA_PARAM_CHIPSET_ID   0
> > +#define VIA_PARAM_REVISION_ID  1
> > +
> > +struct drm_via_param {
> > +   uint64_t param;
> > +   uint64_t value;
> > +};
> > +
> > +struct drm_via_gem_create {
> > +   /**
> > +* Requested size for the object.
> > +*
> > +* The (page-aligned) allocated size for the object will be 
> > returned.
> > +*/
> > +   uint64_t size;
> > +
> > +   /*
> > +* Place the memory at the proper byte alignment.
> > +*/
> > +   uint32_t alignment;
> > +
> > +   /**
> > +* Format of data i.e tile pitch, for linear it is zero
> > +*/
> > +   uint32_t pitch;
> > +
> > +   /**
> > +* Give hints where to allocate this object.
> > +*/
> > +   uint32_t domains;
> > +
> > +   /**
> > +* chmod values applied to a buffer.
> > +*/
> > +   uint32_t mode_t;
> > +
> > +   /**
> > +* Offset to start of memory region.
> > +*/
> > +   uint64_t offset;
> > +
> > +   /**
> > +* Returned handle need to mmap the buffer.
> > +*/
> > +   uint64_t map_handle;
> > +

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Daniel Vetter]

On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux
 wrote:
> On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote:
>> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
>> > +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
>> > +{
>> > +   struct drm_display_mode *adj = >crtc.mode;
>> > +   uint32_t val = 0;
>> > +
>> > +   if (dcrtc->csc_yuv_mode == CSC_YUV_CCIR709)
>> > +   val |= CFG_CSC_YUV_CCIR709;
>> > +   if (dcrtc->csc_rgb_mode == CSC_RGB_STUDIO)
>> > +   val |= CFG_CSC_RGB_STUDIO;
>> > +
>> > +   /*
>> > +* In auto mode, set the colorimetry, based upon the HDMI spec.
>> > +* 1280x720p, 1920x1080p and 1920x1080i use ITU709, others use
>> > +* ITU601.  It may be more appropriate to set this depending on
>> > +* the source - but what if the graphic frame is YUV and the
>> > +* video frame is RGB?
>> > +*/
>> > +   if ((adj->hdisplay == 1280 && adj->vdisplay == 720 &&
>> > +!(adj->flags & DRM_MODE_FLAG_INTERLACE)) ||
>> > +   (adj->hdisplay == 1920 && adj->vdisplay == 1080)) {
>> > +   if (dcrtc->csc_yuv_mode == CSC_AUTO)
>> > +   val |= CFG_CSC_YUV_CCIR709;
>> > +   }
>> > +
>> > +   /*
>> > +* We assume we're connected to a TV-like device, so the YUV->RGB
>> > +* conversion should produce a limited range.  We should set this
>> > +* depending on the connectors attached to this CRTC, and what
>> > +* kind of device they report being connected.
>> > +*/
>> > +   if (dcrtc->csc_rgb_mode == CSC_AUTO)
>> > +   val |= CFG_CSC_RGB_STUDIO;
>>
>> In the intel driver we check whether it's an cea mode with
>> drm_match_cea_mode, e.g. in intel_hdmi.c:
>>
>>   if (intel_hdmi->color_range_auto) {
>>   /* See CEA-861-E - 5.1 Default Encoding Parameters */
>>   if (intel_hdmi->has_hdmi_sink &&
>>   drm_match_cea_mode(adjusted_mode) > 1)
>>   intel_hdmi->color_range = HDMI_COLOR_RANGE_16_235;
>>   else
>>   intel_hdmi->color_range = 0;
>>   }
>>
>> (The color_range gets then propageted to the right place since different
>> platforms have different ways to do that in intel hw).
>
> Unfortunately, this disagrees with the HDMI v1.3a specification:
>
> | Default Colorimetry
> |
> | ...
> |
> | 480p, 480i, 576p, 576i, 240p and 288p
> |
> | The default colorimetry for all 480-line, 576-line, 240-line, and 288-line
> | video formats described in CEA-861-D is based on SMPTE 170M.
> |
> | 1080i, 1080p and 720p
> |
> | The default colorimetry for high-definition video formats (1080i, 1080p and
> | 720p) described in CEA-861-D is based on ITU-R BT.709-5.
>
> As the HDMI spec refers to the CEA-861 specs, the HDMI spec overrides
> CEA when dealing with HDMI specifics.
>
> So, according to the HDMI specification, the default is that it's only
> 1080i, 1080p and 720p which are 709, the others are 601.  This does not
> correspond with "drm_match_cea_mode(adjusted_mode) > 1".

Hm, sounds like we need to improve stuff a bit, maybe add a common cea
helper to the drm core with a bool is_hdmi to decide whether it's
palin CEA or HDMI-CEA. Ville (who's written the current code and the
match cea mode helper) can you please take a look?

> Unfortunately, given DRM's structure, there's no way for the CRTC layer
> to really know what its driving, and this setting is at the CRTC layer,
> not the output layer.  It may be that you have the CRTC duplicated
> between two different display devices with different characteristics,
> which means you have to "choose" one - or just not bother.  I've chosen
> the latter because it's a simpler solution, and is in no way any more
> correct than any other solution.
>
> This is also why these are exported to userspace via properties, so if
> userspace knows better, it can deal with those issues.

Yeah, allowing userspace to overwrite the default selection makes lots
of sense, we expose similar properties.

>> > +struct armada_framebuffer *armada_framebuffer_create(struct drm_device 
>> > *dev,
>> > +   struct drm_mode_fb_cmd2 *mode, struct armada_gem_object *obj)
>> > +{
>> > +   struct armada_framebuffer *dfb;
>> > +   uint8_t format, config;
>> > +   int ret;
>> > +
>> > +   switch (mode->pixel_format) {
>> > +#define FMT(drm, fmt, mod) \
>> > +   case DRM_FORMAT_##drm:  \
>> > +   format = CFG_##fmt; \
>> > +   config = mod;   \
>> > +   break
>> > +   FMT(RGB565, 565,CFG_SWAPRB);
>> > +   FMT(BGR565, 565,0);
>> > +   FMT(ARGB1555,   1555,   CFG_SWAPRB);
>> > +   FMT(ABGR1555,   1555,   0);
>> > +   FMT(RGB888, 888PACK,CFG_SWAPRB);
>> > +   FMT(BGR888, 888PACK,0);
>> > +   FMT(XRGB,   X888,   CFG_SWAPRB);
>> > +   FMT(XBGR,   X888,   0);
>> > +   FMT(ARGB,   ,   CFG_SWAPRB);
>> > +   

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Daniel Vetter]

On Sun, Jun 30, 2013 at 3:41 PM, Russell King - ARM Linux
 wrote:
> On Sun, Jun 30, 2013 at 02:04:56PM +0100, Russell King - ARM Linux wrote:
>> On Sun, Jun 30, 2013 at 02:37:41PM +0200, Daniel Vetter wrote:
>> > On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
>> > > + mutex_lock(>struct_mutex);
>> > > + free = drm_mm_search_free(>linear, size, align, 0);
>> > > + if (free)
>> > > + obj->linear = drm_mm_get_block(free, size, align);
>> > > + mutex_unlock(>struct_mutex);
>> >
>> > The two-stage search_free+get_block drm_mm interface is something I'd like
>> > to remove since it' complicates the interface for no gain. And the
>> > preallocation trick for atomic contexts is pretty racy as-is. Can you
>> > please convert this over to the insert_node interfaces which take a
>> > preallocate drm_mm_node?
>>
>> Yes and no.  This is only racy if it is callable from atomic contexts,
>> which the above isn't, because it takes a mutex, and the above is the
>> only place which allocations against that pool are done.  Mutexes can't
>> be taken in atomic contexts.  Plus it's using the non-atomic drm_mm_*
>> interfaces.
>>
>> However, the insert_node interfaces appear not to solve any kind of race.
>> All they do is allow the kmalloc to be moved out of this region into
>> the user of this code sequence, while offering no additional locking or
>> safety.  So the mutex lock around a call to drm_mm_insert_node*() is
>> still required.
>>
>> As the kmalloc() happens beneath the mutex lock, another thread can't race
>> with an allocation in the above code anyway.  The *only* reason I'll change
>> this is that it is nicer to the system not to hold locks while allocating
>> memory.
>
> Err.  There's bugs here in the other drivers such as i915 which follow
> your suggestion.  The problem is this:
>
> Every time they allocate using drm_mm_insert_node(), they kmalloc a new
> struct drm_mm_node for this function to fill in and attach.
>
> When they've done with the allocation, they call drm_mm_put_block().
> This places the node onto the mm's unused_nodes list provided we don't
> already have MM_UNUSED_TARGET nodes on that list.

Yeah, for drivers that never use the atomic alloc stuff it's pointless
waste of memory.

> So, we end up filling up the unused nodes list to MM_UNUSED_TARGET,
> at which point we then start freeing any further nodes - and with no
> way to pull these off that list, they all just sit there not being
> used.
>
> The only function which takes nodes off that list is drm_mm_kmalloc(),
> which is declared statically, and so isn't available to drivers.
>
> Are drivers which use the drm_mm_insert_node() function expected to
> also use drm_mm_remove_node(), kfreeing the node after that call,
> rather than using drm_mm_put_block() ?

Yeah, with the insert_node interface deallocing the node is the
driver's responsibility.

> Either way, I think someone needs to fix the other drivers and Cc those
> patches to Stable...

Yeah, I think it's time that I move that item up my todo list a lot.
And also add some decent kerneldoc to the drm_mm stuff.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

drm-next status (or: drm-openchrome will not be in 3.11)

[Johannes Obermayr]

Am Freitag, 28. Juni 2013, 13:31:50 schrieb Dave Airlie:
> Okay drm-next is pretty big, possibly the biggest ever.
> 
> Outstanding things I know about, and will merge, if they arrive soon:
> exynos -next
> nouveau -next
> 
> Big things I've merged:
> new rcar driver
> intel next
> radeon next
> tegra next
> shmob next
> core/mutexes
> ttm -> reservation conversion
> tilcdc patches acked by Rob
> mtrr reworking
> prime + gem patches from samsung
> Laurent's documentation updates
> various mgag200 patches
> 
> Otherwise I'm sure I've missed some changes, please let me know of
> anything you think has fallen down the cracks asap.
> 
> Slow down people :-P
> 
> Dave.

IRC #dri-devel:

 airlied: drm-openchrome will not be part of Kernel 3.11 because 
jsimmons has not responded?

 jobermayr: seems likely, I don't merge just because someone posts 
patchrs


Tasks to do:
http://lists.freedesktop.org/archives/dri-devel/2013-June/039695.html
http://lists.freedesktop.org/archives/dri-devel/2013-June/039796.html

drm-next status (or: drm-openchrome will not be in 3.11)

[Konrad Rzeszutek Wilk]

James Simmons  wrote:

>
>> Am Freitag, 28. Juni 2013, 13:31:50 schrieb Dave Airlie:
>> > Okay drm-next is pretty big, possibly the biggest ever.
>> > 
>> > Outstanding things I know about, and will merge, if they arrive
>soon:
>> > exynos -next
>> > nouveau -next
>> > 
>> > Big things I've merged:
>> > new rcar driver
>> > intel next
>> > radeon next
>> > tegra next
>> > shmob next
>> > core/mutexes
>> > ttm -> reservation conversion
>> > tilcdc patches acked by Rob
>> > mtrr reworking
>> > prime + gem patches from samsung
>> > Laurent's documentation updates
>> > various mgag200 patches
>> > 
>> > Otherwise I'm sure I've missed some changes, please let me know of
>> > anything you think has fallen down the cracks asap.
>> > 
>> > Slow down people :-P
>> > 
>> > Dave.
>> 
>> IRC #dri-devel:
>> 
>>  airlied: drm-openchrome will not be part of Kernel 3.11
>because 
>> jsimmons has not responded?
>> 
>>  jobermayr: seems likely, I don't merge just because someone
>posts 
>> patchrs
>> 
>> 
>> Tasks to do:
>> http://lists.freedesktop.org/archives/dri-devel/2013-June/039695.html
>> http://lists.freedesktop.org/archives/dri-devel/2013-June/039796.html
>
>The VIA driver is pretty huge. Its going to take time to merge it. Plus
>
>I'm the new guy so I don't have the level of trust the other
>maintainers
>have.
>___
>dri-devel mailing list
>dri-devel at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/dri-devel

Could you repost it with some of the reviewers comments addressed please? 
-- 
Sent from my Android phone. Please excuse my brevity.

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

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

--- Comment #28 from Marek Ol??k  ---
Stefan, is the extension for implementing the POSITIONT shader semantic? Would
a gl_Position output modifier also work for you?

For example:

#extension GL_MESA_xxx : require

pretransformed gl_Position;

void main()
{
...
etc.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130630/15d6ed4b/attachment.html>

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

Right, so, incrementally, the changes are (this may not entirely apply
to the version I've posted because I have several patches on top of
that.)

I've also added locking to the calls to drm_mm_dump_table() as otherwise
these walk those lists without holding any locks what so ever, which
could mean that a block is removed while we're walking the list.

 drivers/gpu/drm/armada/armada_debugfs.c |   17 ++--
 drivers/gpu/drm/armada/armada_fb.c  |   43 ++-
 drivers/gpu/drm/armada/armada_fbdev.c   |   20 ++
 drivers/gpu/drm/armada/armada_gem.c |   29 +++--
 4 files changed, 68 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_debugfs.c 
b/drivers/gpu/drm/armada/armada_debugfs.c
index f42f3ab..60e1038 100644
--- a/drivers/gpu/drm/armada/armada_debugfs.c
+++ b/drivers/gpu/drm/armada/armada_debugfs.c
@@ -23,16 +23,27 @@ static int armada_debugfs_gem_offs_show(struct seq_file *m, 
void *data)
struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct drm_gem_mm *mm = dev->mm_private;
+   int ret;
+
+   mutex_lock(>struct_mutex);
+   ret = drm_mm_dump_table(m, >offset_manager);
+   mutex_unlock(>struct_mutex);

-   return drm_mm_dump_table(m, >offset_manager);
+   return ret;
 }

 static int armada_debugfs_gem_linear_show(struct seq_file *m, void *data)
 {
struct drm_info_node *node = m->private;
-   struct armada_private *priv = node->minor->dev->dev_private;
+   struct drm_device *dev = node->minor->dev;
+   struct armada_private *priv = dev->dev_private;
+   int ret;

-   return drm_mm_dump_table(m, >linear);
+   mutex_lock(>struct_mutex);
+   ret = drm_mm_dump_table(m, >linear);
+   mutex_unlock(>struct_mutex);
+
+   return ret;
 }

 static int armada_debugfs_reg_show(struct seq_file *m, void *data)
diff --git a/drivers/gpu/drm/armada/armada_fb.c 
b/drivers/gpu/drm/armada/armada_fb.c
index 28965e3..97fbd61 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -79,6 +79,9 @@ struct armada_framebuffer *armada_framebuffer_create(struct 
drm_device *dev,

dfb->fmt = format;
dfb->mod = config;
+   dfb->obj = obj;
+
+   drm_helper_mode_fill_fb_struct(>fb, mode);

ret = drm_framebuffer_init(dev, >fb, _fb_funcs);
if (ret) {
@@ -86,14 +89,13 @@ struct armada_framebuffer *armada_framebuffer_create(struct 
drm_device *dev,
return ERR_PTR(ret);
}

-   drm_helper_mode_fill_fb_struct(>fb, mode);
-
/*
-* Take a reference on our object - the caller is expected
-* to drop their reference to it.
+* Take a reference on our object as we're successful - the
+* caller already holds a reference, which keeps us safe for
+* the above call, but the caller will drop their reference
+* to it.  Hence we need to take our own reference.
 */
drm_gem_object_reference(>obj);
-   dfb->obj = obj;

return dfb;
 }
@@ -111,39 +113,44 @@ static struct drm_framebuffer *armada_fb_create(struct 
drm_device *dev,
mode->pitches[2]);

/* We can only handle a single plane at the moment */
-   if (drm_format_num_planes(mode->pixel_format) > 1)
-   return ERR_PTR(-EINVAL);
+   if (drm_format_num_planes(mode->pixel_format) > 1) {
+   ret = -EINVAL;
+   goto err;
+   }

obj = armada_gem_object_lookup(dev, dfile, mode->handles[0]);
if (!obj) {
-   DRM_ERROR("failed to lookup gem object\n");
-   return ERR_PTR(-ENOENT);
+   ret = -ENOENT;
+   goto err;
}

if (obj->obj.import_attach && !obj->sgt) {
ret = armada_gem_map_import(obj);
if (ret)
-   goto unref;
+   goto err_unref;
}

/* Framebuffer objects must have a valid device address for scanout */
if (obj->dev_addr == DMA_ERROR_CODE) {
ret = -EINVAL;
-   goto unref;
+   goto err_unref;
}

dfb = armada_framebuffer_create(dev, mode, obj);
-   ret = IS_ERR(dfb) ? PTR_ERR(dfb) : 0;
+   if (IS_ERR(dfb)) {
+   ret = PTR_ERR(dfb);
+   goto err;
+   }

-unref:
drm_gem_object_unreference_unlocked(>obj);

-   if (ret) {
-   DRM_ERROR("failed to initialize framebuffer: %d\n", ret);
-   return ERR_PTR(ret);
-   }
-
return >fb;
+
+ err_unref:
+   drm_gem_object_unreference_unlocked(>obj);
+ err:
+   DRM_ERROR("failed to initialize framebuffer: %d\n", ret);
+   return ERR_PTR(ret);
 }

 static void armada_output_poll_changed(struct drm_device *dev)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Sun, Jun 30, 2013 at 02:04:56PM +0100, Russell King - ARM Linux wrote:
> On Sun, Jun 30, 2013 at 02:37:41PM +0200, Daniel Vetter wrote:
> > On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> > > + mutex_lock(>struct_mutex);
> > > + free = drm_mm_search_free(>linear, size, align, 0);
> > > + if (free)
> > > + obj->linear = drm_mm_get_block(free, size, align);
> > > + mutex_unlock(>struct_mutex);
> > 
> > The two-stage search_free+get_block drm_mm interface is something I'd like
> > to remove since it' complicates the interface for no gain. And the
> > preallocation trick for atomic contexts is pretty racy as-is. Can you
> > please convert this over to the insert_node interfaces which take a
> > preallocate drm_mm_node?
> 
> Yes and no.  This is only racy if it is callable from atomic contexts,
> which the above isn't, because it takes a mutex, and the above is the
> only place which allocations against that pool are done.  Mutexes can't
> be taken in atomic contexts.  Plus it's using the non-atomic drm_mm_*
> interfaces.
> 
> However, the insert_node interfaces appear not to solve any kind of race.
> All they do is allow the kmalloc to be moved out of this region into
> the user of this code sequence, while offering no additional locking or
> safety.  So the mutex lock around a call to drm_mm_insert_node*() is
> still required.
> 
> As the kmalloc() happens beneath the mutex lock, another thread can't race
> with an allocation in the above code anyway.  The *only* reason I'll change
> this is that it is nicer to the system not to hold locks while allocating
> memory.

Err.  There's bugs here in the other drivers such as i915 which follow
your suggestion.  The problem is this:

Every time they allocate using drm_mm_insert_node(), they kmalloc a new
struct drm_mm_node for this function to fill in and attach.

When they've done with the allocation, they call drm_mm_put_block().
This places the node onto the mm's unused_nodes list provided we don't
already have MM_UNUSED_TARGET nodes on that list.

So, we end up filling up the unused nodes list to MM_UNUSED_TARGET,
at which point we then start freeing any further nodes - and with no
way to pull these off that list, they all just sit there not being
used.

The only function which takes nodes off that list is drm_mm_kmalloc(),
which is declared statically, and so isn't available to drivers.

Are drivers which use the drm_mm_insert_node() function expected to
also use drm_mm_remove_node(), kfreeing the node after that call,
rather than using drm_mm_put_block() ?

Either way, I think someone needs to fix the other drivers and Cc those
patches to Stable...

[Intel-gfx] [PATCH 04/66] drm: Optionally create mm blocks from top-to-bottom

[Daniel Vetter]

On Sun, Jun 30, 2013 at 2:30 PM, Daniel Vetter  wrote:
> On Thu, Jun 27, 2013 at 04:30:05PM -0700, Ben Widawsky wrote:
>> From: Chris Wilson 
>>
>> Clients like i915 needs to segregate cache domains within the GTT which
>> can lead to small amounts of fragmentation. By allocating the uncached
>> buffers from the bottom and the cacheable buffers from the top, we can
>> reduce the amount of wasted space and also optimize allocation of the
>> mappable portion of the GTT to only those buffers that require CPU
>> access through the GTT.
>>
>> v2 by Ben:
>> Update callers in i915_gem_object_bind_to_gtt()
>> Turn search flags and allocation flags into separate enums
>> Make checkpatch happy where logical/easy
>>
>> Signed-off-by: Chris Wilson 
>> Signed-off-by: Ben Widawsky 
>
> Since this is a core drm patch it must be cc'ed to dri-devel (and acked by
> Dave) before I can merge it. Can you please resend?

And same review as for Chris' original patch still applies: best_match
is unused (and it's better that way, really) so can be garbage
collected.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Daniel Vetter]

On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> This patch adds support for the pair of LCD controllers on the Marvell
> Armada 510 SoCs.  This driver supports:
> - multiple contiguous scanout buffers for video and graphics
> - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
>   acceleration
> - dual lcd0 and lcd1 crt operation
> - video overlay on each LCD crt
> - page flipping of the main scanout buffers
> 
> Included in this commit is the core driver with no output support; output
> support is platform and encoder driver dependent.
> 
> Signed-off-by: Russell King 

Found one more ...

[snip]

> +int
> +armada_gem_linear_back(struct drm_device *dev, struct armada_gem_object *obj)
> +{
> + struct armada_private *priv = dev->dev_private;
> + size_t size = obj->obj.size;
> +
> + if (obj->page || obj->linear)
> + return 0;
> +
> + /*
> +  * If it is a small allocation (typically cursor, which will
> +  * be 32x64 or 64x32 ARGB pixels) try to get it from the system.
> +  * Framebuffers will never be this small (our minimum size for
> +  * framebuffers is larger than this anyway.)  Such objects are
> +  * only accessed by the CPU so we don't need any special handing
> +  * here.
> +  */
> + if (size <= 8192) {
> + unsigned int order = get_order(size);
> + struct page *p = alloc_pages(GFP_KERNEL, order);
> +
> + if (p) {
> + obj->addr = page_address(p);
> + obj->phys_addr = page_to_phys(p);
> + obj->page = p;
> +
> + memset(obj->addr, 0, PAGE_ALIGN(size));
> + }
> + }
> +
> + /*
> +  * We could grab something from CMA if it's enabled, but that
> +  * involves building in a problem:
> +  *
> +  * CMA's interface uses dma_alloc_coherent(), which provides us
> +  * with an CPU virtual address and a device address.
> +  *
> +  * The CPU virtual address may be either an address in the kernel
> +  * direct mapped region (for example, as it would be on x86) or
> +  * it may be remapped into another part of kernel memory space
> +  * (eg, as it would be on ARM.)  This means virt_to_phys() on the
> +  * returned virtual address is invalid depending on the architecture
> +  * implementation.
> +  *
> +  * The device address may also not be a physical address; it may
> +  * be that there is some kind of remapping between the device and
> +  * system RAM, which makes the use of the device address also
> +  * unsafe to re-use as a physical address.
> +  *
> +  * This makes DRM usage of dma_alloc_coherent() in a generic way
> +  * at best very questionable and unsafe.
> +  */
> +
> + /* Otherwise, grab it from our linear allocation */
> + if (!obj->page) {
> + struct drm_mm_node *free;
> + unsigned align = min_t(unsigned, size, SZ_2M);
> + void __iomem *ptr;
> +
> + mutex_lock(>struct_mutex);
> + free = drm_mm_search_free(>linear, size, align, 0);
> + if (free)
> + obj->linear = drm_mm_get_block(free, size, align);
> + mutex_unlock(>struct_mutex);

The two-stage search_free+get_block drm_mm interface is something I'd like
to remove since it' complicates the interface for no gain. And the
preallocation trick for atomic contexts is pretty racy as-is. Can you
please convert this over to the insert_node interfaces which take a
preallocate drm_mm_node?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] [PATCH 04/66] drm: Optionally create mm blocks from top-to-bottom

[Daniel Vetter]

On Thu, Jun 27, 2013 at 04:30:05PM -0700, Ben Widawsky wrote:
> From: Chris Wilson 
> 
> Clients like i915 needs to segregate cache domains within the GTT which
> can lead to small amounts of fragmentation. By allocating the uncached
> buffers from the bottom and the cacheable buffers from the top, we can
> reduce the amount of wasted space and also optimize allocation of the
> mappable portion of the GTT to only those buffers that require CPU
> access through the GTT.
> 
> v2 by Ben:
> Update callers in i915_gem_object_bind_to_gtt()
> Turn search flags and allocation flags into separate enums
> Make checkpatch happy where logical/easy
> 
> Signed-off-by: Chris Wilson 
> Signed-off-by: Ben Widawsky 

Since this is a core drm patch it must be cc'ed to dri-devel (and acked by
Dave) before I can merge it. Can you please resend?
-Daniel

> ---
>  drivers/gpu/drm/drm_mm.c| 122 ++---
>  drivers/gpu/drm/i915/i915_gem.c |   4 +-
>  include/drm/drm_mm.h| 148 
> 
>  3 files changed, 161 insertions(+), 113 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index 07cf99c..7095328 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -49,7 +49,7 @@
>  
>  #define MM_UNUSED_TARGET 4
>  
> -static struct drm_mm_node *drm_mm_kmalloc(struct drm_mm *mm, int atomic)
> +static struct drm_mm_node *drm_mm_kmalloc(struct drm_mm *mm, bool atomic)
>  {
>   struct drm_mm_node *child;
>  
> @@ -105,7 +105,8 @@ EXPORT_SYMBOL(drm_mm_pre_get);
>  static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
>struct drm_mm_node *node,
>unsigned long size, unsigned alignment,
> -  unsigned long color)
> +  unsigned long color,
> +  enum drm_mm_allocator_flags flags)
>  {
>   struct drm_mm *mm = hole_node->mm;
>   unsigned long hole_start = drm_mm_hole_node_start(hole_node);
> @@ -118,12 +119,22 @@ static void drm_mm_insert_helper(struct drm_mm_node 
> *hole_node,
>   if (mm->color_adjust)
>   mm->color_adjust(hole_node, color, _start, _end);
>  
> + if (flags & DRM_MM_CREATE_TOP)
> + adj_start = adj_end - size;
> +
>   if (alignment) {
>   unsigned tmp = adj_start % alignment;
> - if (tmp)
> - adj_start += alignment - tmp;
> + if (tmp) {
> + if (flags & DRM_MM_CREATE_TOP)
> + adj_start -= tmp;
> + else
> + adj_start += alignment - tmp;
> + }
>   }
>  
> + BUG_ON(adj_start < hole_start);
> + BUG_ON(adj_end > hole_end);
> +
>   if (adj_start == hole_start) {
>   hole_node->hole_follows = 0;
>   list_del(_node->hole_stack);
> @@ -150,7 +161,7 @@ static void drm_mm_insert_helper(struct drm_mm_node 
> *hole_node,
>  struct drm_mm_node *drm_mm_create_block(struct drm_mm *mm,
>   unsigned long start,
>   unsigned long size,
> - bool atomic)
> + enum drm_mm_allocator_flags flags)
>  {
>   struct drm_mm_node *hole, *node;
>   unsigned long end = start + size;
> @@ -161,7 +172,7 @@ struct drm_mm_node *drm_mm_create_block(struct drm_mm *mm,
>   if (hole_start > start || hole_end < end)
>   continue;
>  
> - node = drm_mm_kmalloc(mm, atomic);
> + node = drm_mm_kmalloc(mm, flags & DRM_MM_CREATE_ATOMIC);
>   if (unlikely(node == NULL))
>   return NULL;
>  
> @@ -196,15 +207,15 @@ struct drm_mm_node *drm_mm_get_block_generic(struct 
> drm_mm_node *hole_node,
>unsigned long size,
>unsigned alignment,
>unsigned long color,
> -  int atomic)
> +  enum drm_mm_allocator_flags flags)
>  {
>   struct drm_mm_node *node;
>  
> - node = drm_mm_kmalloc(hole_node->mm, atomic);
> + node = drm_mm_kmalloc(hole_node->mm, flags & DRM_MM_CREATE_ATOMIC);
>   if (unlikely(node == NULL))
>   return NULL;
>  
> - drm_mm_insert_helper(hole_node, node, size, alignment, color);
> + drm_mm_insert_helper(hole_node, node, size, alignment, color, flags);
>  
>   return node;
>  }
> @@ -217,32 +228,28 @@ EXPORT_SYMBOL(drm_mm_get_block_generic);
>   */
>  int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
>  unsigned long size, unsigned alignment,
> -unsigned long color)
> +  

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Sun, Jun 30, 2013 at 02:37:41PM +0200, Daniel Vetter wrote:
> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> > +   mutex_lock(>struct_mutex);
> > +   free = drm_mm_search_free(>linear, size, align, 0);
> > +   if (free)
> > +   obj->linear = drm_mm_get_block(free, size, align);
> > +   mutex_unlock(>struct_mutex);
> 
> The two-stage search_free+get_block drm_mm interface is something I'd like
> to remove since it' complicates the interface for no gain. And the
> preallocation trick for atomic contexts is pretty racy as-is. Can you
> please convert this over to the insert_node interfaces which take a
> preallocate drm_mm_node?

Yes and no.  This is only racy if it is callable from atomic contexts,
which the above isn't, because it takes a mutex, and the above is the
only place which allocations against that pool are done.  Mutexes can't
be taken in atomic contexts.  Plus it's using the non-atomic drm_mm_*
interfaces.

However, the insert_node interfaces appear not to solve any kind of race.
All they do is allow the kmalloc to be moved out of this region into
the user of this code sequence, while offering no additional locking or
safety.  So the mutex lock around a call to drm_mm_insert_node*() is
still required.

As the kmalloc() happens beneath the mutex lock, another thread can't race
with an allocation in the above code anyway.  The *only* reason I'll change
this is that it is nicer to the system not to hold locks while allocating
memory.

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Daniel Vetter]

On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> This patch adds support for the pair of LCD controllers on the Marvell
> Armada 510 SoCs.  This driver supports:
> - multiple contiguous scanout buffers for video and graphics
> - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
>   acceleration
> - dual lcd0 and lcd1 crt operation
> - video overlay on each LCD crt
> - page flipping of the main scanout buffers
> 
> Included in this commit is the core driver with no output support; output
> support is platform and encoder driver dependent.
> 
> Signed-off-by: Russell King 

Upfront disclaimer: I have no clue about ARM/DT integration issues, so I
don't have any opinion/comments on those.

I've spotted a few other things though, see below. With those addressed
this patch is

Reviewed-by: Daniel Vetter 

Cheers, Daniel
> ---

[snip]

> +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
> +{
> + struct drm_display_mode *adj = >crtc.mode;
> + uint32_t val = 0;
> +
> + if (dcrtc->csc_yuv_mode == CSC_YUV_CCIR709)
> + val |= CFG_CSC_YUV_CCIR709;
> + if (dcrtc->csc_rgb_mode == CSC_RGB_STUDIO)
> + val |= CFG_CSC_RGB_STUDIO;
> +
> + /*
> +  * In auto mode, set the colorimetry, based upon the HDMI spec.
> +  * 1280x720p, 1920x1080p and 1920x1080i use ITU709, others use
> +  * ITU601.  It may be more appropriate to set this depending on
> +  * the source - but what if the graphic frame is YUV and the
> +  * video frame is RGB?
> +  */
> + if ((adj->hdisplay == 1280 && adj->vdisplay == 720 &&
> +  !(adj->flags & DRM_MODE_FLAG_INTERLACE)) ||
> + (adj->hdisplay == 1920 && adj->vdisplay == 1080)) {
> + if (dcrtc->csc_yuv_mode == CSC_AUTO)
> + val |= CFG_CSC_YUV_CCIR709;
> + }
> +
> + /*
> +  * We assume we're connected to a TV-like device, so the YUV->RGB
> +  * conversion should produce a limited range.  We should set this
> +  * depending on the connectors attached to this CRTC, and what
> +  * kind of device they report being connected.
> +  */
> + if (dcrtc->csc_rgb_mode == CSC_AUTO)
> + val |= CFG_CSC_RGB_STUDIO;

In the intel driver we check whether it's an cea mode with
drm_match_cea_mode, e.g. in intel_hdmi.c:

if (intel_hdmi->color_range_auto) {
/* See CEA-861-E - 5.1 Default Encoding Parameters */
if (intel_hdmi->has_hdmi_sink &&
drm_match_cea_mode(adjusted_mode) > 1)
intel_hdmi->color_range = HDMI_COLOR_RANGE_16_235;
else
intel_hdmi->color_range = 0;
}

(The color_range gets then propageted to the right place since different
platforms have different ways to do that in intel hw).

> +
> + return val;
> +}
> +

[snip]

> +struct armada_framebuffer *armada_framebuffer_create(struct drm_device *dev,
> + struct drm_mode_fb_cmd2 *mode, struct armada_gem_object *obj)
> +{
> + struct armada_framebuffer *dfb;
> + uint8_t format, config;
> + int ret;
> +
> + switch (mode->pixel_format) {
> +#define FMT(drm, fmt, mod)   \
> + case DRM_FORMAT_##drm:  \
> + format = CFG_##fmt; \
> + config = mod;   \
> + break
> + FMT(RGB565, 565,CFG_SWAPRB);
> + FMT(BGR565, 565,0);
> + FMT(ARGB1555,   1555,   CFG_SWAPRB);
> + FMT(ABGR1555,   1555,   0);
> + FMT(RGB888, 888PACK,CFG_SWAPRB);
> + FMT(BGR888, 888PACK,0);
> + FMT(XRGB,   X888,   CFG_SWAPRB);
> + FMT(XBGR,   X888,   0);
> + FMT(ARGB,   ,   CFG_SWAPRB);
> + FMT(ABGR,   ,   0);
> + FMT(YUYV,   422PACK,CFG_YUV2RGB | CFG_SWAPYU | CFG_SWAPUV);
> + FMT(UYVY,   422PACK,CFG_YUV2RGB);
> + FMT(VYUY,   422PACK,CFG_YUV2RGB | CFG_SWAPUV);
> + FMT(YVYU,   422PACK,CFG_YUV2RGB | CFG_SWAPYU);
> + FMT(YUV422, 422,CFG_YUV2RGB | CFG_SWAPUV);
> + FMT(YVU422, 422,CFG_YUV2RGB);
> + FMT(YUV420, 420,CFG_YUV2RGB | CFG_SWAPUV);
> + FMT(YVU420, 420,CFG_YUV2RGB);
> + FMT(C8, PSEUDO8,0);
> +#undef FMT
> + default:
> + return ERR_PTR(-EINVAL);
> + }
> +
> + dfb = kzalloc(sizeof(*dfb), GFP_KERNEL);
> + if (!dfb) {
> + DRM_ERROR("failed to allocate Armada fb object\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + dfb->fmt = format;
> + dfb->mod = config;
> +
> + ret = drm_framebuffer_init(dev, >fb, _fb_funcs);
> + if (ret) {
> + kfree(dfb);
> + return ERR_PTR(ret);
> + }

drm_framebuffer_init publishes the fb object to the 

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote:
> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> > +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
> > +{
> > +   struct drm_display_mode *adj = >crtc.mode;
> > +   uint32_t val = 0;
> > +
> > +   if (dcrtc->csc_yuv_mode == CSC_YUV_CCIR709)
> > +   val |= CFG_CSC_YUV_CCIR709;
> > +   if (dcrtc->csc_rgb_mode == CSC_RGB_STUDIO)
> > +   val |= CFG_CSC_RGB_STUDIO;
> > +
> > +   /*
> > +* In auto mode, set the colorimetry, based upon the HDMI spec.
> > +* 1280x720p, 1920x1080p and 1920x1080i use ITU709, others use
> > +* ITU601.  It may be more appropriate to set this depending on
> > +* the source - but what if the graphic frame is YUV and the
> > +* video frame is RGB?
> > +*/
> > +   if ((adj->hdisplay == 1280 && adj->vdisplay == 720 &&
> > +!(adj->flags & DRM_MODE_FLAG_INTERLACE)) ||
> > +   (adj->hdisplay == 1920 && adj->vdisplay == 1080)) {
> > +   if (dcrtc->csc_yuv_mode == CSC_AUTO)
> > +   val |= CFG_CSC_YUV_CCIR709;
> > +   }
> > +
> > +   /*
> > +* We assume we're connected to a TV-like device, so the YUV->RGB
> > +* conversion should produce a limited range.  We should set this
> > +* depending on the connectors attached to this CRTC, and what
> > +* kind of device they report being connected.
> > +*/
> > +   if (dcrtc->csc_rgb_mode == CSC_AUTO)
> > +   val |= CFG_CSC_RGB_STUDIO;
> 
> In the intel driver we check whether it's an cea mode with
> drm_match_cea_mode, e.g. in intel_hdmi.c:
> 
>   if (intel_hdmi->color_range_auto) {
>   /* See CEA-861-E - 5.1 Default Encoding Parameters */
>   if (intel_hdmi->has_hdmi_sink &&
>   drm_match_cea_mode(adjusted_mode) > 1)
>   intel_hdmi->color_range = HDMI_COLOR_RANGE_16_235;
>   else
>   intel_hdmi->color_range = 0;
>   }
> 
> (The color_range gets then propageted to the right place since different
> platforms have different ways to do that in intel hw).

Unfortunately, this disagrees with the HDMI v1.3a specification:

| Default Colorimetry
| 
| ...
| 
| 480p, 480i, 576p, 576i, 240p and 288p
| 
| The default colorimetry for all 480-line, 576-line, 240-line, and 288-line
| video formats described in CEA-861-D is based on SMPTE 170M.
| 
| 1080i, 1080p and 720p
| 
| The default colorimetry for high-definition video formats (1080i, 1080p and
| 720p) described in CEA-861-D is based on ITU-R BT.709-5.

As the HDMI spec refers to the CEA-861 specs, the HDMI spec overrides
CEA when dealing with HDMI specifics.

So, according to the HDMI specification, the default is that it's only
1080i, 1080p and 720p which are 709, the others are 601.  This does not
correspond with "drm_match_cea_mode(adjusted_mode) > 1".

Unfortunately, given DRM's structure, there's no way for the CRTC layer
to really know what its driving, and this setting is at the CRTC layer,
not the output layer.  It may be that you have the CRTC duplicated
between two different display devices with different characteristics,
which means you have to "choose" one - or just not bother.  I've chosen
the latter because it's a simpler solution, and is in no way any more
correct than any other solution.

This is also why these are exported to userspace via properties, so if
userspace knows better, it can deal with those issues.

> > +struct armada_framebuffer *armada_framebuffer_create(struct drm_device 
> > *dev,
> > +   struct drm_mode_fb_cmd2 *mode, struct armada_gem_object *obj)
> > +{
> > +   struct armada_framebuffer *dfb;
> > +   uint8_t format, config;
> > +   int ret;
> > +
> > +   switch (mode->pixel_format) {
> > +#define FMT(drm, fmt, mod) \
> > +   case DRM_FORMAT_##drm:  \
> > +   format = CFG_##fmt; \
> > +   config = mod;   \
> > +   break
> > +   FMT(RGB565, 565,CFG_SWAPRB);
> > +   FMT(BGR565, 565,0);
> > +   FMT(ARGB1555,   1555,   CFG_SWAPRB);
> > +   FMT(ABGR1555,   1555,   0);
> > +   FMT(RGB888, 888PACK,CFG_SWAPRB);
> > +   FMT(BGR888, 888PACK,0);
> > +   FMT(XRGB,   X888,   CFG_SWAPRB);
> > +   FMT(XBGR,   X888,   0);
> > +   FMT(ARGB,   ,   CFG_SWAPRB);
> > +   FMT(ABGR,   ,   0);
> > +   FMT(YUYV,   422PACK,CFG_YUV2RGB | CFG_SWAPYU | CFG_SWAPUV);
> > +   FMT(UYVY,   422PACK,CFG_YUV2RGB);
> > +   FMT(VYUY,   422PACK,CFG_YUV2RGB | CFG_SWAPUV);
> > +   FMT(YVYU,   422PACK,CFG_YUV2RGB | CFG_SWAPYU);
> > +   FMT(YUV422, 422,CFG_YUV2RGB | CFG_SWAPUV);
> > +   FMT(YVU422, 422,CFG_YUV2RGB);
> > +   FMT(YUV420, 420,CFG_YUV2RGB | CFG_SWAPUV);
> > +   FMT(YVU420, 420,CFG_YUV2RGB);
> > +   FMT(C8, 

[Bug 60251] Resume after suspend-to-RAM crashes in kernel module radeon

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

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





--- Comment #1 from Birger   2013-06-30 
13:17:50 ---
Created an attachment (id=106471)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=106471)
Contents of /var/log/pm-suspend.log

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

[Bug 60251] New: Resume after suspend-to-RAM crashes in kernel module radeon

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

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

   Summary: Resume after suspend-to-RAM crashes in kernel module
radeon
   Product: Drivers
   Version: 2.5
Kernel Version: 3.8.8, 3.9.8, drm-next from 2013-06-29
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: birger.retterstol.olaisen at gmail.com
Regression: No


I have an older HP Compaq dc5750 Microtower with an ATI Radeon XPRESS 1150
chipset and an integrated ATI Radeon X300 graphic card (RS482/RS485 [Radeon
Xpress 1100/1150]). For more detailed info on the system see
http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/12454-12454-64287-321860-3328896-3252512.html?dnr=1
. This is an x86_64 machine.

When doing suspend-to-RAM with pm-suspend, the system suspends nicely (screen
and fan turns off, and the power led starts pulsing) but when I try to resume
the system, it stops after just a couple of seconds, and I have to do a hard
reboot to start the system. /var/log/pm-suspend.log contains no lines from the
resume, only from the suspend.

The distribution I'm using is Linux Mint 15, based on Ubuntu 13.04, and I've
used DebuggingKernelSuspend from the Ubuntu Wiki
(https://wiki.ubuntu.com/DebuggingKernelSuspend) to try to debug the problem.
After recompiling the kernel with CONFIG_PM_TRACE, /sys/power/pm_trace pointed
to radeon kernel module as the source of the problem.

As suggested on the Ubuntu Wiki page, I also tested two mainline kernels
(drm-next from 2013-06-29 and v3.9.8) from
http://kernel.ubuntu.com/~kernel-ppa/, and they cashed on resume the same way
as the Ubuntu 3.8 kernel.

I attach the pm-suspend.log.

With regards,
Birger Retterst?l Olaisen

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

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

--- Comment #56 from Christian K?nig  ---
(In reply to comment #55)
> Sorry for the noise, I am seeing a different issue related to DPM.

Well then please open up a new bugreport, cause this one is about Macs not
booting the UVD block correctly.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130630/aa3f926c/attachment.html>

Linux 3.10-rc7

[Dave Airlie]

On Sun, Jun 30, 2013 at 8:13 AM, Linus Torvalds
 wrote:
> On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich  
> wrote:
>>> (and possibly the
>>> mkregtable binary) and trying again might fix it.
>>
>> Removing mkregtable  has indeed the compile issue for me. Thanks!
>
> Ok, so something failed at an earlier build. That error is probably
> long gone, though, since the subsequent build failure ends up being
> just a symptom rather than the underlying cause.
>
>>> Which still leaves
>>> us with the question of how this happened, and a potentially fragile
>>> Makefile.
>
> Radeon/drm people - any ideas how that mkregtable failure happened?
>

I'd care if we can definitely rule out previous power fails or forced reboots.
Otherwise just seems like noise, if gcc can produce 0 sized binaries
then I'm sure we'd have other issues.

Dave.

[PATCH] drm: drm init call takes large time

[Abbas Raza]

From: Abbas Raza 

DRM_INFO calls in the drm init routines are causing a large delay at boot time
due to which imx_drm_init call average takes around 26 ms. Changing DRM_INFO to
DRM_DEBUG reduces startup time to < 3ms.

Signed-off-by: Abbas Raza 
CC: David Airlie 
Acked-by: Dmitry Eremin-Solenikov 
---
 drivers/gpu/drm/drm_irq.c  | 6 +++---
 drivers/gpu/drm/drm_platform.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c798eea..782f5ff 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -252,13 +252,13 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
if (!dev->_vblank_time)
goto err;

-   DRM_INFO("Supports vblank timestamp caching Rev 1 (10.10.2010).\n");
+   DRM_DEBUG("Supports vblank timestamp caching Rev 1 (10.10.2010).\n");

/* Driver specific high-precision vblank timestamping supported? */
if (dev->driver->get_vblank_timestamp)
-   DRM_INFO("Driver supports precise vblank timestamp query.\n");
+   DRM_DEBUG("Driver supports precise vblank timestamp query.\n");
else
-   DRM_INFO("No driver support for vblank timestamp query.\n");
+   DRM_DEBUG("No driver support for vblank timestamp query.\n");

/* Zero per-crtc vblank stuff */
for (i = 0; i < num_crtcs; i++) {
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index 82431dc..7649963 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -92,7 +92,7 @@ int drm_get_platform_dev(struct platform_device *platdev,

mutex_unlock(_global_mutex);

-   DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n",
+   DRM_DEBUG("Initialized %s %d.%d.%d %s on minor %d\n",
 driver->name, driver->major, driver->minor, driver->patchlevel,
 driver->date, dev->primary->index);

-- 
1.8.2

Linux 3.10-rc7

[Sergey Meirovich]

On 30 June 2013 01:13, Linus Torvalds  wrote:
> On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich  
> wrote:
>>> (and possibly the
>>> mkregtable binary) and trying again might fix it.
>>
>> Removing mkregtable  has indeed the compile issue for me. Thanks!
>
> Ok, so something failed at an earlier build. That error is probably
> long gone, though, since the subsequent build failure ends up being
> just a symptom rather than the underlying cause.

There was overheating issue, that caused forced power off in the
middle of the first compile.

>
>>> Which still leaves
>>> us with the question of how this happened, and a potentially fragile
>>> Makefile.
>
> Radeon/drm people - any ideas how that mkregtable failure happened?
>
>Linus

[PATCH RFC 3/3] DRM: Armada: support for dma_buf import into gem

[Russell King]

Support importing certain dma_bufs back into gem - notably those which
are either contiguous or are our own exports which do not use
dma_map_sg().

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_drv.c |4 +-
 drivers/gpu/drm/armada/armada_fb.c  |6 +++
 drivers/gpu/drm/armada/armada_gem.c |   81 ++-
 drivers/gpu/drm/armada/armada_gem.h |4 ++
 4 files changed, 92 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index e0a08e9..268ea28 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -311,9 +311,9 @@ static struct drm_driver armada_drm_driver = {
.gem_init_object= NULL,
.gem_free_object= armada_gem_free_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = NULL,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export   = armada_gem_prime_export,
-   .gem_prime_import   = NULL,
+   .gem_prime_import   = armada_gem_prime_import,
.dumb_create= armada_gem_dumb_create,
.dumb_map_offset= armada_gem_dumb_map_offset,
.dumb_destroy   = armada_gem_dumb_destroy,
diff --git a/drivers/gpu/drm/armada/armada_fb.c 
b/drivers/gpu/drm/armada/armada_fb.c
index 5154f04..28965e3 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -120,6 +120,12 @@ static struct drm_framebuffer *armada_fb_create(struct 
drm_device *dev,
return ERR_PTR(-ENOENT);
}

+   if (obj->obj.import_attach && !obj->sgt) {
+   ret = armada_gem_map_import(obj);
+   if (ret)
+   goto unref;
+   }
+
/* Framebuffer objects must have a valid device address for scanout */
if (obj->dev_addr == DMA_ERROR_CODE) {
ret = -EINVAL;
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index d09fa14..ad517ce 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -70,6 +70,12 @@ void armada_gem_free_object(struct drm_gem_object *obj)
iounmap(dobj->addr);
}

+   if (dobj->obj.import_attach) {
+   /* We only ever display imported data */
+   dma_buf_unmap_attachment(dobj->obj.import_attach, dobj->sgt,
+DMA_TO_DEVICE);
+   drm_prime_gem_destroy(>obj, NULL);
+   }

drm_gem_object_release(>obj);

@@ -270,6 +276,12 @@ int armada_gem_dumb_map_offset(struct drm_file *file, 
struct drm_device *dev,
goto err_unlock;
}

+   /* Don't allow imported objects to be mapped */
+   if (obj->obj.import_attach) {
+   ret = -EINVAL;
+   goto err_unlock;
+   }
+
if (!obj->obj.map_list.map)
ret = drm_gem_create_mmap_offset(>obj);

@@ -537,5 +549,72 @@ armada_gem_prime_export(struct drm_device *dev, struct 
drm_gem_object *obj,
int flags)
 {
return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
- flags);
+ O_RDWR);
+}
+
+struct drm_gem_object *
+armada_gem_prime_import(struct drm_device *dev, struct dma_buf *buf)
+{
+   struct dma_buf_attachment *attach;
+   struct armada_gem_object *dobj;
+
+   if (buf->ops == _gem_prime_dmabuf_ops) {
+   struct drm_gem_object *obj = buf->priv;
+   if (obj->dev == dev) {
+   /*
+* Importing our own dmabuf(s) increases the
+* refcount on the gem object itself.
+*/
+   drm_gem_object_reference(obj);
+   dma_buf_put(buf);
+   return obj;
+   }
+   }
+
+   attach = dma_buf_attach(buf, dev->dev);
+   if (IS_ERR(attach))
+   return ERR_CAST(attach);
+
+   dobj = armada_gem_alloc_private_object(dev, buf->size);
+   if (!dobj) {
+   dma_buf_detach(buf, attach);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   dobj->obj.import_attach = attach;
+
+   /*
+* Don't call dma_buf_map_attachment() here - it maps the
+* scatterlist immediately for DMA, and this is not always
+* an appropriate thing to do.
+*/
+   return >obj;
+}
+
+int armada_gem_map_import(struct armada_gem_object *dobj)
+{
+   int ret;
+
+   dobj->sgt = dma_buf_map_attachment(dobj->obj.import_attach,
+ DMA_TO_DEVICE);
+   if (!dobj->sgt) {
+   DRM_ERROR("dma_buf_map_attachment() returned NULL\n");
+   return -EINVAL;
+   }
+   if (IS_ERR(dobj->sgt)) {
+

[PATCH RFC 2/3] DRM: Armada: Add support for ARGB 32x64 or 64x32 hardware cursors

[Russell King]

This patch adds ARGB hardware cursor support to the DRM driver for the
Marvell Armada SoCs.  ARGB cursors are supported at either 32x64 or
64x32 resolutions.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_510.c  |1 +
 drivers/gpu/drm/armada/armada_crtc.c |  244 +-
 drivers/gpu/drm/armada/armada_crtc.h |9 ++
 drivers/gpu/drm/armada/armada_drm.h  |1 +
 drivers/gpu/drm/armada/armada_hw.h   |6 +-
 5 files changed, 255 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_510.c 
b/drivers/gpu/drm/armada/armada_510.c
index a016888..59948ef 100644
--- a/drivers/gpu/drm/armada/armada_510.c
+++ b/drivers/gpu/drm/armada/armada_510.c
@@ -80,6 +80,7 @@ static int armada510_crtc_compute_clock(struct armada_crtc 
*dcrtc,

 const struct armada_variant armada510_ops = {
.has_spu_adv_reg = true,
+   .spu_adv_reg = ADV_HWC32ENABLE | ADV_HWC32ARGB | ADV_HWC32BLEND,
.init = armada510_init,
.crtc_init = armada510_crtc_init,
.crtc_compute_clock = armada510_crtc_compute_clock,
diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index f489157..7df1101 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -381,8 +381,21 @@ void armada_drm_crtc_irq(struct armada_crtc *dcrtc, u32 
stat)
val = readl_relaxed(base + LCD_SPU_ADV_REG);
val &= ~(ADV_VSYNC_L_OFF | ADV_VSYNC_H_OFF | ADV_VSYNCOFFEN);
val |= dcrtc->v[i].spu_adv_reg;
-   writel_relaxed(val, dcrtc->base + LCD_SPU_ADV_REG);
+   writel_relaxed(val, base + LCD_SPU_ADV_REG);
}
+
+   if (stat & DUMB_FRAMEDONE && dcrtc->cursor_update) {
+   writel_relaxed(dcrtc->cursor_hw_pos,
+  base + LCD_SPU_HWC_OVSA_HPXL_VLN);
+   writel_relaxed(dcrtc->cursor_hw_sz,
+  base + LCD_SPU_HWC_HPXL_VLN);
+   armada_updatel(CFG_HWC_ENA,
+  CFG_HWC_ENA | CFG_HWC_1BITMOD | CFG_HWC_1BITENA,
+  base + LCD_SPU_DMA_CTRL0);
+   dcrtc->cursor_update = false;
+   armada_drm_crtc_disable_irq(dcrtc, DUMB_FRAMEDONE_ENA);
+   }
+
spin_unlock(>irq_lock);

if (stat & GRA_FRAME_IRQ) {
@@ -522,7 +535,8 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
adj->crtc_htotal;
dcrtc->v[1].spu_v_porch = tm << 16 | bm;
val = adj->crtc_hsync_start;
-   dcrtc->v[1].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN;
+   dcrtc->v[1].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN |
+   priv->variant->spu_adv_reg;

if (interlaced) {
/* Odd interlaced frame */
@@ -530,7 +544,8 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
(1 << 16);
dcrtc->v[0].spu_v_porch = dcrtc->v[1].spu_v_porch + 1;
val = adj->crtc_hsync_start - adj->crtc_htotal / 2;
-   dcrtc->v[0].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN;
+   dcrtc->v[0].spu_adv_reg = val << 20 | val | ADV_VSYNCOFFEN |
+   priv->variant->spu_adv_reg;
} else {
dcrtc->v[0] = dcrtc->v[1];
}
@@ -545,10 +560,11 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
armada_reg_queue_set(regs, i, dcrtc->v[0].spu_v_h_total,
   LCD_SPUT_V_H_TOTAL);

-   if (priv->variant->has_spu_adv_reg)
+   if (priv->variant->has_spu_adv_reg) {
armada_reg_queue_mod(regs, i, dcrtc->v[0].spu_adv_reg,
 ADV_VSYNC_L_OFF | ADV_VSYNC_H_OFF |
 ADV_VSYNCOFFEN, LCD_SPU_ADV_REG);
+   }

val = CFG_GRA_ENA | CFG_GRA_HSMOOTH;
val |= CFG_GRA_FMT(drm_fb_to_armada_fb(dcrtc->crtc.fb)->fmt);
@@ -640,11 +656,229 @@ static const struct drm_crtc_helper_funcs 
armada_crtc_helper_funcs = {
.disable= armada_drm_crtc_disable,
 };

+static void armada_load_cursor_argb(void __iomem *base, uint32_t *pix,
+   unsigned stride, unsigned width, unsigned height)
+{
+   uint32_t addr;
+   unsigned y;
+
+   addr = SRAM_HWC32_RAM1;
+   for (y = 0; y < height; y++) {
+   uint32_t *p = [y * stride];
+   unsigned x;
+
+   for (x = 0; x < width; x++, p++) {
+   uint32_t val = *p;
+
+   val = (val & 0xff00ff00) |
+ (val & 0x00ff) << 16 |
+ (val & 0x00ff) >> 16;
+
+   writel_relaxed(val,
+  base + LCD_SPU_SRAM_WRDAT);
+   writel_relaxed(addr | SRAM_WRITE,
+  

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Russell King]

This patch adds support for the pair of LCD controllers on the Marvell
Armada 510 SoCs.  This driver supports:
- multiple contiguous scanout buffers for video and graphics
- shm backed cacheable buffer objects for X pixmaps for Vivante GPU
  acceleration
- dual lcd0 and lcd1 crt operation
- video overlay on each LCD crt
- page flipping of the main scanout buffers

Included in this commit is the core driver with no output support; output
support is platform and encoder driver dependent.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/Kconfig |2 +
 drivers/gpu/drm/Makefile|1 +
 drivers/gpu/drm/armada/Kconfig  |   15 +
 drivers/gpu/drm/armada/Makefile |7 +
 drivers/gpu/drm/armada/armada_510.c |   86 +++
 drivers/gpu/drm/armada/armada_crtc.c|  861 +++
 drivers/gpu/drm/armada/armada_crtc.h|   74 +++
 drivers/gpu/drm/armada/armada_debugfs.c |  187 +++
 drivers/gpu/drm/armada/armada_drm.h |  112 
 drivers/gpu/drm/armada/armada_drv.c |  381 ++
 drivers/gpu/drm/armada/armada_fb.c  |  155 ++
 drivers/gpu/drm/armada/armada_fb.h  |   24 +
 drivers/gpu/drm/armada/armada_fbdev.c   |  206 
 drivers/gpu/drm/armada/armada_gem.c |  541 +++
 drivers/gpu/drm/armada/armada_gem.h |   48 ++
 drivers/gpu/drm/armada/armada_hw.h  |  316 +++
 drivers/gpu/drm/armada/armada_ioctl.h   |   45 ++
 drivers/gpu/drm/armada/armada_ioctlP.h  |   18 +
 drivers/gpu/drm/armada/armada_output.c  |  159 ++
 drivers/gpu/drm/armada/armada_output.h  |   39 ++
 drivers/gpu/drm/armada/armada_overlay.c |  478 +
 drivers/gpu/drm/armada/armada_slave.c   |  139 +
 drivers/gpu/drm/armada/armada_slave.h   |   26 +
 drivers/gpu/drm/armada/drm_helper.h |   31 ++
 24 files changed, 3951 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/armada/Kconfig
 create mode 100644 drivers/gpu/drm/armada/Makefile
 create mode 100644 drivers/gpu/drm/armada/armada_510.c
 create mode 100644 drivers/gpu/drm/armada/armada_crtc.c
 create mode 100644 drivers/gpu/drm/armada/armada_crtc.h
 create mode 100644 drivers/gpu/drm/armada/armada_debugfs.c
 create mode 100644 drivers/gpu/drm/armada/armada_drm.h
 create mode 100644 drivers/gpu/drm/armada/armada_drv.c
 create mode 100644 drivers/gpu/drm/armada/armada_fb.c
 create mode 100644 drivers/gpu/drm/armada/armada_fb.h
 create mode 100644 drivers/gpu/drm/armada/armada_fbdev.c
 create mode 100644 drivers/gpu/drm/armada/armada_gem.c
 create mode 100644 drivers/gpu/drm/armada/armada_gem.h
 create mode 100644 drivers/gpu/drm/armada/armada_hw.h
 create mode 100644 drivers/gpu/drm/armada/armada_ioctl.h
 create mode 100644 drivers/gpu/drm/armada/armada_ioctlP.h
 create mode 100644 drivers/gpu/drm/armada/armada_output.c
 create mode 100644 drivers/gpu/drm/armada/armada_output.h
 create mode 100644 drivers/gpu/drm/armada/armada_overlay.c
 create mode 100644 drivers/gpu/drm/armada/armada_slave.c
 create mode 100644 drivers/gpu/drm/armada/armada_slave.h
 create mode 100644 drivers/gpu/drm/armada/drm_helper.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1e82882..ae8a57f 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -213,6 +213,8 @@ source "drivers/gpu/drm/mgag200/Kconfig"

 source "drivers/gpu/drm/cirrus/Kconfig"

+source "drivers/gpu/drm/armada/Kconfig"
+
 source "drivers/gpu/drm/shmobile/Kconfig"

 source "drivers/gpu/drm/tegra/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0d59b24..b458168 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_DRM_EXYNOS) +=exynos/
 obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
+obj-$(CONFIG_DRM_ARMADA) += armada/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_TEGRA) += tegra/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
new file mode 100644
index 000..c7a0a94
--- /dev/null
+++ b/drivers/gpu/drm/armada/Kconfig
@@ -0,0 +1,15 @@
+config DRM_ARMADA
+   tristate "DRM support for Marvell Armada SoCs"
+   depends on DRM && HAVE_CLK
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   select DRM_KMS_HELPER
+   help
+ Support the "LCD" controllers found on the Marvell Armada 510
+ devices.  There are two controllers on the device, each controller
+ supports graphics and video overlays.
+
+ This driver provides no built-in acceleration; acceleration is
+ performed by other IP found on the SoC.  This driver provides
+ kernel mode setting and buffer management to userspace.
diff --git a/drivers/gpu/drm/armada/Makefile b/drivers/gpu/drm/armada/Makefile
new file mode 100644
index 000..d6f43e0
--- 

[PATCH RFC v4 0/3] Armada DRM driver

[Russell King - ARM Linux]

Quite a number of things has changed since the last revision in the
core code - notably the move to use drm_plane for overlay, and the
limited and restricted use of dma_buf so that gem objects can be
passed to the GALCORE code and libbmm contiguous video frames can
be imported into DRM.

As I thought, this does require quite a number of new system calls,
but the case which I care more about (vlc) doesn't pass rendered
frames directly to the X server by physical address, it's not
something I'm particularly concerned about - for vlc and the "normal"
Xv protocol we can cache four DRM gem objects with their framebuffers
pre-prepared meaning we just copy the frame and call the DRM set_plane
function.

What the loss of the create_phys() interface does mean is that the
modified gstreamer gstbmmxvimagesink plugin will not work; it will
need to be updated.  I do *not* intend to support the hacky
bidirectional Xv SHM hack which Marvell came up with there!

I've left out the TDA998x changes and the final patch which depends
on those changes which add the HDMI output for the cubox, so this
series will be lacking the final parts of connector support.  It is
probable that the patch from the previous series can be trivially
applied to this (or easily adapted if not.)

Other changes:
- the crtc exports a few attributes now for setting the colour
  transform mode.  (CCIR601/709 to Computer vs "Studio" RGB).
  An automatic mode for these settings provided depending on selected
  resolution.
- overlay has working brightness/contrast/saturation settings, but
  not hue - not worked that bit out yet.
- hardware ARGB cursor support only in this version.
- backend ops are now called variants, because the structure started
  to contain other stuff other than just function pointers.  Armada510
  backend moved to a separate file.
- features requiring the SPU_ADV_REG (only present on Armada 510)
  can be disabled by the variant structure - such as interlace and
  ARGB cursor.
- use of page_alloc() reduced down to 8K, enough to store the hardware
  cursor.  This is all that that allocation was really used for anyway.
- now uses a common kfifo queue to free used framebuffers at the
  appropriate time, both from the crtc code and the drm_plane code,
  rather than having this logic in several places.  kfifo is a weird
  API and there's a note in the driver about that.
- framebuffers now carry their configuration with them, to save having
  the pixel format decode scattered in several places in the driver.
- power down FIFOs and RAMs not being used, and keep them powered down
  where possible.
- minimum framebuffer size added, moved out from the X server driver.
- maximum horizontal resolution dropped to 1920 to avoid a potential
  problem with V scaling (the RAM is apparantly 1920 pixels by 3 lines.)
- protection preventing various gem objects being used in unexpected
  ways added - eg, you can't create a framebuffer from a cursor gem
  object or an imported object which is non-contiguous.
- full range of colorkey modes for video supported (hey, it's just
  drm plane properties!)
- loads of smaller cleanups, and a number of checkpatch fixes.

Things left to do, in no particular order:
- Creation of planar YUV formatted framebuffers - I suspect the planar
  YUV formats are not supported for graphic framebuffers even though
  Marvell document the register settings.  (Where do you program the
  base addresses of the U and V planes?)  Not a high priority as Vmeta
  produces UYVY encoded frames and it's more efficient to keep the
  native format.
- Gamma support if anyone cares.  Again, not high priority.
- Resolution of the clocking conundrum.
- Resolution of the DT specification conundrum (super-device?)
- Specification of DRM connectors (DT but how?), their configuration,
  what they're connected to and what fixed format(s) they support.
- CMA or no CMA - I've added a comment pointing out additional concerns
  about how to get the physical address from CMA.  I think for most
  platforms this driver will be used on, the device address and physical
  address will be the same, but _conceptually_ they have never been the
  same in the kernel.
- DCON support... I have no use for this, and the information in my
  documentation is pretty damned poor, so much so that I'm reluctant to
  try prodding around with it, especially as some of it is
  self-contradictory.  Anyone who really cares about this can look at
  the issues there.

Stuff omitted:
- the DRM refcounting bug fix which breaks the i915 driver (but without
  it, booting with this driver results in a leaked refcount on the
  framebuffer thanks what I consider to be a bug in the DRM crtc code.)
  So don't boot this without something reporting itself as being
  connected with a valid mode.

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-daemon]

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

--- Comment #56 from Christian König deathsim...@vodafone.de ---
(In reply to comment #55)
 Sorry for the noise, I am seeing a different issue related to DPM.

Well then please open up a new bugreport, cause this one is about Macs not
booting the UVD block correctly.

-- 
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

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Daniel Vetter]

On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
 This patch adds support for the pair of LCD controllers on the Marvell
 Armada 510 SoCs.  This driver supports:
 - multiple contiguous scanout buffers for video and graphics
 - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
   acceleration
 - dual lcd0 and lcd1 crt operation
 - video overlay on each LCD crt
 - page flipping of the main scanout buffers
 
 Included in this commit is the core driver with no output support; output
 support is platform and encoder driver dependent.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk

Upfront disclaimer: I have no clue about ARM/DT integration issues, so I
don't have any opinion/comments on those.

I've spotted a few other things though, see below. With those addressed
this patch is

Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

Cheers, Daniel
 ---

[snip]

 +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
 +{
 + struct drm_display_mode *adj = dcrtc-crtc.mode;
 + uint32_t val = 0;
 +
 + if (dcrtc-csc_yuv_mode == CSC_YUV_CCIR709)
 + val |= CFG_CSC_YUV_CCIR709;
 + if (dcrtc-csc_rgb_mode == CSC_RGB_STUDIO)
 + val |= CFG_CSC_RGB_STUDIO;
 +
 + /*
 +  * In auto mode, set the colorimetry, based upon the HDMI spec.
 +  * 1280x720p, 1920x1080p and 1920x1080i use ITU709, others use
 +  * ITU601.  It may be more appropriate to set this depending on
 +  * the source - but what if the graphic frame is YUV and the
 +  * video frame is RGB?
 +  */
 + if ((adj-hdisplay == 1280  adj-vdisplay == 720 
 +  !(adj-flags  DRM_MODE_FLAG_INTERLACE)) ||
 + (adj-hdisplay == 1920  adj-vdisplay == 1080)) {
 + if (dcrtc-csc_yuv_mode == CSC_AUTO)
 + val |= CFG_CSC_YUV_CCIR709;
 + }
 +
 + /*
 +  * We assume we're connected to a TV-like device, so the YUV-RGB
 +  * conversion should produce a limited range.  We should set this
 +  * depending on the connectors attached to this CRTC, and what
 +  * kind of device they report being connected.
 +  */
 + if (dcrtc-csc_rgb_mode == CSC_AUTO)
 + val |= CFG_CSC_RGB_STUDIO;

In the intel driver we check whether it's an cea mode with
drm_match_cea_mode, e.g. in intel_hdmi.c:

if (intel_hdmi-color_range_auto) {
/* See CEA-861-E - 5.1 Default Encoding Parameters */
if (intel_hdmi-has_hdmi_sink 
drm_match_cea_mode(adjusted_mode)  1)
intel_hdmi-color_range = HDMI_COLOR_RANGE_16_235;
else
intel_hdmi-color_range = 0;
}

(The color_range gets then propageted to the right place since different
platforms have different ways to do that in intel hw).

 +
 + return val;
 +}
 +

[snip]

 +struct armada_framebuffer *armada_framebuffer_create(struct drm_device *dev,
 + struct drm_mode_fb_cmd2 *mode, struct armada_gem_object *obj)
 +{
 + struct armada_framebuffer *dfb;
 + uint8_t format, config;
 + int ret;
 +
 + switch (mode-pixel_format) {
 +#define FMT(drm, fmt, mod)   \
 + case DRM_FORMAT_##drm:  \
 + format = CFG_##fmt; \
 + config = mod;   \
 + break
 + FMT(RGB565, 565,CFG_SWAPRB);
 + FMT(BGR565, 565,0);
 + FMT(ARGB1555,   1555,   CFG_SWAPRB);
 + FMT(ABGR1555,   1555,   0);
 + FMT(RGB888, 888PACK,CFG_SWAPRB);
 + FMT(BGR888, 888PACK,0);
 + FMT(XRGB,   X888,   CFG_SWAPRB);
 + FMT(XBGR,   X888,   0);
 + FMT(ARGB,   ,   CFG_SWAPRB);
 + FMT(ABGR,   ,   0);
 + FMT(YUYV,   422PACK,CFG_YUV2RGB | CFG_SWAPYU | CFG_SWAPUV);
 + FMT(UYVY,   422PACK,CFG_YUV2RGB);
 + FMT(VYUY,   422PACK,CFG_YUV2RGB | CFG_SWAPUV);
 + FMT(YVYU,   422PACK,CFG_YUV2RGB | CFG_SWAPYU);
 + FMT(YUV422, 422,CFG_YUV2RGB | CFG_SWAPUV);
 + FMT(YVU422, 422,CFG_YUV2RGB);
 + FMT(YUV420, 420,CFG_YUV2RGB | CFG_SWAPUV);
 + FMT(YVU420, 420,CFG_YUV2RGB);
 + FMT(C8, PSEUDO8,0);
 +#undef FMT
 + default:
 + return ERR_PTR(-EINVAL);
 + }
 +
 + dfb = kzalloc(sizeof(*dfb), GFP_KERNEL);
 + if (!dfb) {
 + DRM_ERROR(failed to allocate Armada fb object\n);
 + return ERR_PTR(-ENOMEM);
 + }
 +
 + dfb-fmt = format;
 + dfb-mod = config;
 +
 + ret = drm_framebuffer_init(dev, dfb-fb, armada_fb_funcs);
 + if (ret) {
 + kfree(dfb);
 + return ERR_PTR(ret);
 + }

drm_framebuffer_init publishes the fb object to the world, hence
initialization of all invariant state _must_ be done beforehand. This is a
new 

Re: [Intel-gfx] [PATCH 04/66] drm: Optionally create mm blocks from top-to-bottom

[Daniel Vetter]

On Thu, Jun 27, 2013 at 04:30:05PM -0700, Ben Widawsky wrote:
 From: Chris Wilson ch...@chris-wilson.co.uk
 
 Clients like i915 needs to segregate cache domains within the GTT which
 can lead to small amounts of fragmentation. By allocating the uncached
 buffers from the bottom and the cacheable buffers from the top, we can
 reduce the amount of wasted space and also optimize allocation of the
 mappable portion of the GTT to only those buffers that require CPU
 access through the GTT.
 
 v2 by Ben:
 Update callers in i915_gem_object_bind_to_gtt()
 Turn search flags and allocation flags into separate enums
 Make checkpatch happy where logical/easy
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

Since this is a core drm patch it must be cc'ed to dri-devel (and acked by
Dave) before I can merge it. Can you please resend?
-Daniel

 ---
  drivers/gpu/drm/drm_mm.c| 122 ++---
  drivers/gpu/drm/i915/i915_gem.c |   4 +-
  include/drm/drm_mm.h| 148 
 
  3 files changed, 161 insertions(+), 113 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
 index 07cf99c..7095328 100644
 --- a/drivers/gpu/drm/drm_mm.c
 +++ b/drivers/gpu/drm/drm_mm.c
 @@ -49,7 +49,7 @@
  
  #define MM_UNUSED_TARGET 4
  
 -static struct drm_mm_node *drm_mm_kmalloc(struct drm_mm *mm, int atomic)
 +static struct drm_mm_node *drm_mm_kmalloc(struct drm_mm *mm, bool atomic)
  {
   struct drm_mm_node *child;
  
 @@ -105,7 +105,8 @@ EXPORT_SYMBOL(drm_mm_pre_get);
  static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
struct drm_mm_node *node,
unsigned long size, unsigned alignment,
 -  unsigned long color)
 +  unsigned long color,
 +  enum drm_mm_allocator_flags flags)
  {
   struct drm_mm *mm = hole_node-mm;
   unsigned long hole_start = drm_mm_hole_node_start(hole_node);
 @@ -118,12 +119,22 @@ static void drm_mm_insert_helper(struct drm_mm_node 
 *hole_node,
   if (mm-color_adjust)
   mm-color_adjust(hole_node, color, adj_start, adj_end);
  
 + if (flags  DRM_MM_CREATE_TOP)
 + adj_start = adj_end - size;
 +
   if (alignment) {
   unsigned tmp = adj_start % alignment;
 - if (tmp)
 - adj_start += alignment - tmp;
 + if (tmp) {
 + if (flags  DRM_MM_CREATE_TOP)
 + adj_start -= tmp;
 + else
 + adj_start += alignment - tmp;
 + }
   }
  
 + BUG_ON(adj_start  hole_start);
 + BUG_ON(adj_end  hole_end);
 +
   if (adj_start == hole_start) {
   hole_node-hole_follows = 0;
   list_del(hole_node-hole_stack);
 @@ -150,7 +161,7 @@ static void drm_mm_insert_helper(struct drm_mm_node 
 *hole_node,
  struct drm_mm_node *drm_mm_create_block(struct drm_mm *mm,
   unsigned long start,
   unsigned long size,
 - bool atomic)
 + enum drm_mm_allocator_flags flags)
  {
   struct drm_mm_node *hole, *node;
   unsigned long end = start + size;
 @@ -161,7 +172,7 @@ struct drm_mm_node *drm_mm_create_block(struct drm_mm *mm,
   if (hole_start  start || hole_end  end)
   continue;
  
 - node = drm_mm_kmalloc(mm, atomic);
 + node = drm_mm_kmalloc(mm, flags  DRM_MM_CREATE_ATOMIC);
   if (unlikely(node == NULL))
   return NULL;
  
 @@ -196,15 +207,15 @@ struct drm_mm_node *drm_mm_get_block_generic(struct 
 drm_mm_node *hole_node,
unsigned long size,
unsigned alignment,
unsigned long color,
 -  int atomic)
 +  enum drm_mm_allocator_flags flags)
  {
   struct drm_mm_node *node;
  
 - node = drm_mm_kmalloc(hole_node-mm, atomic);
 + node = drm_mm_kmalloc(hole_node-mm, flags  DRM_MM_CREATE_ATOMIC);
   if (unlikely(node == NULL))
   return NULL;
  
 - drm_mm_insert_helper(hole_node, node, size, alignment, color);
 + drm_mm_insert_helper(hole_node, node, size, alignment, color, flags);
  
   return node;
  }
 @@ -217,32 +228,28 @@ EXPORT_SYMBOL(drm_mm_get_block_generic);
   */
  int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
  unsigned long size, unsigned alignment,
 -unsigned long color)
 +unsigned long color,
 +

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Daniel Vetter]

On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
 This patch adds support for the pair of LCD controllers on the Marvell
 Armada 510 SoCs.  This driver supports:
 - multiple contiguous scanout buffers for video and graphics
 - shm backed cacheable buffer objects for X pixmaps for Vivante GPU
   acceleration
 - dual lcd0 and lcd1 crt operation
 - video overlay on each LCD crt
 - page flipping of the main scanout buffers
 
 Included in this commit is the core driver with no output support; output
 support is platform and encoder driver dependent.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk

Found one more ...

[snip]

 +int
 +armada_gem_linear_back(struct drm_device *dev, struct armada_gem_object *obj)
 +{
 + struct armada_private *priv = dev-dev_private;
 + size_t size = obj-obj.size;
 +
 + if (obj-page || obj-linear)
 + return 0;
 +
 + /*
 +  * If it is a small allocation (typically cursor, which will
 +  * be 32x64 or 64x32 ARGB pixels) try to get it from the system.
 +  * Framebuffers will never be this small (our minimum size for
 +  * framebuffers is larger than this anyway.)  Such objects are
 +  * only accessed by the CPU so we don't need any special handing
 +  * here.
 +  */
 + if (size = 8192) {
 + unsigned int order = get_order(size);
 + struct page *p = alloc_pages(GFP_KERNEL, order);
 +
 + if (p) {
 + obj-addr = page_address(p);
 + obj-phys_addr = page_to_phys(p);
 + obj-page = p;
 +
 + memset(obj-addr, 0, PAGE_ALIGN(size));
 + }
 + }
 +
 + /*
 +  * We could grab something from CMA if it's enabled, but that
 +  * involves building in a problem:
 +  *
 +  * CMA's interface uses dma_alloc_coherent(), which provides us
 +  * with an CPU virtual address and a device address.
 +  *
 +  * The CPU virtual address may be either an address in the kernel
 +  * direct mapped region (for example, as it would be on x86) or
 +  * it may be remapped into another part of kernel memory space
 +  * (eg, as it would be on ARM.)  This means virt_to_phys() on the
 +  * returned virtual address is invalid depending on the architecture
 +  * implementation.
 +  *
 +  * The device address may also not be a physical address; it may
 +  * be that there is some kind of remapping between the device and
 +  * system RAM, which makes the use of the device address also
 +  * unsafe to re-use as a physical address.
 +  *
 +  * This makes DRM usage of dma_alloc_coherent() in a generic way
 +  * at best very questionable and unsafe.
 +  */
 +
 + /* Otherwise, grab it from our linear allocation */
 + if (!obj-page) {
 + struct drm_mm_node *free;
 + unsigned align = min_t(unsigned, size, SZ_2M);
 + void __iomem *ptr;
 +
 + mutex_lock(dev-struct_mutex);
 + free = drm_mm_search_free(priv-linear, size, align, 0);
 + if (free)
 + obj-linear = drm_mm_get_block(free, size, align);
 + mutex_unlock(dev-struct_mutex);

The two-stage search_free+get_block drm_mm interface is something I'd like
to remove since it' complicates the interface for no gain. And the
preallocation trick for atomic contexts is pretty racy as-is. Can you
please convert this over to the insert_node interfaces which take a
preallocate drm_mm_node?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 04/66] drm: Optionally create mm blocks from top-to-bottom

[Daniel Vetter]

On Sun, Jun 30, 2013 at 2:30 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Thu, Jun 27, 2013 at 04:30:05PM -0700, Ben Widawsky wrote:
 From: Chris Wilson ch...@chris-wilson.co.uk

 Clients like i915 needs to segregate cache domains within the GTT which
 can lead to small amounts of fragmentation. By allocating the uncached
 buffers from the bottom and the cacheable buffers from the top, we can
 reduce the amount of wasted space and also optimize allocation of the
 mappable portion of the GTT to only those buffers that require CPU
 access through the GTT.

 v2 by Ben:
 Update callers in i915_gem_object_bind_to_gtt()
 Turn search flags and allocation flags into separate enums
 Make checkpatch happy where logical/easy

 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

 Since this is a core drm patch it must be cc'ed to dri-devel (and acked by
 Dave) before I can merge it. Can you please resend?

And same review as for Chris' original patch still applies: best_match
is unused (and it's better that way, really) so can be garbage
collected.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.10-rc7

[Sergey Meirovich]

On 30 June 2013 01:13, Linus Torvalds torva...@linux-foundation.org wrote:
 On Sat, Jun 29, 2013 at 2:07 PM, Sergey Meirovich rathamah...@gmail.com 
 wrote:
 (and possibly the
 mkregtable binary) and trying again might fix it.

 Removing mkregtable  has indeed the compile issue for me. Thanks!

 Ok, so something failed at an earlier build. That error is probably
 long gone, though, since the subsequent build failure ends up being
 just a symptom rather than the underlying cause.

There was overheating issue, that caused forced power off in the
middle of the first compile.


 Which still leaves
 us with the question of how this happened, and a potentially fragile
 Makefile.

 Radeon/drm people - any ideas how that mkregtable failure happened?

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

[Bug 60251] New: Resume after suspend-to-RAM crashes in kernel module radeon

[bugzilla-daemon]

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

   Summary: Resume after suspend-to-RAM crashes in kernel module
radeon
   Product: Drivers
   Version: 2.5
Kernel Version: 3.8.8, 3.9.8, drm-next from 2013-06-29
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: birger.retterstol.olai...@gmail.com
Regression: No


I have an older HP Compaq dc5750 Microtower with an ATI Radeon XPRESS 1150
chipset and an integrated ATI Radeon X300 graphic card (RS482/RS485 [Radeon
Xpress 1100/1150]). For more detailed info on the system see
http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/12454-12454-64287-321860-3328896-3252512.html?dnr=1
. This is an x86_64 machine.

When doing suspend-to-RAM with pm-suspend, the system suspends nicely (screen
and fan turns off, and the power led starts pulsing) but when I try to resume
the system, it stops after just a couple of seconds, and I have to do a hard
reboot to start the system. /var/log/pm-suspend.log contains no lines from the
resume, only from the suspend.

The distribution I'm using is Linux Mint 15, based on Ubuntu 13.04, and I've
used DebuggingKernelSuspend from the Ubuntu Wiki
(https://wiki.ubuntu.com/DebuggingKernelSuspend) to try to debug the problem.
After recompiling the kernel with CONFIG_PM_TRACE, /sys/power/pm_trace pointed
to radeon kernel module as the source of the problem.

As suggested on the Ubuntu Wiki page, I also tested two mainline kernels
(drm-next from 2013-06-29 and v3.9.8) from
http://kernel.ubuntu.com/~kernel-ppa/, and they cashed on resume the same way
as the Ubuntu 3.8 kernel.

I attach the pm-suspend.log.

With regards,
Birger Retterstøl Olaisen

-- 
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

[Bug 60251] Resume after suspend-to-RAM crashes in kernel module radeon

[bugzilla-daemon]

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





--- Comment #1 from Birger birger.retterstol.olai...@gmail.com  2013-06-30 
13:17:50 ---
Created an attachment (id=106471)
 -- (https://bugzilla.kernel.org/attachment.cgi?id=106471)
Contents of /var/log/pm-suspend.log

-- 
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

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote:
 On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
  +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
  +{
  +   struct drm_display_mode *adj = dcrtc-crtc.mode;
  +   uint32_t val = 0;
  +
  +   if (dcrtc-csc_yuv_mode == CSC_YUV_CCIR709)
  +   val |= CFG_CSC_YUV_CCIR709;
  +   if (dcrtc-csc_rgb_mode == CSC_RGB_STUDIO)
  +   val |= CFG_CSC_RGB_STUDIO;
  +
  +   /*
  +* In auto mode, set the colorimetry, based upon the HDMI spec.
  +* 1280x720p, 1920x1080p and 1920x1080i use ITU709, others use
  +* ITU601.  It may be more appropriate to set this depending on
  +* the source - but what if the graphic frame is YUV and the
  +* video frame is RGB?
  +*/
  +   if ((adj-hdisplay == 1280  adj-vdisplay == 720 
  +!(adj-flags  DRM_MODE_FLAG_INTERLACE)) ||
  +   (adj-hdisplay == 1920  adj-vdisplay == 1080)) {
  +   if (dcrtc-csc_yuv_mode == CSC_AUTO)
  +   val |= CFG_CSC_YUV_CCIR709;
  +   }
  +
  +   /*
  +* We assume we're connected to a TV-like device, so the YUV-RGB
  +* conversion should produce a limited range.  We should set this
  +* depending on the connectors attached to this CRTC, and what
  +* kind of device they report being connected.
  +*/
  +   if (dcrtc-csc_rgb_mode == CSC_AUTO)
  +   val |= CFG_CSC_RGB_STUDIO;
 
 In the intel driver we check whether it's an cea mode with
 drm_match_cea_mode, e.g. in intel_hdmi.c:
 
   if (intel_hdmi-color_range_auto) {
   /* See CEA-861-E - 5.1 Default Encoding Parameters */
   if (intel_hdmi-has_hdmi_sink 
   drm_match_cea_mode(adjusted_mode)  1)
   intel_hdmi-color_range = HDMI_COLOR_RANGE_16_235;
   else
   intel_hdmi-color_range = 0;
   }
 
 (The color_range gets then propageted to the right place since different
 platforms have different ways to do that in intel hw).

Unfortunately, this disagrees with the HDMI v1.3a specification:

| Default Colorimetry
| 
| ...
| 
| 480p, 480i, 576p, 576i, 240p and 288p
| 
| The default colorimetry for all 480-line, 576-line, 240-line, and 288-line
| video formats described in CEA-861-D is based on SMPTE 170M.
| 
| 1080i, 1080p and 720p
| 
| The default colorimetry for high-definition video formats (1080i, 1080p and
| 720p) described in CEA-861-D is based on ITU-R BT.709-5.

As the HDMI spec refers to the CEA-861 specs, the HDMI spec overrides
CEA when dealing with HDMI specifics.

So, according to the HDMI specification, the default is that it's only
1080i, 1080p and 720p which are 709, the others are 601.  This does not
correspond with drm_match_cea_mode(adjusted_mode)  1.

Unfortunately, given DRM's structure, there's no way for the CRTC layer
to really know what its driving, and this setting is at the CRTC layer,
not the output layer.  It may be that you have the CRTC duplicated
between two different display devices with different characteristics,
which means you have to choose one - or just not bother.  I've chosen
the latter because it's a simpler solution, and is in no way any more
correct than any other solution.

This is also why these are exported to userspace via properties, so if
userspace knows better, it can deal with those issues.

  +struct armada_framebuffer *armada_framebuffer_create(struct drm_device 
  *dev,
  +   struct drm_mode_fb_cmd2 *mode, struct armada_gem_object *obj)
  +{
  +   struct armada_framebuffer *dfb;
  +   uint8_t format, config;
  +   int ret;
  +
  +   switch (mode-pixel_format) {
  +#define FMT(drm, fmt, mod) \
  +   case DRM_FORMAT_##drm:  \
  +   format = CFG_##fmt; \
  +   config = mod;   \
  +   break
  +   FMT(RGB565, 565,CFG_SWAPRB);
  +   FMT(BGR565, 565,0);
  +   FMT(ARGB1555,   1555,   CFG_SWAPRB);
  +   FMT(ABGR1555,   1555,   0);
  +   FMT(RGB888, 888PACK,CFG_SWAPRB);
  +   FMT(BGR888, 888PACK,0);
  +   FMT(XRGB,   X888,   CFG_SWAPRB);
  +   FMT(XBGR,   X888,   0);
  +   FMT(ARGB,   ,   CFG_SWAPRB);
  +   FMT(ABGR,   ,   0);
  +   FMT(YUYV,   422PACK,CFG_YUV2RGB | CFG_SWAPYU | CFG_SWAPUV);
  +   FMT(UYVY,   422PACK,CFG_YUV2RGB);
  +   FMT(VYUY,   422PACK,CFG_YUV2RGB | CFG_SWAPUV);
  +   FMT(YVYU,   422PACK,CFG_YUV2RGB | CFG_SWAPYU);
  +   FMT(YUV422, 422,CFG_YUV2RGB | CFG_SWAPUV);
  +   FMT(YVU422, 422,CFG_YUV2RGB);
  +   FMT(YUV420, 420,CFG_YUV2RGB | CFG_SWAPUV);
  +   FMT(YVU420, 420,CFG_YUV2RGB);
  +   FMT(C8, PSEUDO8,0);
  +#undef FMT
  +   default:
  +   return ERR_PTR(-EINVAL);
  +   }
  +
  +   dfb = kzalloc(sizeof(*dfb), GFP_KERNEL);
  +   if (!dfb) {
  + 

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Sun, Jun 30, 2013 at 02:37:41PM +0200, Daniel Vetter wrote:
 On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
  +   mutex_lock(dev-struct_mutex);
  +   free = drm_mm_search_free(priv-linear, size, align, 0);
  +   if (free)
  +   obj-linear = drm_mm_get_block(free, size, align);
  +   mutex_unlock(dev-struct_mutex);
 
 The two-stage search_free+get_block drm_mm interface is something I'd like
 to remove since it' complicates the interface for no gain. And the
 preallocation trick for atomic contexts is pretty racy as-is. Can you
 please convert this over to the insert_node interfaces which take a
 preallocate drm_mm_node?

Yes and no.  This is only racy if it is callable from atomic contexts,
which the above isn't, because it takes a mutex, and the above is the
only place which allocations against that pool are done.  Mutexes can't
be taken in atomic contexts.  Plus it's using the non-atomic drm_mm_*
interfaces.

However, the insert_node interfaces appear not to solve any kind of race.
All they do is allow the kmalloc to be moved out of this region into
the user of this code sequence, while offering no additional locking or
safety.  So the mutex lock around a call to drm_mm_insert_node*() is
still required.

As the kmalloc() happens beneath the mutex lock, another thread can't race
with an allocation in the above code anyway.  The *only* reason I'll change
this is that it is nicer to the system not to hold locks while allocating
memory.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

On Sun, Jun 30, 2013 at 02:04:56PM +0100, Russell King - ARM Linux wrote:
 On Sun, Jun 30, 2013 at 02:37:41PM +0200, Daniel Vetter wrote:
  On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
   + mutex_lock(dev-struct_mutex);
   + free = drm_mm_search_free(priv-linear, size, align, 0);
   + if (free)
   + obj-linear = drm_mm_get_block(free, size, align);
   + mutex_unlock(dev-struct_mutex);
  
  The two-stage search_free+get_block drm_mm interface is something I'd like
  to remove since it' complicates the interface for no gain. And the
  preallocation trick for atomic contexts is pretty racy as-is. Can you
  please convert this over to the insert_node interfaces which take a
  preallocate drm_mm_node?
 
 Yes and no.  This is only racy if it is callable from atomic contexts,
 which the above isn't, because it takes a mutex, and the above is the
 only place which allocations against that pool are done.  Mutexes can't
 be taken in atomic contexts.  Plus it's using the non-atomic drm_mm_*
 interfaces.
 
 However, the insert_node interfaces appear not to solve any kind of race.
 All they do is allow the kmalloc to be moved out of this region into
 the user of this code sequence, while offering no additional locking or
 safety.  So the mutex lock around a call to drm_mm_insert_node*() is
 still required.
 
 As the kmalloc() happens beneath the mutex lock, another thread can't race
 with an allocation in the above code anyway.  The *only* reason I'll change
 this is that it is nicer to the system not to hold locks while allocating
 memory.

Err.  There's bugs here in the other drivers such as i915 which follow
your suggestion.  The problem is this:

Every time they allocate using drm_mm_insert_node(), they kmalloc a new
struct drm_mm_node for this function to fill in and attach.

When they've done with the allocation, they call drm_mm_put_block().
This places the node onto the mm's unused_nodes list provided we don't
already have MM_UNUSED_TARGET nodes on that list.

So, we end up filling up the unused nodes list to MM_UNUSED_TARGET,
at which point we then start freeing any further nodes - and with no
way to pull these off that list, they all just sit there not being
used.

The only function which takes nodes off that list is drm_mm_kmalloc(),
which is declared statically, and so isn't available to drivers.

Are drivers which use the drm_mm_insert_node() function expected to
also use drm_mm_remove_node(), kfreeing the node after that call,
rather than using drm_mm_put_block() ?

Either way, I think someone needs to fix the other drivers and Cc those
patches to Stable...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Russell King - ARM Linux]

Right, so, incrementally, the changes are (this may not entirely apply
to the version I've posted because I have several patches on top of
that.)

I've also added locking to the calls to drm_mm_dump_table() as otherwise
these walk those lists without holding any locks what so ever, which
could mean that a block is removed while we're walking the list.

 drivers/gpu/drm/armada/armada_debugfs.c |   17 ++--
 drivers/gpu/drm/armada/armada_fb.c  |   43 ++-
 drivers/gpu/drm/armada/armada_fbdev.c   |   20 ++
 drivers/gpu/drm/armada/armada_gem.c |   29 +++--
 4 files changed, 68 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_debugfs.c 
b/drivers/gpu/drm/armada/armada_debugfs.c
index f42f3ab..60e1038 100644
--- a/drivers/gpu/drm/armada/armada_debugfs.c
+++ b/drivers/gpu/drm/armada/armada_debugfs.c
@@ -23,16 +23,27 @@ static int armada_debugfs_gem_offs_show(struct seq_file *m, 
void *data)
struct drm_info_node *node = m-private;
struct drm_device *dev = node-minor-dev;
struct drm_gem_mm *mm = dev-mm_private;
+   int ret;
+
+   mutex_lock(dev-struct_mutex);
+   ret = drm_mm_dump_table(m, mm-offset_manager);
+   mutex_unlock(dev-struct_mutex);
 
-   return drm_mm_dump_table(m, mm-offset_manager);
+   return ret;
 }
 
 static int armada_debugfs_gem_linear_show(struct seq_file *m, void *data)
 {
struct drm_info_node *node = m-private;
-   struct armada_private *priv = node-minor-dev-dev_private;
+   struct drm_device *dev = node-minor-dev;
+   struct armada_private *priv = dev-dev_private;
+   int ret;
 
-   return drm_mm_dump_table(m, priv-linear);
+   mutex_lock(dev-struct_mutex);
+   ret = drm_mm_dump_table(m, priv-linear);
+   mutex_unlock(dev-struct_mutex);
+
+   return ret;
 }
 
 static int armada_debugfs_reg_show(struct seq_file *m, void *data)
diff --git a/drivers/gpu/drm/armada/armada_fb.c 
b/drivers/gpu/drm/armada/armada_fb.c
index 28965e3..97fbd61 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -79,6 +79,9 @@ struct armada_framebuffer *armada_framebuffer_create(struct 
drm_device *dev,
 
dfb-fmt = format;
dfb-mod = config;
+   dfb-obj = obj;
+
+   drm_helper_mode_fill_fb_struct(dfb-fb, mode);
 
ret = drm_framebuffer_init(dev, dfb-fb, armada_fb_funcs);
if (ret) {
@@ -86,14 +89,13 @@ struct armada_framebuffer *armada_framebuffer_create(struct 
drm_device *dev,
return ERR_PTR(ret);
}
 
-   drm_helper_mode_fill_fb_struct(dfb-fb, mode);
-
/*
-* Take a reference on our object - the caller is expected
-* to drop their reference to it.
+* Take a reference on our object as we're successful - the
+* caller already holds a reference, which keeps us safe for
+* the above call, but the caller will drop their reference
+* to it.  Hence we need to take our own reference.
 */
drm_gem_object_reference(obj-obj);
-   dfb-obj = obj;
 
return dfb;
 }
@@ -111,39 +113,44 @@ static struct drm_framebuffer *armada_fb_create(struct 
drm_device *dev,
mode-pitches[2]);
 
/* We can only handle a single plane at the moment */
-   if (drm_format_num_planes(mode-pixel_format)  1)
-   return ERR_PTR(-EINVAL);
+   if (drm_format_num_planes(mode-pixel_format)  1) {
+   ret = -EINVAL;
+   goto err;
+   }
 
obj = armada_gem_object_lookup(dev, dfile, mode-handles[0]);
if (!obj) {
-   DRM_ERROR(failed to lookup gem object\n);
-   return ERR_PTR(-ENOENT);
+   ret = -ENOENT;
+   goto err;
}
 
if (obj-obj.import_attach  !obj-sgt) {
ret = armada_gem_map_import(obj);
if (ret)
-   goto unref;
+   goto err_unref;
}
 
/* Framebuffer objects must have a valid device address for scanout */
if (obj-dev_addr == DMA_ERROR_CODE) {
ret = -EINVAL;
-   goto unref;
+   goto err_unref;
}
 
dfb = armada_framebuffer_create(dev, mode, obj);
-   ret = IS_ERR(dfb) ? PTR_ERR(dfb) : 0;
+   if (IS_ERR(dfb)) {
+   ret = PTR_ERR(dfb);
+   goto err;
+   }
 
-unref:
drm_gem_object_unreference_unlocked(obj-obj);
 
-   if (ret) {
-   DRM_ERROR(failed to initialize framebuffer: %d\n, ret);
-   return ERR_PTR(ret);
-   }
-
return dfb-fb;
+
+ err_unref:
+   drm_gem_object_unreference_unlocked(obj-obj);
+ err:
+   DRM_ERROR(failed to initialize framebuffer: %d\n, ret);
+   return ERR_PTR(ret);
 }
 
 static void armada_output_poll_changed(struct drm_device *dev)
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 

[Bug 57875] Second Life viewer bad rendering with git-ec83535

[bugzilla-daemon]

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

--- Comment #28 from Marek Olšák mar...@gmail.com ---
Stefan, is the extension for implementing the POSITIONT shader semantic? Would
a gl_Position output modifier also work for you?

For example:

#extension GL_MESA_xxx : require

pretransformed gl_Position;

void main()
{
...
etc.

-- 
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

Re: drm-next status (or: drm-openchrome will not be in 3.11)

[Johannes Obermayr]

Am Freitag, 28. Juni 2013, 13:31:50 schrieb Dave Airlie:
 Okay drm-next is pretty big, possibly the biggest ever.
 
 Outstanding things I know about, and will merge, if they arrive soon:
 exynos -next
 nouveau -next
 
 Big things I've merged:
 new rcar driver
 intel next
 radeon next
 tegra next
 shmob next
 core/mutexes
 ttm - reservation conversion
 tilcdc patches acked by Rob
 mtrr reworking
 prime + gem patches from samsung
 Laurent's documentation updates
 various mgag200 patches
 
 Otherwise I'm sure I've missed some changes, please let me know of
 anything you think has fallen down the cracks asap.
 
 Slow down people :-P
 
 Dave.

IRC #dri-devel:

jobermayr_ airlied: drm-openchrome will not be part of Kernel 3.11 because 
jsimmons has not responded?

airlied jobermayr: seems likely, I don't merge just because someone posts 
patchrs


Tasks to do:
http://lists.freedesktop.org/archives/dri-devel/2013-June/039695.html
http://lists.freedesktop.org/archives/dri-devel/2013-June/039796.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Daniel Vetter]

On Sun, Jun 30, 2013 at 3:41 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Sun, Jun 30, 2013 at 02:04:56PM +0100, Russell King - ARM Linux wrote:
 On Sun, Jun 30, 2013 at 02:37:41PM +0200, Daniel Vetter wrote:
  On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
   + mutex_lock(dev-struct_mutex);
   + free = drm_mm_search_free(priv-linear, size, align, 0);
   + if (free)
   + obj-linear = drm_mm_get_block(free, size, align);
   + mutex_unlock(dev-struct_mutex);
 
  The two-stage search_free+get_block drm_mm interface is something I'd like
  to remove since it' complicates the interface for no gain. And the
  preallocation trick for atomic contexts is pretty racy as-is. Can you
  please convert this over to the insert_node interfaces which take a
  preallocate drm_mm_node?

 Yes and no.  This is only racy if it is callable from atomic contexts,
 which the above isn't, because it takes a mutex, and the above is the
 only place which allocations against that pool are done.  Mutexes can't
 be taken in atomic contexts.  Plus it's using the non-atomic drm_mm_*
 interfaces.

 However, the insert_node interfaces appear not to solve any kind of race.
 All they do is allow the kmalloc to be moved out of this region into
 the user of this code sequence, while offering no additional locking or
 safety.  So the mutex lock around a call to drm_mm_insert_node*() is
 still required.

 As the kmalloc() happens beneath the mutex lock, another thread can't race
 with an allocation in the above code anyway.  The *only* reason I'll change
 this is that it is nicer to the system not to hold locks while allocating
 memory.

 Err.  There's bugs here in the other drivers such as i915 which follow
 your suggestion.  The problem is this:

 Every time they allocate using drm_mm_insert_node(), they kmalloc a new
 struct drm_mm_node for this function to fill in and attach.

 When they've done with the allocation, they call drm_mm_put_block().
 This places the node onto the mm's unused_nodes list provided we don't
 already have MM_UNUSED_TARGET nodes on that list.

Yeah, for drivers that never use the atomic alloc stuff it's pointless
waste of memory.

 So, we end up filling up the unused nodes list to MM_UNUSED_TARGET,
 at which point we then start freeing any further nodes - and with no
 way to pull these off that list, they all just sit there not being
 used.

 The only function which takes nodes off that list is drm_mm_kmalloc(),
 which is declared statically, and so isn't available to drivers.

 Are drivers which use the drm_mm_insert_node() function expected to
 also use drm_mm_remove_node(), kfreeing the node after that call,
 rather than using drm_mm_put_block() ?

Yeah, with the insert_node interface deallocing the node is the
driver's responsibility.

 Either way, I think someone needs to fix the other drivers and Cc those
 patches to Stable...

Yeah, I think it's time that I move that item up my todo list a lot.
And also add some decent kerneldoc to the drm_mm stuff.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Daniel Vetter]

On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote:
 On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
  +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
  +{
  +   struct drm_display_mode *adj = dcrtc-crtc.mode;
  +   uint32_t val = 0;
  +
  +   if (dcrtc-csc_yuv_mode == CSC_YUV_CCIR709)
  +   val |= CFG_CSC_YUV_CCIR709;
  +   if (dcrtc-csc_rgb_mode == CSC_RGB_STUDIO)
  +   val |= CFG_CSC_RGB_STUDIO;
  +
  +   /*
  +* In auto mode, set the colorimetry, based upon the HDMI spec.
  +* 1280x720p, 1920x1080p and 1920x1080i use ITU709, others use
  +* ITU601.  It may be more appropriate to set this depending on
  +* the source - but what if the graphic frame is YUV and the
  +* video frame is RGB?
  +*/
  +   if ((adj-hdisplay == 1280  adj-vdisplay == 720 
  +!(adj-flags  DRM_MODE_FLAG_INTERLACE)) ||
  +   (adj-hdisplay == 1920  adj-vdisplay == 1080)) {
  +   if (dcrtc-csc_yuv_mode == CSC_AUTO)
  +   val |= CFG_CSC_YUV_CCIR709;
  +   }
  +
  +   /*
  +* We assume we're connected to a TV-like device, so the YUV-RGB
  +* conversion should produce a limited range.  We should set this
  +* depending on the connectors attached to this CRTC, and what
  +* kind of device they report being connected.
  +*/
  +   if (dcrtc-csc_rgb_mode == CSC_AUTO)
  +   val |= CFG_CSC_RGB_STUDIO;

 In the intel driver we check whether it's an cea mode with
 drm_match_cea_mode, e.g. in intel_hdmi.c:

   if (intel_hdmi-color_range_auto) {
   /* See CEA-861-E - 5.1 Default Encoding Parameters */
   if (intel_hdmi-has_hdmi_sink 
   drm_match_cea_mode(adjusted_mode)  1)
   intel_hdmi-color_range = HDMI_COLOR_RANGE_16_235;
   else
   intel_hdmi-color_range = 0;
   }

 (The color_range gets then propageted to the right place since different
 platforms have different ways to do that in intel hw).

 Unfortunately, this disagrees with the HDMI v1.3a specification:

 | Default Colorimetry
 |
 | ...
 |
 | 480p, 480i, 576p, 576i, 240p and 288p
 |
 | The default colorimetry for all 480-line, 576-line, 240-line, and 288-line
 | video formats described in CEA-861-D is based on SMPTE 170M.
 |
 | 1080i, 1080p and 720p
 |
 | The default colorimetry for high-definition video formats (1080i, 1080p and
 | 720p) described in CEA-861-D is based on ITU-R BT.709-5.

 As the HDMI spec refers to the CEA-861 specs, the HDMI spec overrides
 CEA when dealing with HDMI specifics.

 So, according to the HDMI specification, the default is that it's only
 1080i, 1080p and 720p which are 709, the others are 601.  This does not
 correspond with drm_match_cea_mode(adjusted_mode)  1.

Hm, sounds like we need to improve stuff a bit, maybe add a common cea
helper to the drm core with a bool is_hdmi to decide whether it's
palin CEA or HDMI-CEA. Ville (who's written the current code and the
match cea mode helper) can you please take a look?

 Unfortunately, given DRM's structure, there's no way for the CRTC layer
 to really know what its driving, and this setting is at the CRTC layer,
 not the output layer.  It may be that you have the CRTC duplicated
 between two different display devices with different characteristics,
 which means you have to choose one - or just not bother.  I've chosen
 the latter because it's a simpler solution, and is in no way any more
 correct than any other solution.

 This is also why these are exported to userspace via properties, so if
 userspace knows better, it can deal with those issues.

Yeah, allowing userspace to overwrite the default selection makes lots
of sense, we expose similar properties.

  +struct armada_framebuffer *armada_framebuffer_create(struct drm_device 
  *dev,
  +   struct drm_mode_fb_cmd2 *mode, struct armada_gem_object *obj)
  +{
  +   struct armada_framebuffer *dfb;
  +   uint8_t format, config;
  +   int ret;
  +
  +   switch (mode-pixel_format) {
  +#define FMT(drm, fmt, mod) \
  +   case DRM_FORMAT_##drm:  \
  +   format = CFG_##fmt; \
  +   config = mod;   \
  +   break
  +   FMT(RGB565, 565,CFG_SWAPRB);
  +   FMT(BGR565, 565,0);
  +   FMT(ARGB1555,   1555,   CFG_SWAPRB);
  +   FMT(ABGR1555,   1555,   0);
  +   FMT(RGB888, 888PACK,CFG_SWAPRB);
  +   FMT(BGR888, 888PACK,0);
  +   FMT(XRGB,   X888,   CFG_SWAPRB);
  +   FMT(XBGR,   X888,   0);
  +   FMT(ARGB,   ,   CFG_SWAPRB);
  +   FMT(ABGR,   ,   0);
  +   FMT(YUYV,   422PACK,CFG_YUV2RGB | CFG_SWAPYU | CFG_SWAPUV);
  +   FMT(UYVY,   422PACK,CFG_YUV2RGB);
  +   FMT(VYUY,   422PACK,CFG_YUV2RGB | CFG_SWAPUV);
  +   

Re: [Openchrome-devel] [RFC 1/21] Add VIA DRM driver

[James Simmons]

  commit 1fcf23d361375645d586756d126b436796ba4fba
  Author: James Simmons jsimm...@infradead.org
  Date:   Sat Jun 8 09:31:57 2013 -0400
 
  via: New KMS ioctls and hardware to support.
 
  Add new VIA pci ids to support newer hardware. Cleanup userspace
  api structs to remove kernel types and add the new KMS ioctls we
  will be supporting.
 
 why remove all the __u32? seems to just undo
 1d7f83d5ad6c30b385ba549c1c3a287cc872b7ae
 
 and definitely shouldn't be in this patch.

Attempting to sync my userland header in xorg with what is used in the 
kernel. Since we have BSD users I attempted to play nice. This weekend
I played with a new header format that should satisfy everyone.
 
 Also I don't think its really necessary to add all the pci ids there,
 just put them in the driver.

Would you be okay with the pci ids being in via_drm.h instead? I have to 
look but if I remember correctly some of those pci ids are for the north 
bridge bus which is used to detect how much VRAM we have.

 
   #define DRM_IOCTL_VIA_ALLOCMEM   DRM_IOWR(DRM_COMMAND_BASE + 
  DRM_VIA_ALLOCMEM, drm_via_mem_t)
   #define DRM_IOCTL_VIA_FREEMEMDRM_IOW( DRM_COMMAND_BASE + 
  DRM_VIA_FREEMEM, drm_via_mem_t)
  @@ -86,6 +89,7 @@
   #define DRM_IOCTL_VIA_FB_INITDRM_IOWR(DRM_COMMAND_BASE + 
  DRM_VIA_FB_INIT, drm_via_fb_t)
   #define DRM_IOCTL_VIA_MAP_INIT   DRM_IOWR(DRM_COMMAND_BASE + 
  DRM_VIA_MAP_INIT, drm_via_init_t)
   #define DRM_IOCTL_VIA_DEC_FUTEX   DRM_IOW( DRM_COMMAND_BASE + 
  DRM_VIA_DEC_FUTEX, drm_via_futex_t)
  +#define DRM_IOCTL_VIA_OLD_GEM_CREATE  DRM_IOWR(DRM_COMMAND_BASE + 
  DRM_VIA_OLD_GEM_CREATE, struct drm_via_gem_create)
   #define DRM_IOCTL_VIA_DMA_INIT   DRM_IOWR(DRM_COMMAND_BASE + 
  DRM_VIA_DMA_INIT, drm_via_dma_init_t)
   #define DRM_IOCTL_VIA_CMDBUFFER  DRM_IOW( DRM_COMMAND_BASE + 
  DRM_VIA_CMDBUFFER, drm_via_cmdbuffer_t)
   #define DRM_IOCTL_VIA_FLUSH  DRM_IO(  DRM_COMMAND_BASE + DRM_VIA_FLUSH)
  @@ -96,6 +100,13 @@
   #define DRM_IOCTL_VIA_DMA_BLITDRM_IOW(DRM_COMMAND_BASE + 
  DRM_VIA_DMA_BLIT, drm_via_dmablit_t)
   #define DRM_IOCTL_VIA_BLIT_SYNC   DRM_IOW(DRM_COMMAND_BASE + 
  DRM_VIA_BLIT_SYNC, drm_via_blitsync_t)
 
  +/* KMS ioctls */
  +#define DRM_IOCTL_VIA_GETPARAMDRM_IOR(DRM_COMMAND_BASE + 
  DRM_VIA_GETPARAM, struct drm_via_param)
  +#define DRM_IOCTL_VIA_SETPARAMDRM_IOW(DRM_COMMAND_BASE + 
  DRM_VIA_SETPARAM, struct drm_via_param)
  +#define DRM_IOCTL_VIA_GEM_CREATE  DRM_IOWR(DRM_COMMAND_BASE + 
  DRM_VIA_GEM_CREATE, struct drm_via_gem_create)
  +#define DRM_IOCTL_VIA_GEM_WAITDRM_IOW(DRM_COMMAND_BASE + 
  DRM_VIA_GEM_WAIT, struct drm_via_gem_wait)
  +#define DRM_IOCTL_VIA_GEM_STATE   DRM_IOWR(DRM_COMMAND_BASE + 
  DRM_VIA_GEM_STATE, struct drm_via_gem_create)
 
 why does gem_state take a gem_create struct? is it the same info it returns?

Yes that same info is returned. Prehaps struct drm_via_gem_create is a 
poor name. Maybe struct drm_via_gem_object ?

   typedef struct drm_via_dmablit {
  -   __u32 num_lines;
  -   __u32 line_length;
  +   uint32_t num_lines;
  +   uint32_t line_length;
 
  -   __u32 fb_addr;
  -   __u32 fb_stride;
  +   uint32_t fb_addr;
  +   uint32_t fb_stride;
 
  unsigned char *mem_addr;
  -   __u32 mem_stride;
  +   uint32_t  mem_stride;
 
  -   __u32 flags;
  +   int bounce_buffer;
 
 ^ totally wtf here? no explains.

Leftovers from older work that doesn't exist anymore. My bad.
 
  int to_fb;
 
  drm_via_blitsync_t sync;
   } drm_via_dmablit_t;
 
  -struct via_file_private {
  -   struct list_head obj_list;
  +/* Ioctl to query kernel params:
  + */
  +#define VIA_PARAM_CHIPSET_ID   0
  +#define VIA_PARAM_REVISION_ID  1
  +
  +struct drm_via_param {
  +   uint64_t param;
  +   uint64_t value;
  +};
  +
  +struct drm_via_gem_create {
  +   /**
  +* Requested size for the object.
  +*
  +* The (page-aligned) allocated size for the object will be 
  returned.
  +*/
  +   uint64_t size;
  +
  +   /*
  +* Place the memory at the proper byte alignment.
  +*/
  +   uint32_t alignment;
  +
  +   /**
  +* Format of data i.e tile pitch, for linear it is zero
  +*/
  +   uint32_t pitch;
  +
  +   /**
  +* Give hints where to allocate this object.
  +*/
  +   uint32_t domains;
  +
  +   /**
  +* chmod values applied to a buffer.
  +*/
  +   uint32_t mode_t;
  +
  +   /**
  +* Offset to start of memory region.
  +*/
  +   uint64_t offset;
  +
  +   /**
  +* Returned handle need to mmap the buffer.
  +*/
  +   uint64_t map_handle;
  +
  +   /**
  +* Returned handle for the object.
  +*
  +* Object handles are nonzero.
  +*/
  +   uint32_t handle;
  +
  +   /**
  +* Padding for future expansion.
  + 

Re: drm-next status (or: drm-openchrome will not be in 3.11)

[James Simmons]

 Am Freitag, 28. Juni 2013, 13:31:50 schrieb Dave Airlie:
  Okay drm-next is pretty big, possibly the biggest ever.
  
  Outstanding things I know about, and will merge, if they arrive soon:
  exynos -next
  nouveau -next
  
  Big things I've merged:
  new rcar driver
  intel next
  radeon next
  tegra next
  shmob next
  core/mutexes
  ttm - reservation conversion
  tilcdc patches acked by Rob
  mtrr reworking
  prime + gem patches from samsung
  Laurent's documentation updates
  various mgag200 patches
  
  Otherwise I'm sure I've missed some changes, please let me know of
  anything you think has fallen down the cracks asap.
  
  Slow down people :-P
  
  Dave.
 
 IRC #dri-devel:
 
 jobermayr_ airlied: drm-openchrome will not be part of Kernel 3.11 because 
 jsimmons has not responded?
 
 airlied jobermayr: seems likely, I don't merge just because someone posts 
 patchrs
 
 
 Tasks to do:
 http://lists.freedesktop.org/archives/dri-devel/2013-June/039695.html
 http://lists.freedesktop.org/archives/dri-devel/2013-June/039796.html

The VIA driver is pretty huge. Its going to take time to merge it. Plus 
I'm the new guy so I don't have the level of trust the other maintainers
have.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm-next status (or: drm-openchrome will not be in 3.11)

[Konrad Rzeszutek Wilk]

James Simmons jsimm...@infradead.org wrote:


 Am Freitag, 28. Juni 2013, 13:31:50 schrieb Dave Airlie:
  Okay drm-next is pretty big, possibly the biggest ever.
  
  Outstanding things I know about, and will merge, if they arrive
soon:
  exynos -next
  nouveau -next
  
  Big things I've merged:
  new rcar driver
  intel next
  radeon next
  tegra next
  shmob next
  core/mutexes
  ttm - reservation conversion
  tilcdc patches acked by Rob
  mtrr reworking
  prime + gem patches from samsung
  Laurent's documentation updates
  various mgag200 patches
  
  Otherwise I'm sure I've missed some changes, please let me know of
  anything you think has fallen down the cracks asap.
  
  Slow down people :-P
  
  Dave.
 
 IRC #dri-devel:
 
 jobermayr_ airlied: drm-openchrome will not be part of Kernel 3.11
because 
 jsimmons has not responded?
 
 airlied jobermayr: seems likely, I don't merge just because someone
posts 
 patchrs
 
 
 Tasks to do:
 http://lists.freedesktop.org/archives/dri-devel/2013-June/039695.html
 http://lists.freedesktop.org/archives/dri-devel/2013-June/039796.html

The VIA driver is pretty huge. Its going to take time to merge it. Plus

I'm the new guy so I don't have the level of trust the other
maintainers
have.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Could you repost it with some of the reviewers comments addressed please? 
-- 
Sent from my Android phone. Please excuse my brevity.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Dave Airlie]

On Sun, Jun 30, 2013 at 10:52 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote:
 On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
  +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
  +{
  +   struct drm_display_mode *adj = dcrtc-crtc.mode;
  +   uint32_t val = 0;
  +
  +   if (dcrtc-csc_yuv_mode == CSC_YUV_CCIR709)
  +   val |= CFG_CSC_YUV_CCIR709;
  +   if (dcrtc-csc_rgb_mode == CSC_RGB_STUDIO)
  +   val |= CFG_CSC_RGB_STUDIO;
  +
  +   /*
  +* In auto mode, set the colorimetry, based upon the HDMI spec.
  +* 1280x720p, 1920x1080p and 1920x1080i use ITU709, others use
  +* ITU601.  It may be more appropriate to set this depending on
  +* the source - but what if the graphic frame is YUV and the
  +* video frame is RGB?
  +*/
  +   if ((adj-hdisplay == 1280  adj-vdisplay == 720 
  +!(adj-flags  DRM_MODE_FLAG_INTERLACE)) ||
  +   (adj-hdisplay == 1920  adj-vdisplay == 1080)) {
  +   if (dcrtc-csc_yuv_mode == CSC_AUTO)
  +   val |= CFG_CSC_YUV_CCIR709;
  +   }
  +
  +   /*
  +* We assume we're connected to a TV-like device, so the YUV-RGB
  +* conversion should produce a limited range.  We should set this
  +* depending on the connectors attached to this CRTC, and what
  +* kind of device they report being connected.
  +*/
  +   if (dcrtc-csc_rgb_mode == CSC_AUTO)
  +   val |= CFG_CSC_RGB_STUDIO;

 In the intel driver we check whether it's an cea mode with
 drm_match_cea_mode, e.g. in intel_hdmi.c:

   if (intel_hdmi-color_range_auto) {
   /* See CEA-861-E - 5.1 Default Encoding Parameters */
   if (intel_hdmi-has_hdmi_sink 
   drm_match_cea_mode(adjusted_mode)  1)
   intel_hdmi-color_range = HDMI_COLOR_RANGE_16_235;
   else
   intel_hdmi-color_range = 0;
   }

 (The color_range gets then propageted to the right place since different
 platforms have different ways to do that in intel hw).

 Unfortunately, this disagrees with the HDMI v1.3a specification:

 | Default Colorimetry
 |
 | ...
 |
 | 480p, 480i, 576p, 576i, 240p and 288p
 |
 | The default colorimetry for all 480-line, 576-line, 240-line, and 288-line
 | video formats described in CEA-861-D is based on SMPTE 170M.
 |
 | 1080i, 1080p and 720p
 |
 | The default colorimetry for high-definition video formats (1080i, 1080p and
 | 720p) described in CEA-861-D is based on ITU-R BT.709-5.

 As the HDMI spec refers to the CEA-861 specs, the HDMI spec overrides
 CEA when dealing with HDMI specifics.

 So, according to the HDMI specification, the default is that it's only
 1080i, 1080p and 720p which are 709, the others are 601.  This does not
 correspond with drm_match_cea_mode(adjusted_mode)  1.

 Unfortunately, given DRM's structure, there's no way for the CRTC layer
 to really know what its driving, and this setting is at the CRTC layer,
 not the output layer.  It may be that you have the CRTC duplicated
 between two different display devices with different characteristics,
 which means you have to choose one - or just not bother.  I've chosen
 the latter because it's a simpler solution, and is in no way any more
 correct than any other solution.

 This is also why these are exported to userspace via properties, so if
 userspace knows better, it can deal with those issues.

  +struct armada_framebuffer *armada_framebuffer_create(struct drm_device 
  *dev,
  +   struct drm_mode_fb_cmd2 *mode, struct armada_gem_object *obj)
  +{
  +   struct armada_framebuffer *dfb;
  +   uint8_t format, config;
  +   int ret;
  +
  +   switch (mode-pixel_format) {
  +#define FMT(drm, fmt, mod) \
  +   case DRM_FORMAT_##drm:  \
  +   format = CFG_##fmt; \
  +   config = mod;   \
  +   break
  +   FMT(RGB565, 565,CFG_SWAPRB);
  +   FMT(BGR565, 565,0);
  +   FMT(ARGB1555,   1555,   CFG_SWAPRB);
  +   FMT(ABGR1555,   1555,   0);
  +   FMT(RGB888, 888PACK,CFG_SWAPRB);
  +   FMT(BGR888, 888PACK,0);
  +   FMT(XRGB,   X888,   CFG_SWAPRB);
  +   FMT(XBGR,   X888,   0);
  +   FMT(ARGB,   ,   CFG_SWAPRB);
  +   FMT(ABGR,   ,   0);
  +   FMT(YUYV,   422PACK,CFG_YUV2RGB | CFG_SWAPYU | CFG_SWAPUV);
  +   FMT(UYVY,   422PACK,CFG_YUV2RGB);
  +   FMT(VYUY,   422PACK,CFG_YUV2RGB | CFG_SWAPUV);
  +   FMT(YVYU,   422PACK,CFG_YUV2RGB | CFG_SWAPYU);
  +   FMT(YUV422, 422,CFG_YUV2RGB | CFG_SWAPUV);
  +   FMT(YVU422, 422,CFG_YUV2RGB);
  +   FMT(YUV420, 420,CFG_YUV2RGB | CFG_SWAPUV);
  +   FMT(YVU420, 420,CFG_YUV2RGB);
  +   FMT(C8, PSEUDO8,0);
  +#undef FMT
  +   default:
  +   

Re: [PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

[Dave Airlie]

On Mon, Jul 1, 2013 at 10:17 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Mon, Jul 01, 2013 at 10:01:30AM +1000, Dave Airlie wrote:
 OMG I'm working in a subsystem where stuff is being developed, with only
 a few resources! I know my full time job isn't maintaining a 500,000
 line subsystem,
 and the sub maintainers and developers do a great job refactoring
 where required.

 lots of other driver authors have made substantial changes to the drm core as
 they've written drivers, you spot one bit of refactoring and its a
 major shortcoming
 of the entire subsystem and development community.

 how about instead of writing:
 However, at least I've taken the time to _think_ about what I'm doing
 and realise that there _is_ scope here for the DRM core to improve,
 rather than burying this stuff deep inside my driver like everyone else
 has.  That's no reason to penalise patches from the good guys who think

 you go with
 I noticed this piece of functionality could be refactored, here is a
 patch adding them to
 the core, does anyone think its a good idea?

 As Daniel pointed out every driver submitted has refactored things,
 even exynos did a
 lot of work to be the first ARM driver we shipped, the DRM core
 doesn't write itself and
 I fully expect driver authors to be the ones that tell me what needs
 refactoring, since
 they are on the pointy end, but to state that you are the only person
 ever to think about
 things is frankly being a dick.

 Lets try for less dick, and more productive in future.

 And you can stick your dick back where you got it from David.  Really,
 your response is totally uncalled for.

 Let's try realising that I only have very limited time to put into this
 and unlike the other submitters who have been _paid_ to get their code
 sorted, this is being done purely for free - which means it's really
 low priority.  As you should already realise because I've stated already
 that I *really* don't care whether it gets into mainline or not.

Really not every driver maintainer is paid to submit their drivers, if
you'd any clue
you'd understand that you aren't special. We currently have a number of non-paid
maintainer drivers being submitted and worked on, via for one, gma500
is maintain
in spare time, the tegra driver isn't purely a work of paid
dedication, I maintain
5 drivers currently, and I certainly don't do all of that in my day
job. Keeping attitude off
this list is what I do, I don't care if you don't appreciate the work
put in by other developers
to the drm subsystem, but I do and I won't have someone come in here
saying you guys
suck when clearly they've no historical perspective and as such are
plainly trolling.

Yes the DRM has growing pains, yes there is a lots of legacy shit in
the way of making
things clean, yes writing a driver for SoC is more painful than
necessary, but overall
its a majorly moving target, 5 years ago DRM/KMS hadn't considered ARM, now its
probably most of what we have to consider.

 If you want stuff to be refactored in DRM, you need to find someone
 with more time to do it.

I pointed out I didn't want stuff refactored, I wanted a driver author
to suggest
possible refactorings with a patch to add the interfaces, and suggest its a
good idea.

Split the patch, one to add the additions to the core without changing
anything, then just
have your driver use them. If other driver writes want to use them they'll
figure it out, and maybe someone else will go around and clean up the other
drivers.

I'm really hoping the OLPC guys pick up this work and care enough to
merge it, if not,
its a bit of a waste.

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

[Bug 65310] [regression] failure in building nvc0_vbo.lo: /tmp/cclDjdRp.s:1270: Error: missing or invalid displacement expression `-8589934576

[bugzilla-daemon]

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

--- Comment #2 from David Ronis david.ro...@mcgill.ca ---
This problem is still here.

-- 
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 66425] New: failed testing IB on ring 5 when suspending to disk

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 66425
  Assignee: dri-devel@lists.freedesktop.org
   Summary: failed testing IB on ring 5 when suspending to disk
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: austin.l...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: DRI CVS
 Component: DRM/Radeon
   Product: DRI

Created attachment 81770
  -- https://bugs.freedesktop.org/attachment.cgi?id=81770action=edit
Full log from suspend test

With kernel 3.10 suspend to disk seems to case a problem with my GPU.  I did
this to test suspend:

echo devices  /sys/power/pm_test
echo disk  /sys/power/state

It takes quite a while to return to the console and the system becomes
unstable.  Strangely suspend to ram doesn't seem to have any problems.

The relevant log lines seem to be:

PM: Allocated 2886788 kbytes in 0.39 seconds (7402.02 MB/s)
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
apple-gmux 00:07: System wakeup disabled by ACPI
radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00174118 and
cpu addr 0xc9001d233118
PM: freeze of devices complete after 292.114 msecs
hibernation debug: Waiting for 5 seconds.
[drm] Wrong MCH_SSKPD value: 0x16040307
[drm] This can cause pipe underruns and display issues.
[drm] Please upgrade your BIOS to fix this.
[drm] PCIE gen 2 link speeds already enabled
[drm] PCIE GART of 512M enabled (table at 0x00142000).
radeon :01:00.0: WB enabled
radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and
cpu addr 0x88025f328c00
radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and
cpu addr 0x88025f328c0c
radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00a9d118 and
cpu addr 0xc9001e3b2118
[drm] ring test on 0 succeeded in 2 usecs
[drm] ring test on 3 succeeded in 1 usecs
[drm] ring test on 5 succeeded in 1 usecs
[drm] UVD initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 1 usecs
radeon :01:00.0: GPU lockup CP stall for more than 1msec
radeon :01:00.0: GPU lockup (waiting for 0x0004 last fence id
0x0002)
[drm:r600_uvd_ib_test] *ERROR* radeon: fence wait failed (-35).
[drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35).

Full log attached.

$ uname -a
Linux lund-macbookpro 3.10.0+ #14 SMP PREEMPT Mon Jul 1 09:12:13 EST 2013
x86_64 GNU/Linux

(+ due to two patches which are unrelated to this driver, but otherwise vanilla
3.10)

$ sudo lspci -v -s 01:00.0
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] (prog-if 00 [VGA
controller])
Subsystem: Apple Inc. MacBookPro8,2 [Core i7, 15, Late 2011]
Flags: bus master, fast devsel, latency 0, IRQ 49
Memory at 9000 (64-bit, prefetchable) [size=256M]
Memory at b080 (64-bit, non-prefetchable) [size=128K]
I/O ports at 2000 [size=256]
Expansion ROM at b082 [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 ?
Capabilities: [150] Advanced Error Reporting
Kernel driver in use: radeon
Kernel modules: radeon

-- 
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/exynos: fix not to remain exynos_gem_obj as a leak

[Seung-Woo Kim]

From: YoungJun Cho yj44@samsung.com

The exynos_drm_gem_create() only calls drm_gem_object_release()
when exynos_drm_alloc_buf() is failed, and exynos_gem_obj remains
as a leak, which is allocated in exynos_drm_gem_init().
So this patch fixes it not to remain as a leak.

Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
This patch is based on exynos-drm-next branch.

 drivers/gpu/drm/exynos/exynos_drm_gem.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index c3f15e7..24c22a8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -246,13 +246,14 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct 
drm_device *dev,
exynos_gem_obj-flags = flags;
 
ret = exynos_drm_alloc_buf(dev, buf, flags);
-   if (ret  0) {
-   drm_gem_object_release(exynos_gem_obj-base);
-   goto err_fini_buf;
-   }
+   if (ret  0)
+   goto err_gem_fini;
 
return exynos_gem_obj;
 
+err_gem_fini:
+   drm_gem_object_release(exynos_gem_obj-base);
+   kfree(exynos_gem_obj);
 err_fini_buf:
exynos_drm_fini_buf(dev, buf);
return ERR_PTR(ret);
-- 
1.7.9.5

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

unsubscribe

[Hyma Y V S]

Hi,

I want to unsubscribe from the mailing list.

Thanks,
Hyma

 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are 
not
to copy, disclose, or distribute this e-mail or its contents to any other 
person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has 
taken
every reasonable precaution to minimize this risk, but is not liable for any 
damage
you may sustain as a result of any virus in this e-mail. You should carry out 
your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this 
e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/exynos: remove dead code in vidi_power_on

[Seung-Woo Kim]

From: YoungJun Cho yj44@samsung.com

The type of input parameter enable is bool, so it does not need
to check whether true or false.

Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 784bbce..41cc74d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -413,9 +413,6 @@ static int vidi_power_on(struct vidi_context *ctx, bool 
enable)
struct exynos_drm_subdrv *subdrv = ctx-subdrv;
struct device *dev = subdrv-dev;
 
-   if (enable != false  enable != true)
-   return -EINVAL;
-
if (enable) {
ctx-suspended = false;
 
-- 
1.7.9.5

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

[PATCH 2/2] drm/exynos: initialize the buf_num in vp_video_buffer

[Seung-Woo Kim]

From: YoungJun Cho yj44@samsung.com

The buf_num in vp_video_buffer() should be 1 or 2, but it is not
initialized, and only set to 2 in NV12M or NV12MT cases.
So this patch initializes the buf_num with 1 as default.

Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_mixer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index b1280b4..42ffb71 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -379,7 +379,7 @@ static void vp_video_buffer(struct mixer_context *ctx, int 
win)
unsigned long flags;
struct hdmi_win_data *win_data;
unsigned int x_ratio, y_ratio;
-   unsigned int buf_num;
+   unsigned int buf_num = 1;
dma_addr_t luma_addr[2], chroma_addr[2];
bool tiled_mode = false;
bool crcb_mode = false;
-- 
1.7.9.5

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

[Bug 66337] evergreen_compute.c:559:26: error: 'kernel' undeclared (first use in this function) shader-active_kernel = kernel;

[bugzilla-daemon]

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

Vinson Lee v...@freedesktop.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Vinson Lee v...@freedesktop.org ---
Fixed by 47e35eff9dec8666efd70ffd08e4b03f83215026.

commit 47e35eff9dec8666efd70ffd08e4b03f83215026
Author: Tom Stellard thomas.stell...@amd.com
Date:   Fri Jun 28 11:08:07 2013 -0700

r600g: Fix build

Broken since 2840bec56f79347b95dec5458b20d4a46d1aa445 when opencl is
disabled.

-- 
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/qxl: make dynamic resizing work properly.

[Dave Airlie]

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

qxl has a feature to allow the userspace driver do arbitrary resizes
when the viewer resizes, this fixes it by removing unnecessary code
from the kernel side.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/qxl/qxl_display.c | 58 ++-
 1 file changed, 3 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 823d29e..4cb36bb 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -30,55 +30,6 @@
 #include qxl_object.h
 #include drm_crtc_helper.h
 
-static void qxl_crtc_set_to_mode(struct qxl_device *qdev,
-struct drm_connector *connector,
-struct qxl_head *head)
-{
-   struct drm_device *dev = connector-dev;
-   struct drm_display_mode *mode, *t;
-   int width = head-width;
-   int height = head-height;
-
-   if (width  320 || height  240) {
-   qxl_io_log(qdev, %s: bad head: %dx%d, width, height);
-   width = 1024;
-   height = 768;
-   }
-   if (width * height * 4  16*1024*1024) {
-   width = 1024;
-   height = 768;
-   }
-   /* TODO: go over regular modes and removed preferred? */
-   list_for_each_entry_safe(mode, t, connector-probed_modes, head)
-   drm_mode_remove(connector, mode);
-   mode = drm_cvt_mode(dev, width, height, 60, false, false, false);
-   mode-type |= DRM_MODE_TYPE_PREFERRED;
-   mode-status = MODE_OK;
-   drm_mode_probed_add(connector, mode);
-   qxl_io_log(qdev, %s: %d x %d\n, __func__, width, height);
-}
-
-void qxl_crtc_set_from_monitors_config(struct qxl_device *qdev)
-{
-   struct drm_connector *connector;
-   int i;
-   struct drm_device *dev = qdev-ddev;
-
-   i = 0;
-   qxl_io_log(qdev, %s: %d, %d\n, __func__,
-  dev-mode_config.num_connector,
-  qdev-monitors_config-count);
-   list_for_each_entry(connector, dev-mode_config.connector_list, head) {
-   if (i  qdev-monitors_config-count) {
-   /* crtc will be reported as disabled */
-   continue;
-   }
-   qxl_crtc_set_to_mode(qdev, connector,
-qdev-monitors_config-heads[i]);
-   ++i;
-   }
-}
-
 void qxl_alloc_client_monitors_config(struct qxl_device *qdev, unsigned count)
 {
if (qdev-client_monitors_config 
@@ -117,8 +68,8 @@ static int 
qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
return 1;
}
if (num_monitors  qdev-monitors_config-max_allowed) {
-   DRM_INFO(client monitors list will be truncated: %d  %d\n,
-qdev-monitors_config-max_allowed, num_monitors);
+   DRM_DEBUG_KMS(client monitors list will be truncated: %d  
%d\n,
+ qdev-monitors_config-max_allowed, num_monitors);
num_monitors = qdev-monitors_config-max_allowed;
} else {
num_monitors = qdev-rom-client_monitors_config.count;
@@ -142,7 +93,7 @@ static int 
qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
client_head-surface_id = head-surface_id = 0;
client_head-id = head-id = i;
client_head-flags = head-flags = 0;
-   QXL_DEBUG(qdev, read %dx%d+%d+%d\n, head-width, head-height,
+   DRM_DEBUG_KMS(read %dx%d+%d+%d\n, head-width, head-height,
  head-x, head-y);
}
return 0;
@@ -155,9 +106,6 @@ void qxl_display_read_client_monitors_config(struct 
qxl_device *qdev)
qxl_io_log(qdev, failed crc check for client_monitors_config,
  retrying\n);
}
-   qxl_crtc_set_from_monitors_config(qdev);
-   /* fire off a uevent and let userspace tell us what to do */
-   qxl_io_log(qdev, calling drm_sysfs_hotplug_event\n);
drm_sysfs_hotplug_event(qdev-ddev);
 }
 
-- 
1.8.3.1

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