[pull] fb helper cleanups
Hi Dave, [Andrew: Pull contains the patch "drm/fb-helper: don't sleep for screen unblank when an oopps is in progress" which is also in your tree, hence the cc.] I've figured a pull request is easier to handle ;-) This is the drm fb helper cleanup, mostly motivated by strange things I've seen in my locking rework and the i915 modeset revamp. Compared to the original submission I've reinstated the setup flexibility you'd like to retain, kerneldoc has been reviewed by Laurent Pinchart and Rob Clark reviewed the code changes. Quick overview of the changes: - Cleaned-up library interface for drivers using the fb helper, also simplified the fb allocation callback since no driver supported reallocating the fb on-the-fly. And the fbdev/fbcon code keeps pointers to the old mapping around anyway, so reallocating backing storage will be much more work. - No longer call the crtc helper "disable everything" function at init time, but allow drivers to do so. Motivated by i915's fastboot effort and allows us to drop a bunch of noop dummy functions just to avoid calling NULL function pointers from i915.ko. - Properly clear old state when doing modeset calls, the fb helper left some old modes in there and unconditionally set an fb (even when disabling a crtc). The crtc helpers didn't care, but i915 modeset code can now drop a few special cases. - Full kerneldoc for the fb helper. Yay! - My version of the "don't sleep in panic ->unblank calls". The patch is already in -mm, I guess Andrew can drop it as soon as this pull lands in drm-next. Imo the fb helper looks now rather nice, and there's only a few pieces left to fix up further: - Removing the duplicated gamma handling. - Reviewing the locking in the panic/sysrq/kgdb handlers some more. - Maybe move some function pointers only used by the fb helper from the crtc helper structs to the fb helper structs. Currently those vtable misplacements are the last thing tying fb/crtc helpers together. - Locking around init/teardown still looks a bit fishy. But that ties into the console_lock madness, so I'm not volunteering ;-) Cheers, Daniel The following changes since commit b9e5071386007729110e86fd2c55c687085624e3: Merge branch 'for-airlied' of git://people.freedesktop.org/~mlankhorst/linux into drm-next (2013-02-08 14:02:32 +1000) are available in the git repository at: git://people.freedesktop.org/~danvet/drm drm-fb-helper for you to fetch changes up to a065b46a01b25d7d364e01e75f7ec2bd9ed5d9cb: drm/fb-helper: remove unused members of struct drm_fb_helper (2013-02-14 00:08:41 +0100) Daniel Vetter (14): drm: review locking for drm_fb_helper_restore_fbdev_mode drm/fb-helper: kill drm_fb_helper_restore drm/fb-helper: unexport drm_fb_helper_panic drm/fb-helper: unexport drm_fb_helper_single_fb_probe drm/tegra: don't set up initial fbcon config twice drm/fb-helper: don't disable everything in initial_config drm/i915: rip out helper->disable noop functions drm/fb-helper: fixup set_config semantics drm/fb-helper: directly call set_par from the hotplug handler drm/fb-helper: streamline drm_fb_helper_single_fb_probe drm/: simplify ->fb_probe callback drm/fb-helper: improve kerneldoc drm/fb-helper: don't sleep for screen unblank when an oopps is in progress drm/fb-helper: remove unused members of struct drm_fb_helper Documentation/DocBook/drm.tmpl|1 + drivers/gpu/drm/ast/ast_fb.c | 26 +-- drivers/gpu/drm/cirrus/cirrus_fbdev.c | 26 +-- drivers/gpu/drm/drm_crtc.c| 16 +- drivers/gpu/drm/drm_fb_cma_helper.c | 22 +-- drivers/gpu/drm/drm_fb_helper.c | 251 +++-- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 35 +--- drivers/gpu/drm/gma500/framebuffer.c | 14 +- drivers/gpu/drm/i915/intel_crt.c |1 - drivers/gpu/drm/i915/intel_ddi.c |1 - drivers/gpu/drm/i915/intel_display.c | 20 +-- drivers/gpu/drm/i915/intel_dp.c |1 - drivers/gpu/drm/i915/intel_drv.h |1 - drivers/gpu/drm/i915/intel_dvo.c |1 - drivers/gpu/drm/i915/intel_fb.c | 21 +-- drivers/gpu/drm/i915/intel_hdmi.c |1 - drivers/gpu/drm/i915/intel_lvds.c |1 - drivers/gpu/drm/i915/intel_sdvo.c |1 - drivers/gpu/drm/i915/intel_tv.c |1 - drivers/gpu/drm/mgag200/mgag200_fb.c | 27 +--- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 25 +-- drivers/gpu/drm/radeon/radeon_fb.c| 25 +-- drivers/gpu/drm/tegra/fb.c|4 - drivers/gpu/drm/udl/udl_fb.c | 26 +-- drivers/staging/omapdrm/omap_fbdev.c | 21 +-- include/drm/drm_crtc.h|1 + include/drm/drm_fb_helper.h | 18 ++- 27 files changed, 298 insertions(+), 290
Re: [Linaro-mm-sig] [PATCH 2/3] mutex: add support for reservation style locks
On Thursday 07 February 2013, Maarten Lankhorst wrote:
Hi Maarten,
I cannot help a lot on this patch set, but there are a few things that
I noticed when reading it.
> Functions:
> --
>
> mutex_reserve_lock, and mutex_reserve_lock_interruptible:
> Lock a buffer with a reservation_id set. reservation_id must not be
> set to 0, since this is a special value that means no reservation_id.
I think the entire description should go into a file in the Documentation
directory, to make it easier to find without looking up the git history.
For the purpose of documenting this, it feels a little strange to
talk about "buffers" here. Obviously this is what you are using the
locks for, but it sounds like that is not the only possible use
case.
> These functions will return -EDEADLK instead of -EAGAIN if
> reservation_id is the same as the reservation_id that's attempted to
> lock the mutex with, since in that case you presumably attempted to
> lock the same lock twice.
Since the user always has to check the return value, would it be
possible to provide only the interruptible kind of this function
but not the non-interruptible one? In general, interruptible locks
are obviously harder to use, but they are much user friendlier when
something goes wrong.
> mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
> Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN.
> This is useful when mutex_reserve_lock failed with -EAGAIN, and you
> unreserved all buffers so no deadlock can occur.
Are these meant to be used a lot? If not, maybe prefix them with __mutex_
instead of mutex_.
> diff --git a/include/linux/mutex.h b/include/linux/mutex.h
> index 9121595..602c247 100644
> --- a/include/linux/mutex.h
> +++ b/include/linux/mutex.h
> @@ -62,6 +62,11 @@ struct mutex {
> #endif
> };
>
> +struct ticket_mutex {
> + struct mutex base;
> + atomic_long_t reservation_id;
> +};
Have you considered changing the meaning of the "count" member
of the mutex in the case where a ticket mutex is used? That would
let you use an unmodified structure.
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 --- Comment #6 from Wojciech Pyczak --- I'm currently using latest version (cb4616d3) and the issue is gone. -- 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: [Linaro-mm-sig] [PATCH 2/3] mutex: add support for reservation style locks
On Thu, Feb 14, 2013 at 11:22 AM, Arnd Bergmann wrote: > >> These functions will return -EDEADLK instead of -EAGAIN if >> reservation_id is the same as the reservation_id that's attempted to >> lock the mutex with, since in that case you presumably attempted to >> lock the same lock twice. > > Since the user always has to check the return value, would it be > possible to provide only the interruptible kind of this function > but not the non-interruptible one? In general, interruptible locks > are obviously harder to use, but they are much user friendlier when > something goes wrong. At least in drm/i915 we only use _interruptible locking on the command-submission ioctls for all locks which could be held while waiting for the gpu. We need unwind paths and ioctl restarting anyway to bail out on catastrophic events like gpu hangs, so signal interrupt handling comes for free. Otoh in the modeset code we generally don't bother with that, since unwinding a modeset sequence mid-way is something you don't want to do really if your sanity is dear to you. But we also never need mutli-object reservations in the modeset code, neither can I imagine a future need for it. So from my side we could drop the non-interruptible interface. But I have not checked whether dropping this would complicate the ttm conversion. >> mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow: >> Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN. >> This is useful when mutex_reserve_lock failed with -EAGAIN, and you >> unreserved all buffers so no deadlock can occur. > > Are these meant to be used a lot? If not, maybe prefix them with __mutex_ > instead of mutex_. If you detect an inversion in a multi-buffer reservation you have to drop all locks and call these functions on the buffer which failed (that's the contention point, hence it's the right lock to sleep on). So every place using ticket locks will also call the above slowpath functions by necessity. -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
[PATCH] omapdrm: Make fixed resolution panels work
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following things are done to make fixed panels work:
- The omap_connector's detect function is modified such that it considers panel
types which are generally fixed panels as always connected(provided the panel
driver doesn't have a detect op). Hence, the connector corresponding to these
panels is always in a 'connected' state.
- If a panel driver doesn't have a check_timings op, assume that it supports the
mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function)
- The function omap_encoder_update shouldn't really do anything for fixed
resolution panels, make sure that it calls set_timings only if the panel
driver has one.
I tested this with picodlp on a OMAP4 sdp board. I couldn't get any other
working boards with fixed DPI panels. I could try the DSI video mode panel
on an OMAP5 sevm, but that will require me to patch a lot of things to get
omap5 dss work with DT. I can try if needed.
Signed-off-by: Archit Taneja
---
drivers/staging/omapdrm/omap_connector.c | 10 --
drivers/staging/omapdrm/omap_encoder.c |6 --
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_connector.c
b/drivers/staging/omapdrm/omap_connector.c
index 4cc9ee7..839c6e4 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+ } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
+ ret = connector_status_connected;
} else {
ret = connector_status_unknown;
}
@@ -189,12 +194,13 @@ static int omap_connector_mode_valid(struct drm_connector
*connector,
struct omap_video_timings timings = {0};
struct drm_device *dev = connector->dev;
struct drm_display_mode *new_mode;
- int ret = MODE_BAD;
+ int r, ret = MODE_BAD;
copy_timings_drm_to_omap(&timings, mode);
mode->vrefresh = drm_mode_vrefresh(mode);
- if (!dssdrv->check_timings(dssdev, &timings)) {
+ r = dssdrv->check_timings ? dssdrv->check_timings(dssdev, &timings) : 0;
+ if (!r) {
/* check if vrefresh is still valid */
new_mode = drm_mode_duplicate(dev, mode);
new_mode->clock = timings.pixel_clock;
diff --git a/drivers/staging/omapdrm/omap_encoder.c
b/drivers/staging/omapdrm/omap_encoder.c
index e053160..871af12e 100644
--- a/drivers/staging/omapdrm/omap_encoder.c
+++ b/drivers/staging/omapdrm/omap_encoder.c
@@ -128,13 +128,15 @@ int omap_encoder_update(struct drm_encoder *encoder,
dssdev->output->manager = mgr;
- ret = dssdrv->check_timings(dssdev, timings);
+ ret = dssdrv->check_timings ?
+ dssdrv->check_timings(dssdev, timings) : 0;
if (ret) {
dev_err(dev->dev, "could not set timings: %d\n", ret);
return ret;
}
- dssdrv->set_timings(dssdev, timings);
+ if (dssdrv->set_timings)
+ dssdrv->set_timings(dssdev, timings);
return 0;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Set i9xx lvds clock limits according to specifications
On Wed, Feb 13, 2013 at 10:20:21PM +0100, Patrik Jakobsson wrote: > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and > 5-9. > Since we do all calculations based on them being register values (which are > subtracted by 2) we need to specify them accordingly. > > Signed-off-by: Patrik Jakobsson Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Including drm-intel tree to linux-next
Hi Steven, Since about a year ago we've switched drm/i915 to buffer around 2 weeks worth of patches so that we can do decent QA before breaking everyone's tree when things land in Dave's drm-next. But that also means we'll miss out a bit in the integration testing -next provides, which did hurt a bit in recent efforts. Hence can you please include git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued into linux-next? Probably best to merge it after drm-next. Note that drm-intel-next are the QA'ed chunks I send off to Dave. Also, any mailing lists I'm supposed to follow? And if possible please cc intel-...@lists.freedesktop.org besides dri-devel/lkml when conflicts with that tree pop up (you won't get moderation spam any more, we've fixed that up). 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: CDF meeting @FOSDEM report
On 2013-02-13 00:45, Stéphane Marchesin wrote: > So, a part which is completely omitted in this thread is how to handle > suspend/resume ordering. If you have multiple encoders which need to > be turned on/off in a given order at suspend/resume, how do you handle > that given the current scheme where they are just separate platform > drivers in drivers/video? > > This problems occurs with drm/exynos in current 3.8 kernels for > example. On that platform, the DP driver and the FIMD driver will > suspend/resume in random order, and therefore fail resuming half the > time. Is there something which could be done in CDF to address that? I don't think we have a perfect solution for this, but I think we can handle this by using PM notifiers, PM_SUSPEND_PREPARE and PM_POST_SUSPEND. The code that manages the whole chain should register to those notifiers, and disable or enable the display devices accordingly. This way the devices are enabled and disabled in the right order, and also (hopefully) so that the control busses are operational. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 3/3] video: exynos: Making s6e8ax0 panel driver compliant with CDF
Hi Mr. Lee,
thanks for the review.
On 14 February 2013 07:30, Donghwa Lee wrote:
> On Wed, Feb 13, 2013 at 19:01, Vikas Sajjan wrote:
>>
>> Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
>> It also removes the dependency on backlight and lcd framework
>>
>> Signed-off-by: Vikas Sajjan
>> ---
>> drivers/video/exynos/s6e8ax0.c | 848
>> +---
>> 1 file changed, 444 insertions(+), 404 deletions(-)
>>
>> diff --git a/drivers/video/exynos/s6e8ax0.c
>> b/drivers/video/exynos/s6e8ax0.c
>> index 7f7b25f..5a17e3c 100644
>> --- a/drivers/video/exynos/s6e8ax0.c
>> +++ b/drivers/video/exynos/s6e8ax0.c
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> +#include
>> #include
>> #include
>> @@ -38,8 +39,7 @@
>> #define POWER_IS_OFF(pwr) ((pwr) == FB_BLANK_POWERDOWN)
>> #define POWER_IS_NRM(pwr) ((pwr) == FB_BLANK_NORMAL)
>> -#define lcd_to_master(a) (a->dsim_dev->master)
>> -#define lcd_to_master_ops(a) ((lcd_to_master(a))->master_ops)
>> +#define to_panel(p) container_of(p, struct s6e8ax0, entity)
>> enum {
>> DSIM_NONE_STATE = 0,
>> @@ -47,20 +47,34 @@ enum {
>> DSIM_FRAME_DONE = 2,
>> };
>> +/* This structure defines all the properties of a backlight */
>> +struct backlight_prop {
>> + /* Current User requested brightness (0 - max_brightness) */
>> + int brightness;
>> + /* Maximal value for brightness (read-only) */
>> + int max_brightness;
>> +};
>> +
>> +struct panel_platform_data {
>> + unsigned intreset_delay;
>> + unsigned intpower_on_delay;
>> + unsigned intpower_off_delay;
>> + const char *video_source_name;
>> +};
>> +
>> struct s6e8ax0 {
>> - struct device *dev;
>> - unsigned intpower;
>> - unsigned intid;
>> - unsigned intgamma;
>> - unsigned intacl_enable;
>> - unsigned intcur_acl;
>> -
>> - struct lcd_device *ld;
>> - struct backlight_device *bd;
>> -
>> - struct mipi_dsim_lcd_device *dsim_dev;
>> - struct lcd_platform_data*ddi_pd;
>> + struct platform_device *pdev;
>> + struct video_source *src;
>> + struct display_entity entity;
>> + unsigned intpower;
>> + unsigned intid;
>> + unsigned intgamma;
>> + unsigned intacl_enable;
>> + unsigned intcur_acl;
>> + boolpanel_reverse;
>> + struct lcd_platform_data*plat_data;
>> struct mutexlock;
>> + struct backlight_prop bl_prop;
>> bool enabled;
>> };
>>
>
> Could this panel driver use only CDF?
> Does not consider the compatibility with backlight and lcd framework?
>
as of now CDF does not support backlight and lcd framework functionalities.
Once CDF has the support, we modify the driver to support both CDF and
non CDF way, there by maintaining the backward compatibility with
backlight and lcd framework.
>> -static const unsigned char s6e8ax0_22_gamma_30[] = {
>> +static unsigned char s6e8ax0_22_gamma_30[] = {
>> 0xfa, 0x01, 0x60, 0x10, 0x60, 0xf5, 0x00, 0xff, 0xad, 0xaf,
>> 0xbA, 0xc3, 0xd8, 0xc5, 0x9f, 0xc6, 0x9e, 0xc1, 0xdc, 0xc0,
>> 0x00, 0x61, 0x00, 0x5a, 0x00, 0x74,
>> };
>
> In all case, you had changed data type to 'static unsigned char'.
> Is it need to change all case? Otherwise, for the unity of the code?
in the CDF-T proposed by Mr. Tomi Valkeinen, the prototype for
"dcs_write" looks as below
int (*dcs_write)(struct video_source *src, int channel, u8 *data, size_t len);
It does not have "const" for the 3rd parameter (u8 *data ), and in our
driver we have all the arrays as "const".
Just to silence the compiler warnings, i had removed the "const" keyword.
>
>
> Thank you,
> Donghwa Lee
>
>
--
Thanks and Regards
Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: modify condition in mixer and hdmi resume
From: Prathyush K
If mixer is runtime suspended (by DPMS OFF), mixer_suspend
does not call mixer_poweroff and just returns. Similarily the
mixer_resume should not resume the mixer if mixer is
runtime_suspended. It should be done through DPMS ON.
The existing check is stopping the resume. This issue is fixed
by reversing the condiftion. It also holds good for hdmi driver.
Inline with
http://lists.freedesktop.org/archives/dri-devel/2013-January/032920.html.
Signed-off-by: Prathyush K
Signed-off-by: Rahul Sharma
---
It is based on exynos-drm-next-todo branch at
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9e3c2ad..273a6ea 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2386,7 +2386,7 @@ static int hdmi_resume(struct device *dev)
enable_irq(hdata->external_irq);
enable_irq(hdata->internal_irq);
- if (!pm_runtime_suspended(dev)) {
+ if (pm_runtime_suspended(dev)) {
DRM_DEBUG_KMS("%s : Already resumed\n", __func__);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 5139a43..6404f7e4 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1265,7 +1265,7 @@ static int mixer_resume(struct device *dev)
DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
- if (!pm_runtime_suspended(dev)) {
+ if (pm_runtime_suspended(dev)) {
DRM_DEBUG_KMS("%s : Already resumed\n", __func__);
return 0;
}
--
1.8.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH 2/3] mutex: add support for reservation style locks
Hey,
Op 14-02-13 11:22, Arnd Bergmann schreef:
> On Thursday 07 February 2013, Maarten Lankhorst wrote:
>
> Hi Maarten,
>
> I cannot help a lot on this patch set, but there are a few things that
> I noticed when reading it.
>
>> Functions:
>> --
>>
>> mutex_reserve_lock, and mutex_reserve_lock_interruptible:
>> Lock a buffer with a reservation_id set. reservation_id must not be
>> set to 0, since this is a special value that means no reservation_id.
> I think the entire description should go into a file in the Documentation
> directory, to make it easier to find without looking up the git history.
>
> For the purpose of documenting this, it feels a little strange to
> talk about "buffers" here. Obviously this is what you are using the
> locks for, but it sounds like that is not the only possible use
> case.
It is the idea it will end up in Documentation, however I had a hard time even
getting people to
review the code, so I found it easier to keep code and documentation in sync by
keeping it into
the commit log when I was amending things.
But yes it's the use case I use it for. The generic use case would be if you
had a number of equal
locks you want to take in an arbitrary order without deadlocking or a lock
protecting all those locks*.
*) In the eyes of lockdep you still take one of those locks, and nest all those
locks you take into that lock.
>> These functions will return -EDEADLK instead of -EAGAIN if
>> reservation_id is the same as the reservation_id that's attempted to
>> lock the mutex with, since in that case you presumably attempted to
>> lock the same lock twice.
> Since the user always has to check the return value, would it be
> possible to provide only the interruptible kind of this function
> but not the non-interruptible one? In general, interruptible locks
> are obviously harder to use, but they are much user friendlier when
> something goes wrong.
I agree that in general you want to use the interruptible versions as much as
possible,
but there are some cases in ttm where it is desirable to lock non-interruptibly.
>> mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
>> Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN.
>> This is useful when mutex_reserve_lock failed with -EAGAIN, and you
>> unreserved all buffers so no deadlock can occur.
> Are these meant to be used a lot? If not, maybe prefix them with __mutex_
> instead of mutex_.
It is a common path in case of contestion. The example lock_execbuf from the
commit log used
it. When you use the mutex_reserve_lock calls, you'll have to add calls to the
*_slow variants
too when those return -EAGAIN.
>> diff --git a/include/linux/mutex.h b/include/linux/mutex.h
>> index 9121595..602c247 100644
>> --- a/include/linux/mutex.h
>> +++ b/include/linux/mutex.h
>> @@ -62,6 +62,11 @@ struct mutex {
>> #endif
>> };
>>
>> +struct ticket_mutex {
>> +struct mutex base;
>> +atomic_long_t reservation_id;
>> +};
> Have you considered changing the meaning of the "count" member
> of the mutex in the case where a ticket mutex is used? That would
> let you use an unmodified structure.
I have considered it, but I never found a good way to make that happen.
mutex_lock and mutex_unlock are currently still used when only a single
buffer needs to be locked.
Thanks for the review!
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Including drm-intel tree to linux-next
On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote: > Hi Steven, > > Since about a year ago we've switched drm/i915 to buffer around 2 > weeks worth of patches so that we can do decent QA before breaking > everyone's tree when things land in Dave's drm-next. But that also > means we'll miss out a bit in the integration testing -next provides, > which did hurt a bit in recent efforts. Hence can you please include > > git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued > > into linux-next? Probably best to merge it after drm-next. Note that > drm-intel-next are the QA'ed chunks I send off to Dave. Also, any > mailing lists I'm supposed to follow? And if possible please cc > intel-...@lists.freedesktop.org besides dri-devel/lkml when conflicts > with that tree pop up (you won't get moderation spam any more, we've > fixed that up). I think you want to send this here to Stephen Rothwell. CCed. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Including drm-intel tree to linux-next
On Thu, Feb 14, 2013 at 3:28 PM, Steven Rostedt wrote: > On Thu, 2013-02-14 at 15:19 +0100, Borislav Petkov wrote: >> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote: >> > Hi Steven, >> > >> > Since about a year ago we've switched drm/i915 to buffer around 2 >> > weeks worth of patches so that we can do decent QA before breaking >> > everyone's tree when things land in Dave's drm-next. But that also >> > means we'll miss out a bit in the integration testing -next provides, >> > which did hurt a bit in recent efforts. Hence can you please include >> > >> > git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued >> > >> > into linux-next? Probably best to merge it after drm-next. Note that >> > drm-intel-next are the QA'ed chunks I send off to Dave. Also, any >> > mailing lists I'm supposed to follow? And if possible please cc >> > intel-...@lists.freedesktop.org besides dri-devel/lkml when conflicts >> > with that tree pop up (you won't get moderation spam any more, we've >> > fixed that up). >> >> I think you want to send this here to Stephen Rothwell. CCed. >> > > This is why I tell people to call me Steve or Steven, but never Stephen, > otherwise people might confuse me with one of the Stephens that also do > kernel development. > > Note, this is not the first time I've been confused with someone else. > So don't feel bad ;-) Oops, indeed picked the wrong mail from my sea of "drm/i915 broke stuff, again" mails ;-) Sorry for the noise, Steve. -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
[Bug 60848] New: [bisected] r600g: add htile support cause gpu lockup in Dishonored wine.
https://bugs.freedesktop.org/show_bug.cgi?id=60848 Priority: medium Bug ID: 60848 Assignee: dri-devel@lists.freedesktop.org Summary: [bisected] r600g: add htile support cause gpu lockup in Dishonored wine. Severity: normal Classification: Unclassified OS: Linux (All) Reporter: thomas.lindr...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 74826 --> https://bugs.freedesktop.org/attachment.cgi?id=74826&action=edit dmesg, xorg.log Commit 6532eb17baff6e61b427f29e076883f8941ae664 r600g: add htile support v16 cause a gpu lockup on juniper with Dishonored in wine. https://www.dropbox.com/s/7w140vtr48xb8vt/Dishonored.trace.bz2 this trace reproduce the error. bug #59592 is similar but I should be using the fix from that bug already. mesa, libdrm, xf86-video-ati and linus kernel are all git from yesterday. 3.0 Mesa 9.2-devel (git-ce3dfa1) Option "ColorTiling" "true" Option "ColorTiling2D" "true" Option "SwapbuffersWait" "false" Option "EnablePageFlip" "true" configure --disable-dependency-tracking --enable-dri --enable-glx --enable-texture-float --disable-debug --enable-egl --disable-gbm --disable-gles1 --disable-gles2 --enable-glx-tls --disable-osmesa --enable-asm --enable-shared-glapi --with-dri-drivers= --with-gallium-drivers=,swrast,r600 --with-egl-platforms=x11 --enable-gallium-egl --disable-d3d1x --disable-gallium-g3dvl --enable-gallium-llvm --disable-openvg --disable-vdpau --disable-xvmc --enable-shared-dricore -- 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 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jerome Glisse --- Ok closing -- 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 60848] [bisected] r600g: add htile support cause gpu lockup in Dishonored wine.
https://bugs.freedesktop.org/show_bug.cgi?id=60848 --- Comment #1 from Jerome Glisse --- Does it happen without --enable-gallium-llvm also does it happen when running with R600_HTILE=0 env variable ? -- 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] omapdrm: Make fixed resolution panels work
On Thu, Feb 14, 2013 at 6:52 AM, Archit Taneja wrote:
> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
> and SDI drivers. At some places, there are no checks to see if the panel
> driver
> has these ops or not, and that leads to a crash.
>
> The following things are done to make fixed panels work:
>
> - The omap_connector's detect function is modified such that it considers
> panel
> types which are generally fixed panels as always connected(provided the
> panel
> driver doesn't have a detect op). Hence, the connector corresponding to
> these
> panels is always in a 'connected' state.
>
> - If a panel driver doesn't have a check_timings op, assume that it supports
> the
> mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper
> function)
>
> - The function omap_encoder_update shouldn't really do anything for fixed
> resolution panels, make sure that it calls set_timings only if the panel
> driver has one.
>
> I tested this with picodlp on a OMAP4 sdp board. I couldn't get any other
> working boards with fixed DPI panels. I could try the DSI video mode panel
> on an OMAP5 sevm, but that will require me to patch a lot of things to get
> omap5 dss work with DT. I can try if needed.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/staging/omapdrm/omap_connector.c | 10 --
> drivers/staging/omapdrm/omap_encoder.c |6 --
> 2 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/omapdrm/omap_connector.c
> b/drivers/staging/omapdrm/omap_connector.c
> index 4cc9ee7..839c6e4 100644
> --- a/drivers/staging/omapdrm/omap_connector.c
> +++ b/drivers/staging/omapdrm/omap_connector.c
> @@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
> ret = connector_status_connected;
> else
> ret = connector_status_disconnected;
> + } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
> + dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
> + dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
> + dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
> + ret = connector_status_connected;
hmm, why not just have a default detect fxn for panel drivers which
always returns true? Seems a bit cleaner.. otherwise, I guess we
could just change omap_connector so that if dssdev->detect is null,
assume always connected. Seems maybe a slightly better way since
currently omap_connector doesn't really know too much about different
sorts of panels. But I'm not too picky if that is a big pain because
we probably end up changing all this as CFP starts coming into
existence.
Same goes for check_timings/set_timings.. it seems a bit cleaner just
to have default fxns in the panel drivers that do-the-right-thing,
although I suppose it might be a bit more convenient for out-of-tree
panel drivers to just assume fixed panel if these fxns are null.
BR,
-R
> } else {
> ret = connector_status_unknown;
> }
> @@ -189,12 +194,13 @@ static int omap_connector_mode_valid(struct
> drm_connector *connector,
> struct omap_video_timings timings = {0};
> struct drm_device *dev = connector->dev;
> struct drm_display_mode *new_mode;
> - int ret = MODE_BAD;
> + int r, ret = MODE_BAD;
>
> copy_timings_drm_to_omap(&timings, mode);
> mode->vrefresh = drm_mode_vrefresh(mode);
>
> - if (!dssdrv->check_timings(dssdev, &timings)) {
> + r = dssdrv->check_timings ? dssdrv->check_timings(dssdev, &timings) :
> 0;
> + if (!r) {
> /* check if vrefresh is still valid */
> new_mode = drm_mode_duplicate(dev, mode);
> new_mode->clock = timings.pixel_clock;
> diff --git a/drivers/staging/omapdrm/omap_encoder.c
> b/drivers/staging/omapdrm/omap_encoder.c
> index e053160..871af12e 100644
> --- a/drivers/staging/omapdrm/omap_encoder.c
> +++ b/drivers/staging/omapdrm/omap_encoder.c
> @@ -128,13 +128,15 @@ int omap_encoder_update(struct drm_encoder *encoder,
>
> dssdev->output->manager = mgr;
>
> - ret = dssdrv->check_timings(dssdev, timings);
> + ret = dssdrv->check_timings ?
> + dssdrv->check_timings(dssdev, timings) : 0;
> if (ret) {
> dev_err(dev->dev, "could not set timings: %d\n", ret);
> return ret;
> }
>
> - dssdrv->set_timings(dssdev, timings);
> + if (dssdrv->set_timings)
> + dssdrv->set_timings(dssdev, timings);
>
> return 0;
> }
> --
> 1.7.9.5
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: gl.h: Version mumbo-jumbo and Copyright?
On 02/14/2013 01:10 PM, Sedat Dilek wrote: Hi, noticed when polishing up my build-scripts fot libdrm | mesa | xf86-video-intel (last one requires gl.h). /* * Mesa 3-D graphics library * Version: 7.6<--- ??? I could remove that obsolete line. * * Copyright (C) 1999-2006 Brian Paul All Rights Reserved.<--- ??? * Copyright (C) 2009 VMware, Inc. All Rights Reserved. What's the question there? -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] [media] s5p-g2d: Add DT based discovery support
On Thursday, 14 February 2013, Sylwester Nawrocki <
sylvester.nawro...@gmail.com> wrote:
> On 02/12/2013 06:30 PM, Sachin Kamat wrote:
>>
>> Hi Sylwester,
>>
>> On Wednesday, 6 February 2013, Sachin Kamat
wrote:
>>>
>>> This patch adds device tree based discovery support to G2D driver
>>>
>>> Signed-off-by: Sachin Kamat
>>> ---
>>> Based on for_v3.9 branch of below tree:
>>> git://linuxtv.org/snawrocki/samsung.git
>>>
>>> Changes since v1:
>>> * Addressed review comments from Sylwester .
>>> * Modified the compatible string as per the discussions at [1].
>>> [1] https://patchwork1.kernel.org/patch/2045821/
>>>
>>
>> Does this patch look good?
>
> It looks OK to me. I've sent a pull request including it, but it may
> happen it ends up only in 3.10.
Thanks. Hope it gets picked for 3.9 itself.
>
> I tried to test this patch today and I had to correct some clock
> definitions in the common clock API driver [1]. And we already have
> quite a few fixes to that patch series.
>
> Shouldn't you also provide a patch adding related OF_DEV_AUXDATA entry ?
> How did you test this one ?
I tested this without the common clock patches, with the mainline tree. It
did not require any auxdata entry.
>
> When the new clocks driver gets merged (I guess it happens only in 3.10)
> I'd like to have the media devices' clock names cleaned up, instead of
> names like: {"sclk_fimg2d", "fimg2d"}, {"sclk_fimc", "fimc"},
> {"sclk_fimd"/"fimd"}, in clock-names property we could have common names,
> e.g. { "sclk", "gate" }. This could simplify a bit subsystems like
devfreq.
Yes. That makes sense.
>
> Also I noticed there are some issues caused by splitting mux + div + gate
> clocks into 3 different clocks. One solution to this might be to use the
> new composite clock type.
Ok.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg214149.html
>
--
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Including drm-intel tree to linux-next
On Thu, 2013-02-14 at 15:19 +0100, Borislav Petkov wrote: > On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote: > > Hi Steven, > > > > Since about a year ago we've switched drm/i915 to buffer around 2 > > weeks worth of patches so that we can do decent QA before breaking > > everyone's tree when things land in Dave's drm-next. But that also > > means we'll miss out a bit in the integration testing -next provides, > > which did hurt a bit in recent efforts. Hence can you please include > > > > git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued > > > > into linux-next? Probably best to merge it after drm-next. Note that > > drm-intel-next are the QA'ed chunks I send off to Dave. Also, any > > mailing lists I'm supposed to follow? And if possible please cc > > intel-...@lists.freedesktop.org besides dri-devel/lkml when conflicts > > with that tree pop up (you won't get moderation spam any more, we've > > fixed that up). > > I think you want to send this here to Stephen Rothwell. CCed. > This is why I tell people to call me Steve or Steven, but never Stephen, otherwise people might confuse me with one of the Stephens that also do kernel development. Note, this is not the first time I've been confused with someone else. So don't feel bad ;-) -- Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
gl.h: Version mumbo-jumbo and Copyright?
Hi, noticed when polishing up my build-scripts fot libdrm | mesa | xf86-video-intel (last one requires gl.h). /* * Mesa 3-D graphics library * Version: 7.6 <--- ??? * * Copyright (C) 1999-2006 Brian Paul All Rights Reserved. <--- ??? * Copyright (C) 2009 VMware, Inc. All Rights Reserved. ... Regards, - Sedat - http://cgit.freedesktop.org/mesa/mesa/tree/include/GL/gl.h#n3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: gl.h: Version mumbo-jumbo and Copyright?
On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul wrote: > On 02/14/2013 01:10 PM, Sedat Dilek wrote: >> >> Hi, >> >> noticed when polishing up my build-scripts fot libdrm | mesa | >> xf86-video-intel (last one requires gl.h). >> >> /* >> * Mesa 3-D graphics library >> * Version: 7.6<--- ??? > > > I could remove that obsolete line. > > > >> * >> * Copyright (C) 1999-2006 Brian Paul All Rights Reserved.<--- ??? >> * Copyright (C) 2009 VMware, Inc. All Rights Reserved. > > > What's the question there? > As we have 2013... - Sedat - > -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Set i9xx sdvo clock limits according to specifications
On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote: > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and > 5-9. > Since we do all calculations based on them being register values (which are > subtracted by 2) we need to specify them accordingly. > > Signed-off-by: Patrik Jakobsson Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Set i9xx sdvo clock limits according to specifications
On Thu, Feb 14, 2013 at 08:50:25PM +, Chris Wilson wrote: > On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote: > > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and > > 5-9. > > Since we do all calculations based on them being register values (which are > > subtracted by 2) we need to specify them accordingly. > > > > Signed-off-by: Patrik Jakobsson > > Reviewed-by: Chris Wilson Queued both for -next with a cc: stable tag to increase the odds of detecting bugs (or fixing some). Thanks for the patches. -Daniel > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- 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] drm/i915: Set i9xx sdvo clock limits according to specifications
On Fri, Feb 15, 2013 at 6:59 AM, Daniel Vetter wrote: > On Thu, Feb 14, 2013 at 08:50:25PM +, Chris Wilson wrote: >> On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote: >> > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 >> > and 5-9. >> > Since we do all calculations based on them being register values (which are >> > subtracted by 2) we need to specify them accordingly. >> > >> > Signed-off-by: Patrik Jakobsson >> >> Reviewed-by: Chris Wilson > > Queued both for -next with a cc: stable tag to increase the odds of > detecting bugs (or fixing some). Thanks for the patches. > -Daniel yeah no stable for this sorta thing, this could go horribly wrong, if it fxies something stable it later. stable isn't meant for testing patches that could break things. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Set i9xx sdvo clock limits according to specifications
On Thu, Feb 14, 2013 at 10:45 PM, Dave Airlie wrote: > On Fri, Feb 15, 2013 at 6:59 AM, Daniel Vetter wrote: >> On Thu, Feb 14, 2013 at 08:50:25PM +, Chris Wilson wrote: >>> On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote: >>> > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 >>> > and 5-9. >>> > Since we do all calculations based on them being register values (which >>> > are >>> > subtracted by 2) we need to specify them accordingly. >>> > >>> > Signed-off-by: Patrik Jakobsson >>> >>> Reviewed-by: Chris Wilson >> >> Queued both for -next with a cc: stable tag to increase the odds of >> detecting bugs (or fixing some). Thanks for the patches. >> -Daniel > > yeah no stable for this sorta thing, this could go horribly wrong, if > it fxies something stable it later. > > stable isn't meant for testing patches that could break things. Ok, unstabled again. But wouldn't really have been the first time we'd throw a revert to stable ;-) -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: gl.h: Version mumbo-jumbo and Copyright?
On 02/14/2013 12:29 PM, Sedat Dilek wrote: On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul wrote: On 02/14/2013 01:10 PM, Sedat Dilek wrote: Hi, noticed when polishing up my build-scripts fot libdrm | mesa | xf86-video-intel (last one requires gl.h). /* * Mesa 3-D graphics library * Version: 7.6<--- ??? I could remove that obsolete line. * * Copyright (C) 1999-2006 Brian Paul All Rights Reserved.<--- ??? * Copyright (C) 2009 VMware, Inc. All Rights Reserved. What's the question there? As we have 2013... Copyright lines are typically only updated when the file is modified. I suspect there haven't been any modifications made to gl.h in a long time, so there's no material with a later copyright. - Sedat - -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Including drm-intel tree to linux-next
Hi Daniel, On Thu, 14 Feb 2013 15:19:53 +0100 Borislav Petkov wrote: > > On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote: > > > > Since about a year ago we've switched drm/i915 to buffer around 2 > > weeks worth of patches so that we can do decent QA before breaking > > everyone's tree when things land in Dave's drm-next. But that also > > means we'll miss out a bit in the integration testing -next provides, > > which did hurt a bit in recent efforts. Hence can you please include > > > > git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued > > > > into linux-next? Probably best to merge it after drm-next. Note that > > drm-intel-next are the QA'ed chunks I send off to Dave. Also, any > > mailing lists I'm supposed to follow? And if possible please cc > > intel-...@lists.freedesktop.org besides dri-devel/lkml when conflicts > > with that tree pop up (you won't get moderation spam any more, we've > > fixed that up). Added from today. I am in two minds a bit since I really like stuff in linux-next to have been reviewed and debugged as much as possible. But I have added it and will keep an eye on how many problems it causes. Problem reports will go to you, intel-gfx and dri-devel. You can follow linux-n...@vger.kernel.org (I sometimes post stuff there that goes nowhere else (except lkml - which noone seems to notice :-)). Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au Legal Stuff: By participating in linux-next, your subsystem tree contributions are public and will be included in the linux-next trees. You may be sent e-mail messages indicating errors or other issues when the patches/commits from your subsystem tree are merged and tested in linux-next. These messages may also be cross-posted to the linux-next mailing list, the linux-kernel mailing list, etc. The linux-next tree project and IBM (my employer) make no warranties regarding the linux-next project, the testing procedures, the results, the e-mails, etc. If you don't agree to these ground rules, let me know and I'll remove your tree from participation in linux-next. pgp1UfwMxjJCa.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Set i9xx lvds clock limits according to specifications
On Wed, Feb 13, 2013 at 10:20:21PM +0100, Patrik Jakobsson wrote: > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and > 5-9. > Since we do all calculations based on them being register values (which are > subtracted by 2) we need to specify them accordingly. One thing I've just noticed is that intel_limits_i9xx_sdvo is reused by g4x, so I'll double check that in the morning unless someone beats me to it. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the drm-intel tree
Hi all, After merging the drm-intel tree, today's linux-next build (x86_64 allmodconfig) failed like this: ERROR: "pm_vt_switch_unregister" [drivers/video/fb.ko] undefined! I have dropped the tree for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpbVHZH4ZWzz.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
2013/2/6 Vikas Sajjan :
> Add support for parsing the display-timing node using video helper
> function.
>
> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
> exists and the NON-DT logic is still maintained under the 'else' part.
>
> Signed-off-by: Leela Krishna Amudala
> Signed-off-by: Vikas Sajjan
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 41
> +++---
> 1 file changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bf0d9ba..978e866 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -905,16 +906,48 @@ static int __devinit fimd_probe(struct platform_device
> *pdev)
> struct exynos_drm_subdrv *subdrv;
> struct exynos_drm_fimd_pdata *pdata;
> struct exynos_drm_panel_info *panel;
> + struct fb_videomode *fbmode;
> + struct pinctrl *pctrl;
> struct resource *res;
> int win;
> int ret = -EINVAL;
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> - pdata = pdev->dev.platform_data;
> - if (!pdata) {
> - dev_err(dev, "no platform data specified\n");
> - return -EINVAL;
> + if (pdev->dev.of_node) {
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + DRM_ERROR("memory allocation for pdata failed\n");
> + return -ENOMEM;
> + }
> +
> + fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
> + if (!fbmode) {
> + DRM_ERROR("memory allocation for fbmode failed\n");
> + return -ENOMEM;
> + }
It doesn't need to allocate fbmode.
> +
> + ret = of_get_fb_videomode(dev->of_node, fbmode, -1);
What is -1? use OF_USE_NATIVE_MODE instead including
"of_display_timing.h" and just change the above code like below,
fbmode = &pdata->panel.timing;
ret = of_get_fb_videomode(dev->of_node, fbmode,
OF_USE_NATIVE_MODE);
> + if (ret) {
> + DRM_ERROR("failed: of_get_fb_videomode()\n"
> + "with return value: %d\n", ret);
> + return ret;
> + }
> + pdata->panel.timing = (struct fb_videomode) *fbmode;
remove the above line.
> +
> + pctrl = devm_pinctrl_get_select_default(dev);
> + if (IS_ERR_OR_NULL(pctrl)) {
> + DRM_ERROR("failed:
> devm_pinctrl_get_select_default()\n"
> + "with return value: %d\n", PTR_RET(pctrl));
> + return PTR_RET(pctrl);
> + }
> +
> + } else {
> + pdata = pdev->dev.platform_data;
> + if (!pdata) {
> + DRM_ERROR("no platform data specified\n");
> + return -EINVAL;
> + }
> }
>
> panel = &pdata->panel;
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] exynos-drm-next
Hi Dave, This pull-request includes hdmi mode relevant some improvements, bug fixes and code cleanups. The summary: . Add display mode check operaion to mixer driver - Mixer IP also can put certain restrictions on the proposed display modes and these restrictions need to be considered during mode negotiation, which happens immediately after edid parsing. . Set correct mode for range of resolutions - With this patch, the mixer driver could find the correct mode for the range of resolutions upto 1080 vertical lines. . Support extra resolution for hdmi - This patch programs the core and timing generator registers using the timing data provided in drm_display_mode without hard-coded configurations. So this patch adds additional PHY configs to allow us to support more permissible resolutions and refresh rates. . Add device tree support for g2d - This patch adds just the compatible string for exynos5250 SoC so that with device tree enabling, this driver can be probed. . And bug fixes and code cleanups. And there are two patches not merged yet and being reviewed so I will have pull-request after reviewed enough and adding more device tree supports one more time. If there is any problem, please kindly let me know. Thanks, Inki Dae The following changes since commit 3314fdf8b44bd4914050614fa2c56b7c587fabc2: Merge branch 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm into drm-next (2013-02-15 10:22:01 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-next Ajay Kumar (1): drm/exynos: Add device tree based discovery support for G2D Inki Dae (2): drm/exynos: fix iommu address allocation order drm/exynos: consider exception case to fb handle creation Rahul Sharma (3): drm/exynos: add display-mode-check operation to exynos_mixer_ops struct drm/exynos: implement display-mode-check callback in mixer driver drm/exynos: mixer: set correct mode for range of resolutions Sachin Kamat (1): drm/exynos: Add missing braces around sizeof Sean Paul (1): drm/exynos: hdmi: support extra resolutions using drm_display_mode timings YoungJun Cho (2): drm/exynos: fix wrong pointer access at vm close. drm/exynos: release resources properly when fb creation is failed. drivers/gpu/drm/exynos/exynos_drm_fb.c| 55 +- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 12 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 33 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 12 + drivers/gpu/drm/exynos/exynos_drm_hdmi.h |5 +- drivers/gpu/drm/exynos/exynos_drm_iommu.h |2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 1035 +++-- drivers/gpu/drm/exynos/exynos_mixer.c | 34 +- 8 files changed, 490 insertions(+), 698 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay
https://bugs.freedesktop.org/show_bug.cgi?id=56659 --- Comment #3 from runetmem...@gmail.com --- Still reproducible with radeon 7.0.0 and newer git snapshots. -- 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 v5 1/1] video: drm: exynos: Add display-timing node parsing using video helper function
Hi Mr. Inki Dae,
Thanks for review.
On 15 February 2013 08:50, Inki Dae wrote:
> 2013/2/6 Vikas Sajjan :
>> Add support for parsing the display-timing node using video helper
>> function.
>>
>> The DT node parsing and pinctrl selection is done only if 'dev.of_node'
>> exists and the NON-DT logic is still maintained under the 'else' part.
>>
>> Signed-off-by: Leela Krishna Amudala
>> Signed-off-by: Vikas Sajjan
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 41
>> +++---
>> 1 file changed, 37 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index bf0d9ba..978e866 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -19,6 +19,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -905,16 +906,48 @@ static int __devinit fimd_probe(struct platform_device
>> *pdev)
>> struct exynos_drm_subdrv *subdrv;
>> struct exynos_drm_fimd_pdata *pdata;
>> struct exynos_drm_panel_info *panel;
>> + struct fb_videomode *fbmode;
>> + struct pinctrl *pctrl;
>> struct resource *res;
>> int win;
>> int ret = -EINVAL;
>>
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>
>> - pdata = pdev->dev.platform_data;
>> - if (!pdata) {
>> - dev_err(dev, "no platform data specified\n");
>> - return -EINVAL;
>> + if (pdev->dev.of_node) {
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata) {
>> + DRM_ERROR("memory allocation for pdata failed\n");
>> + return -ENOMEM;
>> + }
>> +
>> + fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
>> + if (!fbmode) {
>> + DRM_ERROR("memory allocation for fbmode failed\n");
>> + return -ENOMEM;
>> + }
>
> It doesn't need to allocate fbmode.
>
>> +
>> + ret = of_get_fb_videomode(dev->of_node, fbmode, -1);
>
> What is -1? use OF_USE_NATIVE_MODE instead including
> "of_display_timing.h" and just change the above code like below,
>
>fbmode = &pdata->panel.timing;
>ret = of_get_fb_videomode(dev->of_node, fbmode,
> OF_USE_NATIVE_MODE);
>
>> + if (ret) {
>> + DRM_ERROR("failed: of_get_fb_videomode()\n"
>> + "with return value: %d\n", ret);
>> + return ret;
>> + }
>> + pdata->panel.timing = (struct fb_videomode) *fbmode;
>
> remove the above line.
>
>> +
>> + pctrl = devm_pinctrl_get_select_default(dev);
>> + if (IS_ERR_OR_NULL(pctrl)) {
>> + DRM_ERROR("failed:
>> devm_pinctrl_get_select_default()\n"
>> + "with return value: %d\n", PTR_RET(pctrl));
>> + return PTR_RET(pctrl);
>> + }
>> +
>> + } else {
>> + pdata = pdev->dev.platform_data;
>> + if (!pdata) {
>> + DRM_ERROR("no platform data specified\n");
>> + return -EINVAL;
>> + }
>> }
>>
>> panel = &pdata->panel;
>> --
>> 1.7.9.5
Will modify, test and resend V6.
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thanks and Regards
Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: Use C8 instead of RGB332 when determining the format from depth/bpp
On Wed, Feb 13, 2013 at 01:40:56PM +0100, Daniel Vetter wrote: > On Tue, Feb 05, 2013 at 01:07:01PM +1000, Dave Airlie wrote: > > On Tue, Feb 5, 2013 at 12:55 AM, Daniel Vetter wrote: > > > On Thu, Jan 31, 2013 at 07:43:38PM +0200, ville.syrjala at > > > linux.intel.com wrote: > > >> From: Ville Syrj?l? > > >> > > >> Support for real RGB332 is a rarity, most hardware only really support > > >> C8. So use C8 instead of RGB332 when determining the format based on > > >> depth/bpp. > > >> > > >> This fixes 8bpp fbcon on i915, since i915 will only accept C8 and not > > >> RGB332. > > >> > > >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59572 > > >> Signed-off-by: Ville Syrj?l? > > > > > > Tested-by: mlsemon35 at gmail.com > > > > > > Dave, can you please consider including these two patches into -fixes? The > > > fix a black screen regression when users opt for 8bpp console ... > > > > These are for next, considering what Linus said about -fixes not > > unless they are big. > > > > so I'll stick a stable cc onto it in next. > > Ping for merging into drm-next or acking for merging through > drm-intel-next ... Merged both into drm-intel trees for 3.9 with Dave's irc-ack. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 60802] Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #1 from Alexandre Demers --- It seems I'll have to bisect because even 3.8-rc1 displays the corruption. I'm attaching a screenshot from RendererFeattest as a corrupted reference. -- 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/20130214/ba19c43b/attachment.html>
[Bug 60802] Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #2 from Alexandre Demers --- Created attachment 74793 --> https://bugs.freedesktop.org/attachment.cgi?id=74793&action=edit Corrupted texture on background But the texture on the cubes seems to be ok -- 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/20130214/868197c0/attachment.html>
[Bug 60802] Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #3 from Alexandre Demers --- (In reply to comment #2) > Created attachment 74793 [details] > Corrupted texture on background > > But the texture on the cubes seems to be ok The text is also corrupted -- 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/20130214/e0cdbd34/attachment.html>
[PATCH v2 1/2] [media] s5p-g2d: Add DT based discovery support
On 02/12/2013 06:30 PM, Sachin Kamat wrote:
>
> Hi Sylwester,
>
> On Wednesday, 6 February 2013, Sachin Kamat
> wrote:
>> This patch adds device tree based discovery support to G2D driver
>>
>> Signed-off-by: Sachin Kamat
>> ---
>> Based on for_v3.9 branch of below tree:
>> git://linuxtv.org/snawrocki/samsung.git
>>
>> Changes since v1:
>> * Addressed review comments from Sylwester .
>> * Modified the compatible string as per the discussions at [1].
>> [1] https://patchwork1.kernel.org/patch/2045821/
>>
>
> Does this patch look good?
It looks OK to me. I've sent a pull request including it, but it may
happen it ends up only in 3.10.
I tried to test this patch today and I had to correct some clock
definitions in the common clock API driver [1]. And we already have
quite a few fixes to that patch series.
Shouldn't you also provide a patch adding related OF_DEV_AUXDATA entry ?
How did you test this one ?
When the new clocks driver gets merged (I guess it happens only in 3.10)
I'd like to have the media devices' clock names cleaned up, instead of
names like: {"sclk_fimg2d", "fimg2d"}, {"sclk_fimc", "fimc"},
{"sclk_fimd"/"fimd"}, in clock-names property we could have common names,
e.g. { "sclk", "gate" }. This could simplify a bit subsystems like devfreq.
Also I noticed there are some issues caused by splitting mux + div + gate
clocks into 3 different clocks. One solution to this might be to use the
new composite clock type.
[1] http://www.spinics.net/lists/arm-kernel/msg214149.html
[PATCH 2/3] drm: Renesas R-Car Display Unit DRM driver
On Wed, Feb 13, 2013 at 07:18:33PM +0100, Laurent Pinchart wrote: > Hi Simon, > > On Wednesday 13 February 2013 21:28:20 Simon Horman wrote: > > On Thu, Jan 31, 2013 at 02:45:02AM +0100, Laurent Pinchart wrote: > > > The R-Car Display Unit (DU) DRM driver supports both superposition > > > processors and all eight planes in RGB and YUV formats without alpha > > > blending. > > > > > > Only VGA and LVDS encoders and connectors are currently supported. > > > > As discussed elsewhere I have applied this series to topic/r-car-du-drm > > in the renesas tree. > > > > Subsequently, thanks to the wonder that is kbuild, > > I have noticed the following build error when using this series > > in conjunction with "ARM: shmobile: r8a7779: Remove DU function GPIOs". > > > > Clearly this will not be a problem if this series is applied before > > the patch above. But presumably it will be a problem down the road. > > And actually it is currently a (ignorable) problem in topic/all+next. > > > > In any case, I was wondering if Laurent could cook up an add-on patch > > to resolve this problem. At the very least it would provide a > > reference for how to solve the problem later on and as a bonus clean > > up topic/all+next. > > The DU board code I've submitted for the Marzen board doesn't use the pinctrl > API yet, as I wanted the DU DRM driver to be usable without waiting for the > next pinctrl series to be ready. I will fix this later, either in the DU DRM > driver patch series or in the pinctrl patch series, depending on which one is > ready first. > > In the meantime, please keep the branches separate. Sure, I can do that :)
[RFC v2 3/3] video: exynos: Making s6e8ax0 panel driver compliant with CDF
On Wed, Feb 13, 2013 at 19:01, Vikas Sajjan wrote:
> Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
> It also removes the dependency on backlight and lcd framework
>
> Signed-off-by: Vikas Sajjan
> ---
> drivers/video/exynos/s6e8ax0.c | 848
> +---
> 1 file changed, 444 insertions(+), 404 deletions(-)
>
> diff --git a/drivers/video/exynos/s6e8ax0.c b/drivers/video/exynos/s6e8ax0.c
> index 7f7b25f..5a17e3c 100644
> --- a/drivers/video/exynos/s6e8ax0.c
> +++ b/drivers/video/exynos/s6e8ax0.c
> @@ -25,6 +25,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -38,8 +39,7 @@
> #define POWER_IS_OFF(pwr) ((pwr) == FB_BLANK_POWERDOWN)
> #define POWER_IS_NRM(pwr) ((pwr) == FB_BLANK_NORMAL)
>
> -#define lcd_to_master(a) (a->dsim_dev->master)
> -#define lcd_to_master_ops(a) ((lcd_to_master(a))->master_ops)
> +#define to_panel(p) container_of(p, struct s6e8ax0, entity)
>
> enum {
> DSIM_NONE_STATE = 0,
> @@ -47,20 +47,34 @@ enum {
> DSIM_FRAME_DONE = 2,
> };
>
> +/* This structure defines all the properties of a backlight */
> +struct backlight_prop {
> + /* Current User requested brightness (0 - max_brightness) */
> + int brightness;
> + /* Maximal value for brightness (read-only) */
> + int max_brightness;
> +};
> +
> +struct panel_platform_data {
> + unsigned intreset_delay;
> + unsigned intpower_on_delay;
> + unsigned intpower_off_delay;
> + const char *video_source_name;
> +};
> +
> struct s6e8ax0 {
> - struct device *dev;
> - unsigned intpower;
> - unsigned intid;
> - unsigned intgamma;
> - unsigned intacl_enable;
> - unsigned intcur_acl;
> -
> - struct lcd_device *ld;
> - struct backlight_device *bd;
> -
> - struct mipi_dsim_lcd_device *dsim_dev;
> - struct lcd_platform_data*ddi_pd;
> + struct platform_device *pdev;
> + struct video_source *src;
> + struct display_entity entity;
> + unsigned intpower;
> + unsigned intid;
> + unsigned intgamma;
> + unsigned intacl_enable;
> + unsigned intcur_acl;
> + boolpanel_reverse;
> + struct lcd_platform_data*plat_data;
> struct mutexlock;
> + struct backlight_prop bl_prop;
> bool enabled;
> };
>
Could this panel driver use only CDF?
Does not consider the compatibility with backlight and lcd framework?
> -static const unsigned char s6e8ax0_22_gamma_30[] = {
> +static unsigned char s6e8ax0_22_gamma_30[] = {
> 0xfa, 0x01, 0x60, 0x10, 0x60, 0xf5, 0x00, 0xff, 0xad, 0xaf,
> 0xbA, 0xc3, 0xd8, 0xc5, 0x9f, 0xc6, 0x9e, 0xc1, 0xdc, 0xc0,
> 0x00, 0x61, 0x00, 0x5a, 0x00, 0x74,
> };
In all case, you had changed data type to 'static unsigned char'.
Is it need to change all case? Otherwise, for the unity of the code?
Thank you,
Donghwa Lee
[pull] fb helper cleanups
Hi Dave, [Andrew: Pull contains the patch "drm/fb-helper: don't sleep for screen unblank when an oopps is in progress" which is also in your tree, hence the cc.] I've figured a pull request is easier to handle ;-) This is the drm fb helper cleanup, mostly motivated by strange things I've seen in my locking rework and the i915 modeset revamp. Compared to the original submission I've reinstated the setup flexibility you'd like to retain, kerneldoc has been reviewed by Laurent Pinchart and Rob Clark reviewed the code changes. Quick overview of the changes: - Cleaned-up library interface for drivers using the fb helper, also simplified the fb allocation callback since no driver supported reallocating the fb on-the-fly. And the fbdev/fbcon code keeps pointers to the old mapping around anyway, so reallocating backing storage will be much more work. - No longer call the crtc helper "disable everything" function at init time, but allow drivers to do so. Motivated by i915's fastboot effort and allows us to drop a bunch of noop dummy functions just to avoid calling NULL function pointers from i915.ko. - Properly clear old state when doing modeset calls, the fb helper left some old modes in there and unconditionally set an fb (even when disabling a crtc). The crtc helpers didn't care, but i915 modeset code can now drop a few special cases. - Full kerneldoc for the fb helper. Yay! - My version of the "don't sleep in panic ->unblank calls". The patch is already in -mm, I guess Andrew can drop it as soon as this pull lands in drm-next. Imo the fb helper looks now rather nice, and there's only a few pieces left to fix up further: - Removing the duplicated gamma handling. - Reviewing the locking in the panic/sysrq/kgdb handlers some more. - Maybe move some function pointers only used by the fb helper from the crtc helper structs to the fb helper structs. Currently those vtable misplacements are the last thing tying fb/crtc helpers together. - Locking around init/teardown still looks a bit fishy. But that ties into the console_lock madness, so I'm not volunteering ;-) Cheers, Daniel The following changes since commit b9e5071386007729110e86fd2c55c687085624e3: Merge branch 'for-airlied' of git://people.freedesktop.org/~mlankhorst/linux into drm-next (2013-02-08 14:02:32 +1000) are available in the git repository at: git://people.freedesktop.org/~danvet/drm drm-fb-helper for you to fetch changes up to a065b46a01b25d7d364e01e75f7ec2bd9ed5d9cb: drm/fb-helper: remove unused members of struct drm_fb_helper (2013-02-14 00:08:41 +0100) Daniel Vetter (14): drm: review locking for drm_fb_helper_restore_fbdev_mode drm/fb-helper: kill drm_fb_helper_restore drm/fb-helper: unexport drm_fb_helper_panic drm/fb-helper: unexport drm_fb_helper_single_fb_probe drm/tegra: don't set up initial fbcon config twice drm/fb-helper: don't disable everything in initial_config drm/i915: rip out helper->disable noop functions drm/fb-helper: fixup set_config semantics drm/fb-helper: directly call set_par from the hotplug handler drm/fb-helper: streamline drm_fb_helper_single_fb_probe drm/: simplify ->fb_probe callback drm/fb-helper: improve kerneldoc drm/fb-helper: don't sleep for screen unblank when an oopps is in progress drm/fb-helper: remove unused members of struct drm_fb_helper Documentation/DocBook/drm.tmpl|1 + drivers/gpu/drm/ast/ast_fb.c | 26 +-- drivers/gpu/drm/cirrus/cirrus_fbdev.c | 26 +-- drivers/gpu/drm/drm_crtc.c| 16 +- drivers/gpu/drm/drm_fb_cma_helper.c | 22 +-- drivers/gpu/drm/drm_fb_helper.c | 251 +++-- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 35 +--- drivers/gpu/drm/gma500/framebuffer.c | 14 +- drivers/gpu/drm/i915/intel_crt.c |1 - drivers/gpu/drm/i915/intel_ddi.c |1 - drivers/gpu/drm/i915/intel_display.c | 20 +-- drivers/gpu/drm/i915/intel_dp.c |1 - drivers/gpu/drm/i915/intel_drv.h |1 - drivers/gpu/drm/i915/intel_dvo.c |1 - drivers/gpu/drm/i915/intel_fb.c | 21 +-- drivers/gpu/drm/i915/intel_hdmi.c |1 - drivers/gpu/drm/i915/intel_lvds.c |1 - drivers/gpu/drm/i915/intel_sdvo.c |1 - drivers/gpu/drm/i915/intel_tv.c |1 - drivers/gpu/drm/mgag200/mgag200_fb.c | 27 +--- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 25 +-- drivers/gpu/drm/radeon/radeon_fb.c| 25 +-- drivers/gpu/drm/tegra/fb.c|4 - drivers/gpu/drm/udl/udl_fb.c | 26 +-- drivers/staging/omapdrm/omap_fbdev.c | 21 +-- include/drm/drm_crtc.h|1 + include/drm/drm_fb_helper.h | 18 ++- 27 files changed, 298 insertions(+), 290
[Linaro-mm-sig] [PATCH 2/3] mutex: add support for reservation style locks
On Thursday 07 February 2013, Maarten Lankhorst wrote:
Hi Maarten,
I cannot help a lot on this patch set, but there are a few things that
I noticed when reading it.
> Functions:
> --
>
> mutex_reserve_lock, and mutex_reserve_lock_interruptible:
> Lock a buffer with a reservation_id set. reservation_id must not be
> set to 0, since this is a special value that means no reservation_id.
I think the entire description should go into a file in the Documentation
directory, to make it easier to find without looking up the git history.
For the purpose of documenting this, it feels a little strange to
talk about "buffers" here. Obviously this is what you are using the
locks for, but it sounds like that is not the only possible use
case.
> These functions will return -EDEADLK instead of -EAGAIN if
> reservation_id is the same as the reservation_id that's attempted to
> lock the mutex with, since in that case you presumably attempted to
> lock the same lock twice.
Since the user always has to check the return value, would it be
possible to provide only the interruptible kind of this function
but not the non-interruptible one? In general, interruptible locks
are obviously harder to use, but they are much user friendlier when
something goes wrong.
> mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
> Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN.
> This is useful when mutex_reserve_lock failed with -EAGAIN, and you
> unreserved all buffers so no deadlock can occur.
Are these meant to be used a lot? If not, maybe prefix them with __mutex_
instead of mutex_.
> diff --git a/include/linux/mutex.h b/include/linux/mutex.h
> index 9121595..602c247 100644
> --- a/include/linux/mutex.h
> +++ b/include/linux/mutex.h
> @@ -62,6 +62,11 @@ struct mutex {
> #endif
> };
>
> +struct ticket_mutex {
> + struct mutex base;
> + atomic_long_t reservation_id;
> +};
Have you considered changing the meaning of the "count" member
of the mutex in the case where a ticket mutex is used? That would
let you use an unmodified structure.
Arnd
[Bug 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 --- Comment #6 from Wojciech Pyczak --- I'm currently using latest version (cb4616d3) and the issue is gone. -- 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/20130214/3a272d1b/attachment.html>
[Linaro-mm-sig] [PATCH 2/3] mutex: add support for reservation style locks
On Thu, Feb 14, 2013 at 11:22 AM, Arnd Bergmann wrote: > >> These functions will return -EDEADLK instead of -EAGAIN if >> reservation_id is the same as the reservation_id that's attempted to >> lock the mutex with, since in that case you presumably attempted to >> lock the same lock twice. > > Since the user always has to check the return value, would it be > possible to provide only the interruptible kind of this function > but not the non-interruptible one? In general, interruptible locks > are obviously harder to use, but they are much user friendlier when > something goes wrong. At least in drm/i915 we only use _interruptible locking on the command-submission ioctls for all locks which could be held while waiting for the gpu. We need unwind paths and ioctl restarting anyway to bail out on catastrophic events like gpu hangs, so signal interrupt handling comes for free. Otoh in the modeset code we generally don't bother with that, since unwinding a modeset sequence mid-way is something you don't want to do really if your sanity is dear to you. But we also never need mutli-object reservations in the modeset code, neither can I imagine a future need for it. So from my side we could drop the non-interruptible interface. But I have not checked whether dropping this would complicate the ttm conversion. >> mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow: >> Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN. >> This is useful when mutex_reserve_lock failed with -EAGAIN, and you >> unreserved all buffers so no deadlock can occur. > > Are these meant to be used a lot? If not, maybe prefix them with __mutex_ > instead of mutex_. If you detect an inversion in a multi-buffer reservation you have to drop all locks and call these functions on the buffer which failed (that's the contention point, hence it's the right lock to sleep on). So every place using ticket locks will also call the above slowpath functions by necessity. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] omapdrm: Make fixed resolution panels work
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following things are done to make fixed panels work:
- The omap_connector's detect function is modified such that it considers panel
types which are generally fixed panels as always connected(provided the panel
driver doesn't have a detect op). Hence, the connector corresponding to these
panels is always in a 'connected' state.
- If a panel driver doesn't have a check_timings op, assume that it supports the
mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function)
- The function omap_encoder_update shouldn't really do anything for fixed
resolution panels, make sure that it calls set_timings only if the panel
driver has one.
I tested this with picodlp on a OMAP4 sdp board. I couldn't get any other
working boards with fixed DPI panels. I could try the DSI video mode panel
on an OMAP5 sevm, but that will require me to patch a lot of things to get
omap5 dss work with DT. I can try if needed.
Signed-off-by: Archit Taneja
---
drivers/staging/omapdrm/omap_connector.c | 10 --
drivers/staging/omapdrm/omap_encoder.c |6 --
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_connector.c
b/drivers/staging/omapdrm/omap_connector.c
index 4cc9ee7..839c6e4 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+ } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
+ ret = connector_status_connected;
} else {
ret = connector_status_unknown;
}
@@ -189,12 +194,13 @@ static int omap_connector_mode_valid(struct drm_connector
*connector,
struct omap_video_timings timings = {0};
struct drm_device *dev = connector->dev;
struct drm_display_mode *new_mode;
- int ret = MODE_BAD;
+ int r, ret = MODE_BAD;
copy_timings_drm_to_omap(&timings, mode);
mode->vrefresh = drm_mode_vrefresh(mode);
- if (!dssdrv->check_timings(dssdev, &timings)) {
+ r = dssdrv->check_timings ? dssdrv->check_timings(dssdev, &timings) : 0;
+ if (!r) {
/* check if vrefresh is still valid */
new_mode = drm_mode_duplicate(dev, mode);
new_mode->clock = timings.pixel_clock;
diff --git a/drivers/staging/omapdrm/omap_encoder.c
b/drivers/staging/omapdrm/omap_encoder.c
index e053160..871af12e 100644
--- a/drivers/staging/omapdrm/omap_encoder.c
+++ b/drivers/staging/omapdrm/omap_encoder.c
@@ -128,13 +128,15 @@ int omap_encoder_update(struct drm_encoder *encoder,
dssdev->output->manager = mgr;
- ret = dssdrv->check_timings(dssdev, timings);
+ ret = dssdrv->check_timings ?
+ dssdrv->check_timings(dssdev, timings) : 0;
if (ret) {
dev_err(dev->dev, "could not set timings: %d\n", ret);
return ret;
}
- dssdrv->set_timings(dssdev, timings);
+ if (dssdrv->set_timings)
+ dssdrv->set_timings(dssdev, timings);
return 0;
}
--
1.7.9.5
[PATCH] drm/i915: Set i9xx lvds clock limits according to specifications
On Wed, Feb 13, 2013 at 10:20:21PM +0100, Patrik Jakobsson wrote: > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and > 5-9. > Since we do all calculations based on them being register values (which are > subtracted by 2) we need to specify them accordingly. > > Signed-off-by: Patrik Jakobsson Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
Including drm-intel tree to linux-next
Hi Steven, Since about a year ago we've switched drm/i915 to buffer around 2 weeks worth of patches so that we can do decent QA before breaking everyone's tree when things land in Dave's drm-next. But that also means we'll miss out a bit in the integration testing -next provides, which did hurt a bit in recent efforts. Hence can you please include git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued into linux-next? Probably best to merge it after drm-next. Note that drm-intel-next are the QA'ed chunks I send off to Dave. Also, any mailing lists I'm supposed to follow? And if possible please cc intel-gfx at lists.freedesktop.org besides dri-devel/lkml when conflicts with that tree pop up (you won't get moderation spam any more, we've fixed that up). Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Linaro-mm-sig] [PATCH 2/3] mutex: add support for reservation style locks
Hey,
Op 14-02-13 11:22, Arnd Bergmann schreef:
> On Thursday 07 February 2013, Maarten Lankhorst wrote:
>
> Hi Maarten,
>
> I cannot help a lot on this patch set, but there are a few things that
> I noticed when reading it.
>
>> Functions:
>> --
>>
>> mutex_reserve_lock, and mutex_reserve_lock_interruptible:
>> Lock a buffer with a reservation_id set. reservation_id must not be
>> set to 0, since this is a special value that means no reservation_id.
> I think the entire description should go into a file in the Documentation
> directory, to make it easier to find without looking up the git history.
>
> For the purpose of documenting this, it feels a little strange to
> talk about "buffers" here. Obviously this is what you are using the
> locks for, but it sounds like that is not the only possible use
> case.
It is the idea it will end up in Documentation, however I had a hard time even
getting people to
review the code, so I found it easier to keep code and documentation in sync by
keeping it into
the commit log when I was amending things.
But yes it's the use case I use it for. The generic use case would be if you
had a number of equal
locks you want to take in an arbitrary order without deadlocking or a lock
protecting all those locks*.
*) In the eyes of lockdep you still take one of those locks, and nest all those
locks you take into that lock.
>> These functions will return -EDEADLK instead of -EAGAIN if
>> reservation_id is the same as the reservation_id that's attempted to
>> lock the mutex with, since in that case you presumably attempted to
>> lock the same lock twice.
> Since the user always has to check the return value, would it be
> possible to provide only the interruptible kind of this function
> but not the non-interruptible one? In general, interruptible locks
> are obviously harder to use, but they are much user friendlier when
> something goes wrong.
I agree that in general you want to use the interruptible versions as much as
possible,
but there are some cases in ttm where it is desirable to lock non-interruptibly.
>> mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
>> Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN.
>> This is useful when mutex_reserve_lock failed with -EAGAIN, and you
>> unreserved all buffers so no deadlock can occur.
> Are these meant to be used a lot? If not, maybe prefix them with __mutex_
> instead of mutex_.
It is a common path in case of contestion. The example lock_execbuf from the
commit log used
it. When you use the mutex_reserve_lock calls, you'll have to add calls to the
*_slow variants
too when those return -EAGAIN.
>> diff --git a/include/linux/mutex.h b/include/linux/mutex.h
>> index 9121595..602c247 100644
>> --- a/include/linux/mutex.h
>> +++ b/include/linux/mutex.h
>> @@ -62,6 +62,11 @@ struct mutex {
>> #endif
>> };
>>
>> +struct ticket_mutex {
>> +struct mutex base;
>> +atomic_long_t reservation_id;
>> +};
> Have you considered changing the meaning of the "count" member
> of the mutex in the case where a ticket mutex is used? That would
> let you use an unmodified structure.
I have considered it, but I never found a good way to make that happen.
mutex_lock and mutex_unlock are currently still used when only a single
buffer needs to be locked.
Thanks for the review!
~Maarten
CDF meeting @FOSDEM report
On 2013-02-13 00:45, St?phane Marchesin wrote: > So, a part which is completely omitted in this thread is how to handle > suspend/resume ordering. If you have multiple encoders which need to > be turned on/off in a given order at suspend/resume, how do you handle > that given the current scheme where they are just separate platform > drivers in drivers/video? > > This problems occurs with drm/exynos in current 3.8 kernels for > example. On that platform, the DP driver and the FIMD driver will > suspend/resume in random order, and therefore fail resuming half the > time. Is there something which could be done in CDF to address that? I don't think we have a perfect solution for this, but I think we can handle this by using PM notifiers, PM_SUSPEND_PREPARE and PM_POST_SUSPEND. The code that manages the whole chain should register to those notifiers, and disable or enable the display devices accordingly. This way the devices are enabled and disabled in the right order, and also (hopefully) so that the control busses are operational. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130214/51e11dab/attachment.pgp>
[RFC v2 3/3] video: exynos: Making s6e8ax0 panel driver compliant with CDF
Hi Mr. Lee,
thanks for the review.
On 14 February 2013 07:30, Donghwa Lee wrote:
> On Wed, Feb 13, 2013 at 19:01, Vikas Sajjan wrote:
>>
>> Made necessary changes in s6e8ax0 panel driver as per the CDF-T.
>> It also removes the dependency on backlight and lcd framework
>>
>> Signed-off-by: Vikas Sajjan
>> ---
>> drivers/video/exynos/s6e8ax0.c | 848
>> +---
>> 1 file changed, 444 insertions(+), 404 deletions(-)
>>
>> diff --git a/drivers/video/exynos/s6e8ax0.c
>> b/drivers/video/exynos/s6e8ax0.c
>> index 7f7b25f..5a17e3c 100644
>> --- a/drivers/video/exynos/s6e8ax0.c
>> +++ b/drivers/video/exynos/s6e8ax0.c
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> +#include
>> #include
>> #include
>> @@ -38,8 +39,7 @@
>> #define POWER_IS_OFF(pwr) ((pwr) == FB_BLANK_POWERDOWN)
>> #define POWER_IS_NRM(pwr) ((pwr) == FB_BLANK_NORMAL)
>> -#define lcd_to_master(a) (a->dsim_dev->master)
>> -#define lcd_to_master_ops(a) ((lcd_to_master(a))->master_ops)
>> +#define to_panel(p) container_of(p, struct s6e8ax0, entity)
>> enum {
>> DSIM_NONE_STATE = 0,
>> @@ -47,20 +47,34 @@ enum {
>> DSIM_FRAME_DONE = 2,
>> };
>> +/* This structure defines all the properties of a backlight */
>> +struct backlight_prop {
>> + /* Current User requested brightness (0 - max_brightness) */
>> + int brightness;
>> + /* Maximal value for brightness (read-only) */
>> + int max_brightness;
>> +};
>> +
>> +struct panel_platform_data {
>> + unsigned intreset_delay;
>> + unsigned intpower_on_delay;
>> + unsigned intpower_off_delay;
>> + const char *video_source_name;
>> +};
>> +
>> struct s6e8ax0 {
>> - struct device *dev;
>> - unsigned intpower;
>> - unsigned intid;
>> - unsigned intgamma;
>> - unsigned intacl_enable;
>> - unsigned intcur_acl;
>> -
>> - struct lcd_device *ld;
>> - struct backlight_device *bd;
>> -
>> - struct mipi_dsim_lcd_device *dsim_dev;
>> - struct lcd_platform_data*ddi_pd;
>> + struct platform_device *pdev;
>> + struct video_source *src;
>> + struct display_entity entity;
>> + unsigned intpower;
>> + unsigned intid;
>> + unsigned intgamma;
>> + unsigned intacl_enable;
>> + unsigned intcur_acl;
>> + boolpanel_reverse;
>> + struct lcd_platform_data*plat_data;
>> struct mutexlock;
>> + struct backlight_prop bl_prop;
>> bool enabled;
>> };
>>
>
> Could this panel driver use only CDF?
> Does not consider the compatibility with backlight and lcd framework?
>
as of now CDF does not support backlight and lcd framework functionalities.
Once CDF has the support, we modify the driver to support both CDF and
non CDF way, there by maintaining the backward compatibility with
backlight and lcd framework.
>> -static const unsigned char s6e8ax0_22_gamma_30[] = {
>> +static unsigned char s6e8ax0_22_gamma_30[] = {
>> 0xfa, 0x01, 0x60, 0x10, 0x60, 0xf5, 0x00, 0xff, 0xad, 0xaf,
>> 0xbA, 0xc3, 0xd8, 0xc5, 0x9f, 0xc6, 0x9e, 0xc1, 0xdc, 0xc0,
>> 0x00, 0x61, 0x00, 0x5a, 0x00, 0x74,
>> };
>
> In all case, you had changed data type to 'static unsigned char'.
> Is it need to change all case? Otherwise, for the unity of the code?
in the CDF-T proposed by Mr. Tomi Valkeinen, the prototype for
"dcs_write" looks as below
int (*dcs_write)(struct video_source *src, int channel, u8 *data, size_t len);
It does not have "const" for the 3rd parameter (u8 *data ), and in our
driver we have all the arrays as "const".
Just to silence the compiler warnings, i had removed the "const" keyword.
>
>
> Thank you,
> Donghwa Lee
>
>
--
Thanks and Regards
Vikas Sajjan
[PATCH] drm/exynos: modify condition in mixer and hdmi resume
From: Prathyush K
If mixer is runtime suspended (by DPMS OFF), mixer_suspend
does not call mixer_poweroff and just returns. Similarily the
mixer_resume should not resume the mixer if mixer is
runtime_suspended. It should be done through DPMS ON.
The existing check is stopping the resume. This issue is fixed
by reversing the condiftion. It also holds good for hdmi driver.
Inline with
http://lists.freedesktop.org/archives/dri-devel/2013-January/032920.html.
Signed-off-by: Prathyush K
Signed-off-by: Rahul Sharma
---
It is based on exynos-drm-next-todo branch at
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9e3c2ad..273a6ea 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2386,7 +2386,7 @@ static int hdmi_resume(struct device *dev)
enable_irq(hdata->external_irq);
enable_irq(hdata->internal_irq);
- if (!pm_runtime_suspended(dev)) {
+ if (pm_runtime_suspended(dev)) {
DRM_DEBUG_KMS("%s : Already resumed\n", __func__);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 5139a43..6404f7e4 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1265,7 +1265,7 @@ static int mixer_resume(struct device *dev)
DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
- if (!pm_runtime_suspended(dev)) {
+ if (pm_runtime_suspended(dev)) {
DRM_DEBUG_KMS("%s : Already resumed\n", __func__);
return 0;
}
--
1.8.0
Including drm-intel tree to linux-next
On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote: > Hi Steven, > > Since about a year ago we've switched drm/i915 to buffer around 2 > weeks worth of patches so that we can do decent QA before breaking > everyone's tree when things land in Dave's drm-next. But that also > means we'll miss out a bit in the integration testing -next provides, > which did hurt a bit in recent efforts. Hence can you please include > > git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued > > into linux-next? Probably best to merge it after drm-next. Note that > drm-intel-next are the QA'ed chunks I send off to Dave. Also, any > mailing lists I'm supposed to follow? And if possible please cc > intel-gfx at lists.freedesktop.org besides dri-devel/lkml when conflicts > with that tree pop up (you won't get moderation spam any more, we've > fixed that up). I think you want to send this here to Stephen Rothwell. CCed. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Including drm-intel tree to linux-next
On Thu, Feb 14, 2013 at 3:28 PM, Steven Rostedt wrote: > On Thu, 2013-02-14 at 15:19 +0100, Borislav Petkov wrote: >> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote: >> > Hi Steven, >> > >> > Since about a year ago we've switched drm/i915 to buffer around 2 >> > weeks worth of patches so that we can do decent QA before breaking >> > everyone's tree when things land in Dave's drm-next. But that also >> > means we'll miss out a bit in the integration testing -next provides, >> > which did hurt a bit in recent efforts. Hence can you please include >> > >> > git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued >> > >> > into linux-next? Probably best to merge it after drm-next. Note that >> > drm-intel-next are the QA'ed chunks I send off to Dave. Also, any >> > mailing lists I'm supposed to follow? And if possible please cc >> > intel-gfx at lists.freedesktop.org besides dri-devel/lkml when conflicts >> > with that tree pop up (you won't get moderation spam any more, we've >> > fixed that up). >> >> I think you want to send this here to Stephen Rothwell. CCed. >> > > This is why I tell people to call me Steve or Steven, but never Stephen, > otherwise people might confuse me with one of the Stephens that also do > kernel development. > > Note, this is not the first time I've been confused with someone else. > So don't feel bad ;-) Oops, indeed picked the wrong mail from my sea of "drm/i915 broke stuff, again" mails ;-) Sorry for the noise, Steve. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 60848] New: [bisected] r600g: add htile support cause gpu lockup in Dishonored wine.
https://bugs.freedesktop.org/show_bug.cgi?id=60848 Priority: medium Bug ID: 60848 Assignee: dri-devel at lists.freedesktop.org Summary: [bisected] r600g: add htile support cause gpu lockup in Dishonored wine. Severity: normal Classification: Unclassified OS: Linux (All) Reporter: thomas.lindroth at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 74826 --> https://bugs.freedesktop.org/attachment.cgi?id=74826&action=edit dmesg, xorg.log Commit 6532eb17baff6e61b427f29e076883f8941ae664 r600g: add htile support v16 cause a gpu lockup on juniper with Dishonored in wine. https://www.dropbox.com/s/7w140vtr48xb8vt/Dishonored.trace.bz2 this trace reproduce the error. bug #59592 is similar but I should be using the fix from that bug already. mesa, libdrm, xf86-video-ati and linus kernel are all git from yesterday. 3.0 Mesa 9.2-devel (git-ce3dfa1) Option "ColorTiling" "true" Option "ColorTiling2D" "true" Option "SwapbuffersWait" "false" Option "EnablePageFlip" "true" configure --disable-dependency-tracking --enable-dri --enable-glx --enable-texture-float --disable-debug --enable-egl --disable-gbm --disable-gles1 --disable-gles2 --enable-glx-tls --disable-osmesa --enable-asm --enable-shared-glapi --with-dri-drivers= --with-gallium-drivers=,swrast,r600 --with-egl-platforms=x11 --enable-gallium-egl --disable-d3d1x --disable-gallium-g3dvl --enable-gallium-llvm --disable-openvg --disable-vdpau --disable-xvmc --enable-shared-dricore -- 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/20130214/469148da/attachment-0001.html>
[Bug 60073] [bisected] Bad rendering in Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=60073 Jerome Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jerome Glisse --- Ok closing -- 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/20130214/cd70692a/attachment.html>
[Bug 60848] [bisected] r600g: add htile support cause gpu lockup in Dishonored wine.
https://bugs.freedesktop.org/show_bug.cgi?id=60848 --- Comment #1 from Jerome Glisse --- Does it happen without --enable-gallium-llvm also does it happen when running with R600_HTILE=0 env variable ? -- 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/20130214/beab3727/attachment.html>
[PATCH] omapdrm: Make fixed resolution panels work
On Thu, Feb 14, 2013 at 6:52 AM, Archit Taneja wrote:
> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
> and SDI drivers. At some places, there are no checks to see if the panel
> driver
> has these ops or not, and that leads to a crash.
>
> The following things are done to make fixed panels work:
>
> - The omap_connector's detect function is modified such that it considers
> panel
> types which are generally fixed panels as always connected(provided the
> panel
> driver doesn't have a detect op). Hence, the connector corresponding to
> these
> panels is always in a 'connected' state.
>
> - If a panel driver doesn't have a check_timings op, assume that it supports
> the
> mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper
> function)
>
> - The function omap_encoder_update shouldn't really do anything for fixed
> resolution panels, make sure that it calls set_timings only if the panel
> driver has one.
>
> I tested this with picodlp on a OMAP4 sdp board. I couldn't get any other
> working boards with fixed DPI panels. I could try the DSI video mode panel
> on an OMAP5 sevm, but that will require me to patch a lot of things to get
> omap5 dss work with DT. I can try if needed.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/staging/omapdrm/omap_connector.c | 10 --
> drivers/staging/omapdrm/omap_encoder.c |6 --
> 2 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/omapdrm/omap_connector.c
> b/drivers/staging/omapdrm/omap_connector.c
> index 4cc9ee7..839c6e4 100644
> --- a/drivers/staging/omapdrm/omap_connector.c
> +++ b/drivers/staging/omapdrm/omap_connector.c
> @@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
> ret = connector_status_connected;
> else
> ret = connector_status_disconnected;
> + } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
> + dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
> + dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
> + dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
> + ret = connector_status_connected;
hmm, why not just have a default detect fxn for panel drivers which
always returns true? Seems a bit cleaner.. otherwise, I guess we
could just change omap_connector so that if dssdev->detect is null,
assume always connected. Seems maybe a slightly better way since
currently omap_connector doesn't really know too much about different
sorts of panels. But I'm not too picky if that is a big pain because
we probably end up changing all this as CFP starts coming into
existence.
Same goes for check_timings/set_timings.. it seems a bit cleaner just
to have default fxns in the panel drivers that do-the-right-thing,
although I suppose it might be a bit more convenient for out-of-tree
panel drivers to just assume fixed panel if these fxns are null.
BR,
-R
> } else {
> ret = connector_status_unknown;
> }
> @@ -189,12 +194,13 @@ static int omap_connector_mode_valid(struct
> drm_connector *connector,
> struct omap_video_timings timings = {0};
> struct drm_device *dev = connector->dev;
> struct drm_display_mode *new_mode;
> - int ret = MODE_BAD;
> + int r, ret = MODE_BAD;
>
> copy_timings_drm_to_omap(&timings, mode);
> mode->vrefresh = drm_mode_vrefresh(mode);
>
> - if (!dssdrv->check_timings(dssdev, &timings)) {
> + r = dssdrv->check_timings ? dssdrv->check_timings(dssdev, &timings) :
> 0;
> + if (!r) {
> /* check if vrefresh is still valid */
> new_mode = drm_mode_duplicate(dev, mode);
> new_mode->clock = timings.pixel_clock;
> diff --git a/drivers/staging/omapdrm/omap_encoder.c
> b/drivers/staging/omapdrm/omap_encoder.c
> index e053160..871af12e 100644
> --- a/drivers/staging/omapdrm/omap_encoder.c
> +++ b/drivers/staging/omapdrm/omap_encoder.c
> @@ -128,13 +128,15 @@ int omap_encoder_update(struct drm_encoder *encoder,
>
> dssdev->output->manager = mgr;
>
> - ret = dssdrv->check_timings(dssdev, timings);
> + ret = dssdrv->check_timings ?
> + dssdrv->check_timings(dssdev, timings) : 0;
> if (ret) {
> dev_err(dev->dev, "could not set timings: %d\n", ret);
> return ret;
> }
>
> - dssdrv->set_timings(dssdev, timings);
> + if (dssdrv->set_timings)
> + dssdrv->set_timings(dssdev, timings);
>
> return 0;
> }
> --
> 1.7.9.5
>
gl.h: Version mumbo-jumbo and Copyright?
On 02/14/2013 01:10 PM, Sedat Dilek wrote: > Hi, > > noticed when polishing up my build-scripts fot libdrm | mesa | > xf86-video-intel (last one requires gl.h). > > /* > * Mesa 3-D graphics library > * Version: 7.6<--- ??? I could remove that obsolete line. > * > * Copyright (C) 1999-2006 Brian Paul All Rights Reserved.<--- ??? > * Copyright (C) 2009 VMware, Inc. All Rights Reserved. What's the question there? -Brian
[PATCH v2 1/2] [media] s5p-g2d: Add DT based discovery support
On Thursday, 14 February 2013, Sylwester Nawrocki <
sylvester.nawrocki at gmail.com> wrote:
> On 02/12/2013 06:30 PM, Sachin Kamat wrote:
>>
>> Hi Sylwester,
>>
>> On Wednesday, 6 February 2013, Sachin Kamat
wrote:
>>>
>>> This patch adds device tree based discovery support to G2D driver
>>>
>>> Signed-off-by: Sachin Kamat
>>> ---
>>> Based on for_v3.9 branch of below tree:
>>> git://linuxtv.org/snawrocki/samsung.git
>>>
>>> Changes since v1:
>>> * Addressed review comments from Sylwester .
>>> * Modified the compatible string as per the discussions at [1].
>>> [1] https://patchwork1.kernel.org/patch/2045821/
>>>
>>
>> Does this patch look good?
>
> It looks OK to me. I've sent a pull request including it, but it may
> happen it ends up only in 3.10.
Thanks. Hope it gets picked for 3.9 itself.
>
> I tried to test this patch today and I had to correct some clock
> definitions in the common clock API driver [1]. And we already have
> quite a few fixes to that patch series.
>
> Shouldn't you also provide a patch adding related OF_DEV_AUXDATA entry ?
> How did you test this one ?
I tested this without the common clock patches, with the mainline tree. It
did not require any auxdata entry.
>
> When the new clocks driver gets merged (I guess it happens only in 3.10)
> I'd like to have the media devices' clock names cleaned up, instead of
> names like: {"sclk_fimg2d", "fimg2d"}, {"sclk_fimc", "fimc"},
> {"sclk_fimd"/"fimd"}, in clock-names property we could have common names,
> e.g. { "sclk", "gate" }. This could simplify a bit subsystems like
devfreq.
Yes. That makes sense.
>
> Also I noticed there are some issues caused by splitting mux + div + gate
> clocks into 3 different clocks. One solution to this might be to use the
> new composite clock type.
Ok.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg214149.html
>
--
With warm regards,
Sachin
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130214/446beb86/attachment.html>
Including drm-intel tree to linux-next
On Thu, 2013-02-14 at 15:19 +0100, Borislav Petkov wrote: > On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote: > > Hi Steven, > > > > Since about a year ago we've switched drm/i915 to buffer around 2 > > weeks worth of patches so that we can do decent QA before breaking > > everyone's tree when things land in Dave's drm-next. But that also > > means we'll miss out a bit in the integration testing -next provides, > > which did hurt a bit in recent efforts. Hence can you please include > > > > git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued > > > > into linux-next? Probably best to merge it after drm-next. Note that > > drm-intel-next are the QA'ed chunks I send off to Dave. Also, any > > mailing lists I'm supposed to follow? And if possible please cc > > intel-gfx at lists.freedesktop.org besides dri-devel/lkml when conflicts > > with that tree pop up (you won't get moderation spam any more, we've > > fixed that up). > > I think you want to send this here to Stephen Rothwell. CCed. > This is why I tell people to call me Steve or Steven, but never Stephen, otherwise people might confuse me with one of the Stephens that also do kernel development. Note, this is not the first time I've been confused with someone else. So don't feel bad ;-) -- Steve
gl.h: Version mumbo-jumbo and Copyright?
Hi, noticed when polishing up my build-scripts fot libdrm | mesa | xf86-video-intel (last one requires gl.h). /* * Mesa 3-D graphics library * Version: 7.6 <--- ??? * * Copyright (C) 1999-2006 Brian Paul All Rights Reserved. <--- ??? * Copyright (C) 2009 VMware, Inc. All Rights Reserved. ... Regards, - Sedat - http://cgit.freedesktop.org/mesa/mesa/tree/include/GL/gl.h#n3
gl.h: Version mumbo-jumbo and Copyright?
On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul wrote: > On 02/14/2013 01:10 PM, Sedat Dilek wrote: >> >> Hi, >> >> noticed when polishing up my build-scripts fot libdrm | mesa | >> xf86-video-intel (last one requires gl.h). >> >> /* >> * Mesa 3-D graphics library >> * Version: 7.6<--- ??? > > > I could remove that obsolete line. > > > >> * >> * Copyright (C) 1999-2006 Brian Paul All Rights Reserved.<--- ??? >> * Copyright (C) 2009 VMware, Inc. All Rights Reserved. > > > What's the question there? > As we have 2013... - Sedat - > -Brian
[PATCH] drm/i915: Set i9xx sdvo clock limits according to specifications
On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote: > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and > 5-9. > Since we do all calculations based on them being register values (which are > subtracted by 2) we need to specify them accordingly. > > Signed-off-by: Patrik Jakobsson Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm/i915: Set i9xx sdvo clock limits according to specifications
On Thu, Feb 14, 2013 at 08:50:25PM +, Chris Wilson wrote: > On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote: > > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and > > 5-9. > > Since we do all calculations based on them being register values (which are > > subtracted by 2) we need to specify them accordingly. > > > > Signed-off-by: Patrik Jakobsson > > Reviewed-by: Chris Wilson Queued both for -next with a cc: stable tag to increase the odds of detecting bugs (or fixing some). Thanks for the patches. -Daniel > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/i915: Set i9xx sdvo clock limits according to specifications
On Thu, Feb 14, 2013 at 10:45 PM, Dave Airlie wrote: > On Fri, Feb 15, 2013 at 6:59 AM, Daniel Vetter wrote: >> On Thu, Feb 14, 2013 at 08:50:25PM +, Chris Wilson wrote: >>> On Wed, Feb 13, 2013 at 10:20:22PM +0100, Patrik Jakobsson wrote: >>> > The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 >>> > and 5-9. >>> > Since we do all calculations based on them being register values (which >>> > are >>> > subtracted by 2) we need to specify them accordingly. >>> > >>> > Signed-off-by: Patrik Jakobsson >>> >>> Reviewed-by: Chris Wilson >> >> Queued both for -next with a cc: stable tag to increase the odds of >> detecting bugs (or fixing some). Thanks for the patches. >> -Daniel > > yeah no stable for this sorta thing, this could go horribly wrong, if > it fxies something stable it later. > > stable isn't meant for testing patches that could break things. Ok, unstabled again. But wouldn't really have been the first time we'd throw a revert to stable ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
gl.h: Version mumbo-jumbo and Copyright?
On 02/14/2013 12:29 PM, Sedat Dilek wrote: > On Thu, Feb 14, 2013 at 9:26 PM, Brian Paul wrote: >> On 02/14/2013 01:10 PM, Sedat Dilek wrote: >>> >>> Hi, >>> >>> noticed when polishing up my build-scripts fot libdrm | mesa | >>> xf86-video-intel (last one requires gl.h). >>> >>> /* >>>* Mesa 3-D graphics library >>>* Version: 7.6<--- ??? >> >> >> I could remove that obsolete line. >> >> >> >>>* >>>* Copyright (C) 1999-2006 Brian Paul All Rights Reserved.<--- ??? >>>* Copyright (C) 2009 VMware, Inc. All Rights Reserved. >> >> >> What's the question there? >> > > As we have 2013... Copyright lines are typically only updated when the file is modified. I suspect there haven't been any modifications made to gl.h in a long time, so there's no material with a later copyright. > - Sedat - > >> -Brian > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
