ENOENT as an ioctl return code
On Wed, Dec 4, 2013 at 7:13 AM, Thomas Hellstrom wrote: > On 12/03/2013 09:41 PM, Daniel Vetter wrote: >> >> On Tue, Dec 03, 2013 at 09:09:40PM +0100, Thomas Hellstrom wrote: >>> >>> Hi, >>> >>> By concidence I ran across this lkml message >>> >>> http://marc.info/?l=linux-kernel&m=135628421403144&w=2 >>> >>> with an important part in the middle: (this is not a drm commit) >>> >>> To make matters worse, commit f0ed2ce840b3 is clearly total and utter >>> CRAP even if it didn't break applications. ENOENT is not a valid error >>> return from an ioctl. Never has been, never will be. ENOENT means "No >>> such file and directory", and is for path operations. ioctl's are done >>> on files that have already been opened, there's no way in hell that >>> ENOENT would ever be valid. >>> >>> Perhaps we should rethink the use of ENOENT when not finding mode >>> objects? >> >> Yeah, it's somewhat abuse, otoh if we'd do a dma-buf export telling >> userspace that "no such file exists" is a pretty precise answer. In a way >> we _do_ duplicate file objects ... And having this special error code for >> lookup failures is occasionally rather useful imo. >> >> So honestly I'd prefer we keep on doing our practice. > > > Hmm, yes, I figure this might have originated in the GEM ioctls that was > actually trying to mimic file behavior, > but then spilled over to the mode objects in the modesetting code... > > Just thought I'd raise the issue since I saw that message.. > We just need to make sure userspace relies on it, then we can't change it :-P Linus would enter an infinite loop and possibly explode. Dave.
[Bug 66241] radeon fails to initialise the monitor
https://bugzilla.kernel.org/show_bug.cgi?id=66241 --- Comment #5 from Chris Rankin --- Created attachment 117331 --> https://bugzilla.kernel.org/attachment.cgi?id=117331&action=edit dmesg output with 2nd patch applied No, the additional patch did not help. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 72291] vdpau: freeze when moving video to another screen
https://bugs.freedesktop.org/show_bug.cgi?id=72291 --- Comment #5 from David "okias" Heidelberger --- linux-firmware from : 20130728 http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/log/ at same date. -- 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/20131204/6f867f72/attachment.html>
[Bug 72291] vdpau: freeze when moving video to another screen
https://bugs.freedesktop.org/show_bug.cgi?id=72291 --- Comment #6 from Dieter N?tzel --- (In reply to comment #4) > I also experience this problem on my HD5770 card. As far as I can remember > it existed back when the UVD code was first released. > > The freeze happens when a majority of the video windows is moved to the > other screen. I guess it has something to do with vsync being changed to the > other screen. > > I also run git of all relevant packages except the kernel and I use up to > date radeon-ucode. Which kernel are you running - 3.12.1/2? Then please try 3.13-rc2. 3.12.x missing some UVD fixes from Cristain K?nig, currently. Works for me on RV730 AGP. But APU is a nother thing at this time ;-) -- 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/20131204/7187ecc2/attachment.html>
[PATCH] drm: shmob_drm: Check clk_prepare_enable() return value
Hi Thierry, On Tuesday 03 December 2013 10:59:24 Thierry Reding wrote: > On Mon, Dec 02, 2013 at 01:52:20AM +0100, Laurent Pinchart wrote: > [...] > > > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c > > b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c > [...] > > > @@ -170,7 +178,9 @@ static void shmob_drm_crtc_start(struct shmob_drm_crtc > > *scrtc) > > return; > > > > /* Enable clocks before accessing the hardware. */ > > - shmob_drm_clk_on(sdev); > > + ret = shmob_drm_clk_on(sdev); > > + if (ret < 0) > > + return; > > Perhaps this should be printing an error or using WARN_ON()? Otherwise > it might be very difficult to diagnose what's going wrong. That's a good point. In practice, as the driver always uses a Renesas SoC MSTP clock, the clock code will print a message to the kernel log though, so I'm not sure whether we should duplicate that here. If you think we should I'll submit a new patch. -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131204/041078b0/attachment.pgp>
[Bug 72283] [] dce6_afmt_write_speaker_allocation+0xdb/0x140 [radeon]
https://bugs.freedesktop.org/show_bug.cgi?id=72283 Michel D?nzer changed: What|Removed |Added Product|Mesa|DRI Version|git |unspecified Component|Drivers/Gallium/r600|DRM/Radeon -- 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/20131204/2e1637d7/attachment.html>
[Bug 72159] Zapping 1.15.0 RC3 hangs system on Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=72159 --- Comment #11 from Michel D?nzer --- (In reply to comment #8) > When I run "sudo Xorg -configure" I get: Why -configure? You want to run the X server, not configure it. :) What I'm looking for, but not seeing, is this line at the end of the X server shutdown: (EE) Server terminated successfully (0). Closing log file. So it seems like the X server either dies uncleanly for you, or hangs during shutdown. In the former case, there should be more information in the X server's stderr output. The latter case will be hard to debug without ssh access I'm afraid. -- 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/20131204/3f125b51/attachment-0001.html>
[Bug 66384] VDPAU playback hangs when moving window between xrandr monitors
https://bugs.freedesktop.org/show_bug.cgi?id=66384 Michel D?nzer changed: What|Removed |Added CC||david.heidelberger at ixit.cz --- Comment #3 from Michel D?nzer --- *** Bug 72291 has been marked as a duplicate of this bug. *** -- 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/20131204/714fe274/attachment.html>
[Bug 72291] vdpau: freeze when moving video to another screen
https://bugs.freedesktop.org/show_bug.cgi?id=72291 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Michel D?nzer --- *** This bug has been marked as a duplicate of bug 66384 *** -- 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/20131204/16933ea8/attachment.html>
[Bug 66341] Screen dead
https://bugzilla.kernel.org/show_bug.cgi?id=66341 --- Comment #2 from svily0 at yahoo.com --- Created attachment 117351 --> https://bugzilla.kernel.org/attachment.cgi?id=117351&action=edit Xorg.log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 66341] Screen dead
https://bugzilla.kernel.org/show_bug.cgi?id=66341 --- Comment #3 from svily0 at yahoo.com --- Created attachment 117361 --> https://bugzilla.kernel.org/attachment.cgi?id=117361&action=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 29/32] drm/exynos: Implement drm_connector directly in dp driver
2013/12/3 Inki Dae :
> Hi Sean,
>
>
> 2013/10/30 Sean Paul :
>> This patch implements drm_connector directly in the dp driver, this will
>> allow us to move away from the exynos_drm_connector layer.
>>
>> Signed-off-by: Sean Paul
>> ---
>>
>> Changes in v3:
>> - Added to the patchset
>>
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 99
>> ++---
>> drivers/gpu/drm/exynos/exynos_dp_core.h | 4 ++
>> 2 files changed, 94 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 476d3b0..139ea15 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -22,10 +22,15 @@
>> #include
>>
>> #include
>> +#include
>> +#include
>>
>> #include "exynos_drm_drv.h"
>> #include "exynos_dp_core.h"
>>
>> +#define ctx_from_connector(c) container_of(c, struct exynos_dp_device, \
>> + connector)
>> +
>> static int exynos_dp_init_dp(struct exynos_dp_device *dp)
>> {
>> exynos_dp_reset(dp);
>> @@ -896,21 +901,98 @@ static void exynos_dp_hotplug(struct work_struct *work)
>> dev_err(dp->dev, "unable to config video\n");
>> }
>>
>> -static bool exynos_dp_display_is_connected(struct exynos_drm_display
>> *display)
>> +static enum drm_connector_status exynos_dp_detect(
>> + struct drm_connector *connector, bool force)
>> {
>> - return true;
>> + return connector_status_connected;
>
> No, eDP can be hot-plugged. Check if lcd panel is connected or not,
> and if connected then return connector_status_connected else
> connector_status_disconnected. See the interrupt handler.
>
>> }
>>
>> -static void *exynos_dp_get_panel(struct exynos_drm_display *display)
>> +static void exynos_dp_connector_destroy(struct drm_connector *connector)
>> {
>> - struct exynos_dp_device *dp = display->ctx;
>> +}
>> +
>> +static struct drm_connector_funcs exynos_dp_connector_funcs = {
>> + .dpms = drm_helper_connector_dpms,
>> + .fill_modes = drm_helper_probe_single_connector_modes,
>> + .detect = exynos_dp_detect,
>> + .destroy = exynos_dp_connector_destroy,
>> +};
>> +
>> +static int exynos_dp_get_modes(struct drm_connector *connector)
>> +{
>> + struct exynos_dp_device *dp = ctx_from_connector(connector);
>> + struct drm_display_mode *mode;
>> +
>> + mode = drm_mode_create(connector->dev);
>> + if (!mode) {
>> + DRM_ERROR("failed to create a new display mode.\n");
>> + return 0;
>> + }
>>
>> - return &dp->panel;
>> + drm_display_mode_from_videomode(&dp->panel.vm, mode);
>> + mode->width_mm = dp->panel.width_mm;
>> + mode->height_mm = dp->panel.height_mm;
>> + connector->display_info.width_mm = mode->width_mm;
>> + connector->display_info.height_mm = mode->height_mm;
>> +
>> + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
>> + drm_mode_set_name(mode);
>> + drm_mode_probed_add(connector, mode);
>> +
>> + return 1;
>> }
>>
>> -static int exynos_dp_check_mode(struct exynos_drm_display *display,
>> +static int exynos_dp_mode_valid(struct drm_connector *connector,
>> struct drm_display_mode *mode)
>> {
>> + return MODE_OK;
>> +}
>> +
>> +static struct drm_encoder *exynos_dp_best_encoder(
>> + struct drm_connector *connector)
>> +{
>> + struct exynos_dp_device *dp = ctx_from_connector(connector);
>> +
>> + return dp->encoder;
>
> eDP context doesn't need a encoder as its member. And you can get best
> encoder through connector->encoder.
>
Ah~ when drm is closed, connector->encoder could be NULL so it is
needed to connect again.
Sorry.
>> +}
>> +
>> +static struct drm_connector_helper_funcs exynos_dp_connector_helper_funcs =
>> {
>> + .get_modes = exynos_dp_get_modes,
>> + .mode_valid = exynos_dp_mode_valid,
>> + .best_encoder = exynos_dp_best_encoder,
>> +};
>> +
>> +static int exynos_dp_initialize(struct exynos_drm_display *display,
>> + struct drm_device *drm_dev)
>> +{
>> + struct exynos_dp_device *dp = display->ctx;
>> +
>> + dp->drm_dev = drm_dev;
>> +
>> + return 0;
>> +}
>> +
>> +static int exynos_dp_create_connector(struct exynos_drm_display *display,
>> + struct drm_encoder *encoder)
>> +{
>> + struct exynos_dp_device *dp = display->ctx;
>> + struct drm_connector *connector = &dp->connector;
>> + int ret;
>> +
>> + dp->encoder = encoder;
>
> Unnecessary line, Add connector->encoder = encoder instead.
Ignore it.
>
>> + connector->polled = DRM_CONNECTOR_POLL_HPD;
>> +
>> + ret = drm_connector_init(dp->drm_dev, connector,
>> + &exynos_dp_connector_funcs, DRM_MODE_CONNECTOR_eDP);
>> +
[PATCH v3 30/32] drm/exynos: Implement drm_connector directly in vidi driver
Sorry, there was my missing point. Ignore the below my comments.
Thanks,
Inki Dae
2013/12/3 Inki Dae :
> 2013/10/30 Sean Paul :
>> This patch implements drm_connector directly in the vidi
>> driver, this will allow us to move away from the exynos_drm_connector
>> layer.
>>
>> Signed-off-by: Sean Paul
>> ---
>>
>> Changes in v3:
>> - Added to the patchset
>>
>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 163
>> ---
>> 1 file changed, 107 insertions(+), 56 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> index 7d79b6c..5104431 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> @@ -29,6 +29,8 @@
>> #define WINDOWS_NR 3
>>
>> #define get_vidi_mgr(dev) platform_get_drvdata(to_platform_device(dev))
>> +#define ctx_from_connector(c) container_of(c, struct vidi_context, \
>> + connector)
>>
>> struct vidi_win_data {
>> unsigned intoffset_x;
>> @@ -47,6 +49,8 @@ struct vidi_win_data {
>> struct vidi_context {
>> struct drm_device *drm_dev;
>> struct drm_crtc *crtc;
>> + struct drm_encoder *encoder;
>
> Unnecessary member.
>
>> + struct drm_connectorconnector;
>> struct vidi_win_datawin_data[WINDOWS_NR];
>> struct edid *raw_edid;
>> unsigned intclkdiv;
>> @@ -86,62 +90,6 @@ static const char fake_edid_info[] = {
>> 0x00, 0x00, 0x00, 0x06
>> };
>>
>> -static bool vidi_display_is_connected(struct exynos_drm_display *display)
>> -{
>> - struct vidi_context *ctx = display->ctx;
>> -
>> - /*
>> -* connection request would come from user side
>> -* to do hotplug through specific ioctl.
>> -*/
>> - return ctx->connected ? true : false;
>> -}
>> -
>> -static struct edid *vidi_get_edid(struct exynos_drm_display *display,
>> - struct drm_connector *connector)
>> -{
>> - struct vidi_context *ctx = display->ctx;
>> - struct edid *edid;
>> - int edid_len;
>> -
>> - /*
>> -* the edid data comes from user side and it would be set
>> -* to ctx->raw_edid through specific ioctl.
>> -*/
>> - if (!ctx->raw_edid) {
>> - DRM_DEBUG_KMS("raw_edid is null.\n");
>> - return ERR_PTR(-EFAULT);
>> - }
>> -
>> - edid_len = (1 + ctx->raw_edid->extensions) * EDID_LENGTH;
>> - edid = kmemdup(ctx->raw_edid, edid_len, GFP_KERNEL);
>> - if (!edid) {
>> - DRM_DEBUG_KMS("failed to allocate edid\n");
>> - return ERR_PTR(-ENOMEM);
>> - }
>> -
>> - return edid;
>> -}
>> -
>> -static int vidi_check_mode(struct exynos_drm_display *display,
>> - struct drm_display_mode *mode)
>> -{
>> - /* TODO. */
>> -
>> - return 0;
>> -}
>> -
>> -static struct exynos_drm_display_ops vidi_display_ops = {
>> - .is_connected = vidi_display_is_connected,
>> - .get_edid = vidi_get_edid,
>> - .check_mode = vidi_check_mode,
>> -};
>> -
>> -static struct exynos_drm_display vidi_display = {
>> - .type = EXYNOS_DISPLAY_TYPE_VIDI,
>> - .ops = &vidi_display_ops,
>> -};
>> -
>> static void vidi_apply(struct exynos_drm_manager *mgr)
>> {
>> struct vidi_context *ctx = mgr->ctx;
>> @@ -536,6 +484,109 @@ int vidi_connection_ioctl(struct drm_device *drm_dev,
>> void *data,
>> return 0;
>> }
>>
>> +static enum drm_connector_status vidi_detect(struct drm_connector
>> *connector,
>> + bool force)
>> +{
>> + struct vidi_context *ctx = ctx_from_connector(connector);
>> +
>> + /*
>> +* connection request would come from user side
>> +* to do hotplug through specific ioctl.
>> +*/
>> + return ctx->connected ? connector_status_connected :
>> + connector_status_disconnected;
>> +}
>> +
>> +static void vidi_connector_destroy(struct drm_connector *connector)
>> +{
>> +}
>> +
>> +static struct drm_connector_funcs vidi_connector_funcs = {
>> + .dpms = drm_helper_connector_dpms,
>> + .fill_modes = drm_helper_probe_single_connector_modes,
>> + .detect = vidi_detect,
>> + .destroy = vidi_connector_destroy,
>> +};
>> +
>> +static int vidi_get_modes(struct drm_connector *connector)
>> +{
>> + struct vidi_context *ctx = ctx_from_connector(connector);
>> + struct edid *edid;
>> + int edid_len;
>> +
>> + /*
>> +* the edid data comes from user side and it would be set
>> +* to ctx->raw_edid through specific ioctl.
>> +*/
>> + if (!ctx->raw_edid) {
>> + DRM_DEBUG_KMS("raw_edid is null.\n");
>> + return -EFAULT;
>> +
[Bug 72159] Zapping 1.15.0 RC3 hangs system on Radeon
https://bugs.freedesktop.org/show_bug.cgi?id=72159 octoploid changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #12 from octoploid --- I don't have the time and the resources to debug this further. Closed. -- 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/20131204/349eac3c/attachment.html>
[PATCH] drm: shmob_drm: Check clk_prepare_enable() return value
On Wed, Dec 04, 2013 at 02:38:21AM +0100, Laurent Pinchart wrote: > Hi Thierry, > > On Tuesday 03 December 2013 10:59:24 Thierry Reding wrote: > > On Mon, Dec 02, 2013 at 01:52:20AM +0100, Laurent Pinchart wrote: > > [...] > > > > > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c > > > b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c > > [...] > > > > > @@ -170,7 +178,9 @@ static void shmob_drm_crtc_start(struct shmob_drm_crtc > > > *scrtc) > > > return; > > > > > > /* Enable clocks before accessing the hardware. */ > > > - shmob_drm_clk_on(sdev); > > > + ret = shmob_drm_clk_on(sdev); > > > + if (ret < 0) > > > + return; > > > > Perhaps this should be printing an error or using WARN_ON()? Otherwise > > it might be very difficult to diagnose what's going wrong. > > That's a good point. In practice, as the driver always uses a Renesas SoC > MSTP > clock, the clock code will print a message to the kernel log though, so I'm > not sure whether we should duplicate that here. If you think we should I'll > submit a new patch. Is that one of the clocks implemented in drivers/sh/clk? There don't seem to be any error messages in the clk_enable() implementation. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131204/a1b34c70/attachment.pgp>
Nouveau failing during probe followed by GPF on 3.13-rc2
Hi, With 3.13-rc1 and 3.13-rc2 kernel crashes/BUGs while loading nouveau: [ 657.654915] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20131115/nsarguments-95) [ 657.655099] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20131115/nsarguments-95) [ 657.655270] checking generic (8001 64) vs hw (8000 1000) [ 657.655273] fb: conflicting fb hw usage nouveaufb vs simple - removing generic driver [ 657.655383] Console: switching to colour dummy device 80x25 [ 657.655632] nouveau :02:00.0: enabling device (0006 -> 0007) [ 657.657149] ACPI: PCI Interrupt Link [LGPU] enabled at IRQ 16 [ 657.657456] [drm] hdmi device not found 2 0 1 [ 657.657954] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac800b1 [ 657.657958] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC) [ 657.657960] nouveau [ DEVICE][:02:00.0] Family : NV50 [ 657.665274] nouveau [ VBIOS][:02:00.0] checking PRAMIN for image... [ 657.722478] nouveau [ VBIOS][:02:00.0] ... appears to be valid [ 657.722481] nouveau [ VBIOS][:02:00.0] using image from PRAMIN [ 657.722624] nouveau [ VBIOS][:02:00.0] BIT signature found [ 657.722627] nouveau [ VBIOS][:02:00.0] version 62.79.47.00.01 [ 657.745324] nouveau :02:00.0: irq 42 for MSI/MSI-X [ 657.745360] nouveau [ PMC][:02:00.0] MSI interrupts enabled [ 657.745437] nouveau [ PFB][:02:00.0] RAM type: stolen system memory [ 657.745441] nouveau [ PFB][:02:00.0] RAM size: 256 MiB [ 657.745444] nouveau [ PFB][:02:00.0]ZCOMP: 0 tags [ 657.800072] nouveau [ PTHERM][:02:00.0] FAN control: none / external [ 657.800083] nouveau [ PTHERM][:02:00.0] fan management: automatic [ 657.800086] nouveau [ PTHERM][:02:00.0] internal sensor: yes [ 657.800105] nouveau [ CLK][:02:00.0] 03: core 100 MHz shader 200 MHz [ 657.800111] nouveau [ CLK][:02:00.0] 05: core 150 MHz shader 300 MHz [ 657.800116] nouveau [ CLK][:02:00.0] 0e: core 300 MHz shader 600 MHz [ 657.800121] nouveau [ CLK][:02:00.0] 0f: core 350 MHz shader 800 MHz [ 657.800135] nouveau E[ CLK][:02:00.0] 17 freq unknown [ 657.800137] nouveau E[ CLK][:02:00.0] init failed, -22 [ 657.800140] nouveau E[ DRM] failed to create 0x8080, -22 [ 657.802123] general protection fault: [#1] SMP [ 657.802130] Modules linked in: nouveau(+) ttm drm_kms_helper [ 657.802140] CPU: 0 PID: 2999 Comm: modprobe Not tainted 3.13.0-rc2-air+ #5 [ 657.802144] Hardware name: Apple Inc. MacBookAir2,1/Mac-F42D88C8, BIOS MBA21.88Z.0075.B03.0811141325 11/14/08 [ 657.802150] task: 88007f161520 ti: 88007defe000 task.ti: 88007defe000 [ 657.802154] RIP: 0010:[] [] device_del+0x10/0x1b0 [ 657.802165] RSP: 0018:88007deff9f8 EFLAGS: 00010292 [ 657.802168] RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 81a6f237 [ 657.802173] RDX: 81876dea RSI: 81a6e811 RDI: 6b6b6b6b6b6b6b6b [ 657.802177] RBP: 88007deffa18 R08: 6b6b6b6b R09: [ 657.802181] R10: 880078801d00 R11: 002e R12: 6b6b6b6b6b6b6b6b [ 657.802185] R13: 88007f5720f8 R14: a010e7a0 R15: ffea [ 657.802189] FS: 7f3c23d75700() GS:88007b00() knlGS: [ 657.802194] CS: 0010 DS: ES: CR0: 8005003b [ 657.802198] CR2: 7f27436e40f0 CR3: 7db4e000 CR4: 07f0 [ 657.802201] Stack: [ 657.802204] 8134fd0b 6b6b6b6b6b6b6b6b 88007f572060 88007f5720f8 [ 657.802211] 88007deffa38 813d2ca1 88007d938058 88007da01ca8 [ 657.802217] 88007deffa58 813bdd6a 88007f572060 88007da01ca8 [ 657.802224] Call Trace: [ 657.802231] [] ? acpi_pci_irq_disable+0x3c/0x49 [ 657.802237] [] device_unregister+0x11/0x20 [ 657.802243] [] drm_sysfs_device_remove+0x1a/0x30 [ 657.802249] [] drm_unplug_minor+0x1d/0x40 [ 657.802255] [] drm_put_minor+0x3d/0x50 [ 657.802260] [] drm_dev_free+0x18/0x80 [ 657.802265] [] drm_get_pci_dev+0xaf/0x150 [ 657.802272] [] ? pcibios_set_master+0x5e/0x90 [ 657.802315] [] nouveau_drm_probe+0x24a/0x290 [nouveau] [ 657.802321] [] pci_device_probe+0x9c/0xf0 [ 657.802328] [] driver_probe_device+0x76/0x240 [ 657.802333] [] __driver_attach+0x9b/0xa0 [ 657.802339] [] ? driver_probe_device+0x240/0x240 [ 657.802345] [] bus_for_each_dev+0x55/0x90 [ 657.802350] [] driver_attach+0x19/0x20 [ 657.802355] [] bus_add_driver+0x10c/0x210 [ 657.802360] [] ? 0xa0132fff [ 657.802365] [] driver_register+0x5f/0xf0 [ 657.802370] [] ? 0xa0132fff [ 657.802375] [] __pci_register_driver+0x47/0x50 [ 657.802381] [] drm_pci_init+0x115/0x130 [ 657.802386] [] ? 0xa0132fff [ 657.802390] [] ? 0xa0132fff [ 657.
Nouveau failing during probe followed by GPF on 3.13-rc2
On Wed, Dec 4, 2013 at 6:01 AM, Bruno Pr?mont wrote: > Hi, > > With 3.13-rc1 and 3.13-rc2 kernel crashes/BUGs while loading nouveau: > [ 657.654915] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type > mismatch - Found [Integer], ACPI requires [Package] (20131115/nsarguments-95) > [ 657.655099] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type > mismatch - Found [Buffer], ACPI requires [Package] (20131115/nsarguments-95) > [ 657.655270] checking generic (8001 64) vs hw (8000 1000) > [ 657.655273] fb: conflicting fb hw usage nouveaufb vs simple - removing > generic driver > [ 657.655383] Console: switching to colour dummy device 80x25 > [ 657.655632] nouveau :02:00.0: enabling device (0006 -> 0007) > [ 657.657149] ACPI: PCI Interrupt Link [LGPU] enabled at IRQ 16 > [ 657.657456] [drm] hdmi device not found 2 0 1 > [ 657.657954] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac800b1 > [ 657.657958] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC) > [ 657.657960] nouveau [ DEVICE][:02:00.0] Family : NV50 > [ 657.665274] nouveau [ VBIOS][:02:00.0] checking PRAMIN for image... > [ 657.722478] nouveau [ VBIOS][:02:00.0] ... appears to be valid > [ 657.722481] nouveau [ VBIOS][:02:00.0] using image from PRAMIN > [ 657.722624] nouveau [ VBIOS][:02:00.0] BIT signature found > [ 657.722627] nouveau [ VBIOS][:02:00.0] version 62.79.47.00.01 > [ 657.745324] nouveau :02:00.0: irq 42 for MSI/MSI-X > [ 657.745360] nouveau [ PMC][:02:00.0] MSI interrupts enabled > [ 657.745437] nouveau [ PFB][:02:00.0] RAM type: stolen system > memory > [ 657.745441] nouveau [ PFB][:02:00.0] RAM size: 256 MiB > [ 657.745444] nouveau [ PFB][:02:00.0]ZCOMP: 0 tags > [ 657.800072] nouveau [ PTHERM][:02:00.0] FAN control: none / external > [ 657.800083] nouveau [ PTHERM][:02:00.0] fan management: automatic > [ 657.800086] nouveau [ PTHERM][:02:00.0] internal sensor: yes > [ 657.800105] nouveau [ CLK][:02:00.0] 03: core 100 MHz shader 200 > MHz > [ 657.800111] nouveau [ CLK][:02:00.0] 05: core 150 MHz shader 300 > MHz > [ 657.800116] nouveau [ CLK][:02:00.0] 0e: core 300 MHz shader 600 > MHz > [ 657.800121] nouveau [ CLK][:02:00.0] 0f: core 350 MHz shader 800 > MHz > [ 657.800135] nouveau E[ CLK][:02:00.0] 17 freq unknown > [ 657.800137] nouveau E[ CLK][:02:00.0] init failed, -22 There are some patches in http://cgit.freedesktop.org/nouveau/linux-2.6/log/?h=drm-nouveau-next that should help with that, specifically: http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=drm-nouveau-next&id=a7e4201f0f7d47e03b851f06f8987856e8d33083 > [ 657.800140] nouveau E[ DRM] failed to create 0x8080, -22 > [ 657.802123] general protection fault: [#1] SMP > [ 657.802130] Modules linked in: nouveau(+) ttm drm_kms_helper > [ 657.802140] CPU: 0 PID: 2999 Comm: modprobe Not tainted 3.13.0-rc2-air+ #5 > [ 657.802144] Hardware name: Apple Inc. MacBookAir2,1/Mac-F42D88C8, BIOS > MBA21.88Z.0075.B03.0811141325 11/14/08 > [ 657.802150] task: 88007f161520 ti: 88007defe000 task.ti: > 88007defe000 > [ 657.802154] RIP: 0010:[] [] > device_del+0x10/0x1b0 > [ 657.802165] RSP: 0018:88007deff9f8 EFLAGS: 00010292 > [ 657.802168] RAX: RBX: 6b6b6b6b6b6b6b6b RCX: > 81a6f237 > [ 657.802173] RDX: 81876dea RSI: 81a6e811 RDI: > 6b6b6b6b6b6b6b6b > [ 657.802177] RBP: 88007deffa18 R08: 6b6b6b6b R09: > > [ 657.802181] R10: 880078801d00 R11: 002e R12: > 6b6b6b6b6b6b6b6b > [ 657.802185] R13: 88007f5720f8 R14: a010e7a0 R15: > ffea > [ 657.802189] FS: 7f3c23d75700() GS:88007b00() > knlGS: > [ 657.802194] CS: 0010 DS: ES: CR0: 8005003b > [ 657.802198] CR2: 7f27436e40f0 CR3: 7db4e000 CR4: > 07f0 > [ 657.802201] Stack: > [ 657.802204] 8134fd0b 6b6b6b6b6b6b6b6b 88007f572060 > 88007f5720f8 > [ 657.802211] 88007deffa38 813d2ca1 88007d938058 > 88007da01ca8 > [ 657.802217] 88007deffa58 813bdd6a 88007f572060 > 88007da01ca8 > [ 657.802224] Call Trace: > [ 657.802231] [] ? acpi_pci_irq_disable+0x3c/0x49 > [ 657.802237] [] device_unregister+0x11/0x20 > [ 657.802243] [] drm_sysfs_device_remove+0x1a/0x30 > [ 657.802249] [] drm_unplug_minor+0x1d/0x40 > [ 657.802255] [] drm_put_minor+0x3d/0x50 > [ 657.802260] [] drm_dev_free+0x18/0x80 > [ 657.802265] [] drm_get_pci_dev+0xaf/0x150 > [ 657.802272] [] ? pcibios_set_master+0x5e/0x90 > [ 657.802315] [] nouveau_drm_probe+0x24a/0x290 [nouveau] > [ 657.802321] [] pci_device_probe+0x9c/0xf0 > [ 657.802328] [] driver_probe_device+0x76/0x240 > [ 657.802333] [] __driver_attach+0x9b/0xa0 > [ 65
[Bug 72307] New: [radeonsi] radeonsi_dri.so undefined symbol: setupterm
https://bugs.freedesktop.org/show_bug.cgi?id=72307 Priority: medium Bug ID: 72307 Assignee: dri-devel at lists.freedesktop.org Summary: [radeonsi] radeonsi_dri.so undefined symbol: setupterm Severity: normal Classification: Unclassified OS: Linux (All) Reporter: neatnoise at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 90220 --> https://bugs.freedesktop.org/attachment.cgi?id=90220&action=edit Xorg log Hello. I can see following errors when starting Xorg: failed to open /usr/lib64/dri/radeonsi_dri.so: /usr/lib64/dri/radeonsi_dri.so: undefined symbol: setupterm gbm: failed to open any driver (search paths /usr/lib64/dri)failed to load driver: radeonsi failed to load module: /usr/lib64/gbm/gbm_gallium_drm.so: cannot open shared object file: No such file or directory couldn't get display device Program received signal SIGSEGV, Segmentation fault. 0x0020e116 in ?? () OS: Gentoo User space packages: media-libs/mesa git sys-devel/llvm git x11-libs/libdrm git x11-libs/glamor git x11-drivers/xf86-video-ati git x11-base/xorg-server 1.14.3 Linux Kernel: 3.13.0-rc2 Mesa source config: ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --disable-silent-rules --disable-dependency-tracking --enable-dri --enable-glx --enable-shared-glapi --enable-texture-float --disable-debug --enable-egl --enable-gbm --disable-gles1 --disable-gles2 --enable-glx-tls --disable-osmesa --enable-asm --without-llvm-shared-libs --with-dri-drivers=,swrast,radeon,r200 --with-gallium-drivers=,swrast,radeonsi,r300,r600 PYTHON2=/usr/bin/python2.7 --with-egl-platforms=x11,drm --enable-gallium-llvm --disable-openvg --disable-gallium-egl --enable-r600-llvm-compiler --enable-vdpau --disable-xa --disable-xvmc -- 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/20131204/13a5a0cc/attachment.html>
[Bug 72307] [radeonsi] radeonsi_dri.so undefined symbol: setupterm
https://bugs.freedesktop.org/show_bug.cgi?id=72307 --- Comment #1 from Tom --- Created attachment 90221 --> https://bugs.freedesktop.org/attachment.cgi?id=90221&action=edit dmesg log -- 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/20131204/2aec7a51/attachment.html>
[PATCH] drm: Push dirtyfb ioctl kms locking down to drivers
From: Ville Syrj?l?
Not all drivers will need take all the modeset locks for dirtyfb, so
push the locking down to the drivers.
Signed-off-by: Ville Syrj?l?
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 2 --
drivers/gpu/drm/omapdrm/omap_fb.c | 4
drivers/gpu/drm/qxl/qxl_display.c | 9 -
drivers/gpu/drm/udl/udl_fb.c| 12 +---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 18 --
5 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d6cf77c..266a01d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2767,10 +2767,8 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
}
if (fb->funcs->dirty) {
- drm_modeset_lock_all(dev);
ret = fb->funcs->dirty(fb, file_priv, flags, r->color,
clips, num_clips);
- drm_modeset_unlock_all(dev);
} else {
ret = -ENOSYS;
}
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index f2b8f06..f466c4a 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -123,12 +123,16 @@ static int omap_framebuffer_dirty(struct drm_framebuffer
*fb,
{
int i;
+ drm_modeset_lock_all(fb->dev);
+
for (i = 0; i < num_clips; i++) {
omap_framebuffer_flush(fb, clips[i].x1, clips[i].y1,
clips[i].x2 - clips[i].x1,
clips[i].y2 - clips[i].y1);
}
+ drm_modeset_unlock_all(fb->dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 5e827c2..b8f3bc7 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -399,10 +399,14 @@ static int qxl_framebuffer_surface_dirty(struct
drm_framebuffer *fb,
struct qxl_bo *qobj;
int inc = 1;
+ drm_modeset_lock_all(fb->dev);
+
qobj = gem_to_qxl_bo(qxl_fb->obj);
/* if we aren't primary surface ignore this */
- if (!qobj->is_primary)
+ if (!qobj->is_primary) {
+ drm_modeset_unlock_all(fb->dev);
return 0;
+ }
if (!num_clips) {
num_clips = 1;
@@ -417,6 +421,9 @@ static int qxl_framebuffer_surface_dirty(struct
drm_framebuffer *fb,
qxl_draw_dirty_fb(qdev, qxl_fb, qobj, flags, color,
clips, num_clips, inc);
+
+ drm_modeset_unlock_all(fb->dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 97e9d61..dbadd49 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -403,15 +403,17 @@ static int udl_user_framebuffer_dirty(struct
drm_framebuffer *fb,
int i;
int ret = 0;
+ drm_modeset_lock_all(fb->dev);
+
if (!ufb->active_16)
- return 0;
+ goto unlock;
if (ufb->obj->base.import_attach) {
ret =
dma_buf_begin_cpu_access(ufb->obj->base.import_attach->dmabuf,
0, ufb->obj->base.size,
DMA_FROM_DEVICE);
if (ret)
- return ret;
+ goto unlock;
}
for (i = 0; i < num_clips; i++) {
@@ -419,7 +421,7 @@ static int udl_user_framebuffer_dirty(struct
drm_framebuffer *fb,
clips[i].x2 - clips[i].x1,
clips[i].y2 - clips[i].y1);
if (ret)
- break;
+ goto unlock;
}
if (ufb->obj->base.import_attach) {
@@ -427,6 +429,10 @@ static int udl_user_framebuffer_dirty(struct
drm_framebuffer *fb,
0, ufb->obj->base.size,
DMA_FROM_DEVICE);
}
+
+ unlock:
+ drm_modeset_unlock_all(fb->dev);
+
return ret;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index ecb3d86..ab0b88f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -608,9 +608,13 @@ int vmw_framebuffer_surface_dirty(struct drm_framebuffer
*framebuffer,
if (!dev_priv->sou_priv)
return -EINVAL;
+ drm_modeset_lock_all(dev_priv->dev);
+
ret = ttm_read_lock(&vmaster->lock, true);
- if (unlikely(ret != 0))
+ if (unlikely(ret != 0)) {
+ drm_modeset_unlock_all(dev_priv->dev);
return ret;
+ }
if (!num_clips) {
num_clips = 1;
@@ -628,6 +632,9 @@ int vmw_framebuffer_surface_dirty(struct drm_framebuffer
*framebuffer,
clips, num_clips, inc, NUL
[PATCH] drm: Push dirtyfb ioctl kms locking down to drivers
Looks good to me
Reviewed-by: Jakob Bornecrant
On Wed, Dec 4, 2013 at 1:13 PM, wrote:
> From: Ville Syrj?l?
>
> Not all drivers will need take all the modeset locks for dirtyfb, so
> push the locking down to the drivers.
>
> Signed-off-by: Ville Syrj?l?
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 2 --
> drivers/gpu/drm/omapdrm/omap_fb.c | 4
> drivers/gpu/drm/qxl/qxl_display.c | 9 -
> drivers/gpu/drm/udl/udl_fb.c| 12 +---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 18 --
> 5 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d6cf77c..266a01d 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2767,10 +2767,8 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> }
>
> if (fb->funcs->dirty) {
> - drm_modeset_lock_all(dev);
> ret = fb->funcs->dirty(fb, file_priv, flags, r->color,
>clips, num_clips);
> - drm_modeset_unlock_all(dev);
> } else {
> ret = -ENOSYS;
> }
> diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
> b/drivers/gpu/drm/omapdrm/omap_fb.c
> index f2b8f06..f466c4a 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fb.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
> @@ -123,12 +123,16 @@ static int omap_framebuffer_dirty(struct
> drm_framebuffer *fb,
> {
> int i;
>
> + drm_modeset_lock_all(fb->dev);
> +
> for (i = 0; i < num_clips; i++) {
> omap_framebuffer_flush(fb, clips[i].x1, clips[i].y1,
> clips[i].x2 - clips[i].x1,
> clips[i].y2 - clips[i].y1);
> }
>
> + drm_modeset_unlock_all(fb->dev);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 5e827c2..b8f3bc7 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -399,10 +399,14 @@ static int qxl_framebuffer_surface_dirty(struct
> drm_framebuffer *fb,
> struct qxl_bo *qobj;
> int inc = 1;
>
> + drm_modeset_lock_all(fb->dev);
> +
> qobj = gem_to_qxl_bo(qxl_fb->obj);
> /* if we aren't primary surface ignore this */
> - if (!qobj->is_primary)
> + if (!qobj->is_primary) {
> + drm_modeset_unlock_all(fb->dev);
> return 0;
> + }
>
> if (!num_clips) {
> num_clips = 1;
> @@ -417,6 +421,9 @@ static int qxl_framebuffer_surface_dirty(struct
> drm_framebuffer *fb,
>
> qxl_draw_dirty_fb(qdev, qxl_fb, qobj, flags, color,
> clips, num_clips, inc);
> +
> + drm_modeset_unlock_all(fb->dev);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index 97e9d61..dbadd49 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -403,15 +403,17 @@ static int udl_user_framebuffer_dirty(struct
> drm_framebuffer *fb,
> int i;
> int ret = 0;
>
> + drm_modeset_lock_all(fb->dev);
> +
> if (!ufb->active_16)
> - return 0;
> + goto unlock;
>
> if (ufb->obj->base.import_attach) {
> ret =
> dma_buf_begin_cpu_access(ufb->obj->base.import_attach->dmabuf,
>0, ufb->obj->base.size,
>DMA_FROM_DEVICE);
> if (ret)
> - return ret;
> + goto unlock;
> }
>
> for (i = 0; i < num_clips; i++) {
> @@ -419,7 +421,7 @@ static int udl_user_framebuffer_dirty(struct
> drm_framebuffer *fb,
> clips[i].x2 - clips[i].x1,
> clips[i].y2 - clips[i].y1);
> if (ret)
> - break;
> + goto unlock;
> }
>
> if (ufb->obj->base.import_attach) {
> @@ -427,6 +429,10 @@ static int udl_user_framebuffer_dirty(struct
> drm_framebuffer *fb,
>0, ufb->obj->base.size,
>DMA_FROM_DEVICE);
> }
> +
> + unlock:
> + drm_modeset_unlock_all(fb->dev);
> +
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index ecb3d86..ab0b88f 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -608,9 +608,13 @@ int vmw_framebuffer_surface_dirty(struct drm_framebuffer
> *framebuffer,
> if (!dev_priv->sou_priv)
> return -EINVAL;
>
> + drm_modeset_lock_all(dev_priv->dev);
> +
> ret = ttm_read_lock(&vmaster->lock, true);
> -
[PATCH] udl: fix issue with imported prime buffers
5dc9e1e8 was a bit over-ambitious, and accidentially removed handling
for imported prime buffers.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/udl/udl_gem.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 24ffbe9..8d67b94 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -125,6 +125,12 @@ static int udl_gem_get_pages(struct udl_gem_object *obj,
gfp_t gfpmask)
static void udl_gem_put_pages(struct udl_gem_object *obj)
{
+ if (obj->base.import_attach) {
+ drm_free_large(obj->pages);
+ obj->pages = NULL;
+ return;
+ }
+
drm_gem_put_pages(&obj->base, obj->pages, false, false);
obj->pages = NULL;
}
--
1.8.4.2
drm/ttm: Print debug information on memory manager when eviction fails
Hello Jerome Glisse,
The patch fb53f8621a3f: "drm/ttm: Print debug information on memory
manager when eviction fails" from Dec 9, 2009, leads to the following
static checker warning: "drivers/gpu/drm/ttm/ttm_bo.c:1494
ttm_mem_reg_is_pci()
warn: buffer overflow 'bdev->man' 8 <= 8"
drivers/gpu/drm/ttm/ttm_bo.c
56 static inline int ttm_mem_type_from_flags(uint32_t flags, uint32_t
*mem_type)
57 {
58 int i;
59
60 for (i = 0; i <= TTM_PL_PRIV5; i++)
61 if (flags & (1 << i)) {
62 *mem_type = i;
63 return 0;
64 }
65 return -EINVAL;
66 }
--- [snip] to the ttm_bo_mem_space() function:
869 for (i = 0; i < placement->num_placement; ++i) {
870 ret = ttm_mem_type_from_flags(placement->placement[i],
871 &mem_type);
872 if (ret)
873 return ret;
874 man = &bdev->man[mem_type];
875
So after ttm_mem_type_from_flags then mem_type can be TTM_PL_PRIV5 (8)
but the bdev->man[] array only has TTM_NUM_MEM_TYPES (8) elements so we
are one space beyond the end of the array.
regards,
dan carpenter
[PATCH] drm: shmob_drm: Check clk_prepare_enable() return value
Hi Thierry, On Wednesday 04 December 2013 11:01:07 Thierry Reding wrote: > On Wed, Dec 04, 2013 at 02:38:21AM +0100, Laurent Pinchart wrote: > > On Tuesday 03 December 2013 10:59:24 Thierry Reding wrote: > > > On Mon, Dec 02, 2013 at 01:52:20AM +0100, Laurent Pinchart wrote: > > > [...] > > > > > > > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c > > > > b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c > > > > > > [...] > > > > > > > @@ -170,7 +178,9 @@ static void shmob_drm_crtc_start(struct > > > > shmob_drm_crtc > > > > *scrtc) > > > > > > > > return; > > > > > > > > /* Enable clocks before accessing the hardware. */ > > > > > > > > - shmob_drm_clk_on(sdev); > > > > + ret = shmob_drm_clk_on(sdev); > > > > + if (ret < 0) > > > > + return; > > > > > > Perhaps this should be printing an error or using WARN_ON()? Otherwise > > > it might be very difficult to diagnose what's going wrong. > > > > That's a good point. In practice, as the driver always uses a Renesas SoC > > MSTP clock, the clock code will print a message to the kernel log though, > > so I'm not sure whether we should duplicate that here. If you think we > > should I'll submit a new patch. > > Is that one of the clocks implemented in drivers/sh/clk? Correct, and in drivers/clk/shmobile/clk-mstp.c when http://www.spinics.net/lists/devicetree/msg12696.html will be merged. > There don't seem to be any error messages in the clk_enable() > implementation. There will be one when http://www.spinics.net/lists/linux-sh/msg25650.html will get merged :-) Before that enabling the clock never failed, with the patch applied the failure is logged. -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131204/8410e272/attachment.pgp>
[Bug 72283] [] dce6_afmt_write_speaker_allocation+0xdb/0x140 [radeon]
https://bugs.freedesktop.org/show_bug.cgi?id=72283 --- Comment #2 from bgunteriv at gmail.com --- this patch did not fix the issue. should I attach newer logs? -- 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/20131204/ca38b28e/attachment.html>
Nouveau failing during probe followed by GPF on 3.13-rc2
Hi Ilia, On Wed, 4 Dec 2013 06:15:30 -0500 Ilia Mirkin wrote: > On Wed, Dec 4, 2013 at 6:01 AM, Bruno Pr?mont wrote: > > With 3.13-rc1 and 3.13-rc2 kernel crashes/BUGs while loading nouveau: > > [ 657.654915] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type > > mismatch - Found [Integer], ACPI requires [Package] > > (20131115/nsarguments-95) > > [ 657.655099] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type > > mismatch - Found [Buffer], ACPI requires [Package] (20131115/nsarguments-95) > > [ 657.655270] checking generic (8001 64) vs hw (8000 1000) > > [ 657.655273] fb: conflicting fb hw usage nouveaufb vs simple - removing > > generic driver > > [ 657.655383] Console: switching to colour dummy device 80x25 > > [ 657.655632] nouveau :02:00.0: enabling device (0006 -> 0007) > > [ 657.657149] ACPI: PCI Interrupt Link [LGPU] enabled at IRQ 16 > > [ 657.657456] [drm] hdmi device not found 2 0 1 > > [ 657.657954] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac800b1 > > [ 657.657958] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC) > > [ 657.657960] nouveau [ DEVICE][:02:00.0] Family : NV50 > > [ 657.665274] nouveau [ VBIOS][:02:00.0] checking PRAMIN for > > image... > > [ 657.722478] nouveau [ VBIOS][:02:00.0] ... appears to be valid > > [ 657.722481] nouveau [ VBIOS][:02:00.0] using image from PRAMIN > > [ 657.722624] nouveau [ VBIOS][:02:00.0] BIT signature found > > [ 657.722627] nouveau [ VBIOS][:02:00.0] version 62.79.47.00.01 > > [ 657.745324] nouveau :02:00.0: irq 42 for MSI/MSI-X > > [ 657.745360] nouveau [ PMC][:02:00.0] MSI interrupts enabled > > [ 657.745437] nouveau [ PFB][:02:00.0] RAM type: stolen system > > memory > > [ 657.745441] nouveau [ PFB][:02:00.0] RAM size: 256 MiB > > [ 657.745444] nouveau [ PFB][:02:00.0]ZCOMP: 0 tags > > [ 657.800072] nouveau [ PTHERM][:02:00.0] FAN control: none / > > external > > [ 657.800083] nouveau [ PTHERM][:02:00.0] fan management: automatic > > [ 657.800086] nouveau [ PTHERM][:02:00.0] internal sensor: yes > > [ 657.800105] nouveau [ CLK][:02:00.0] 03: core 100 MHz shader > > 200 MHz > > [ 657.800111] nouveau [ CLK][:02:00.0] 05: core 150 MHz shader > > 300 MHz > > [ 657.800116] nouveau [ CLK][:02:00.0] 0e: core 300 MHz shader > > 600 MHz > > [ 657.800121] nouveau [ CLK][:02:00.0] 0f: core 350 MHz shader > > 800 MHz > > [ 657.800135] nouveau E[ CLK][:02:00.0] 17 freq unknown > > [ 657.800137] nouveau E[ CLK][:02:00.0] init failed, -22 > > There are some patches in > http://cgit.freedesktop.org/nouveau/linux-2.6/log/?h=drm-nouveau-next > that should help with that, specifically: > > http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=drm-nouveau-next&id=a7e4201f0f7d47e03b851f06f8987856e8d33083 Yes, that one prevents the "freq unknown" error! It should probably be pushed to dave/linus for rc3. With it applied nouveau loads successfully. > > [ 657.800140] nouveau E[ DRM] failed to create 0x8080, -22 > > [ 657.802123] general protection fault: [#1] SMP > > [ 657.802130] Modules linked in: nouveau(+) ttm drm_kms_helper > > [ 657.802140] CPU: 0 PID: 2999 Comm: modprobe Not tainted 3.13.0-rc2-air+ > > #5 > > [ 657.802144] Hardware name: Apple Inc. MacBookAir2,1/Mac-F42D88C8, BIOS > > MBA21.88Z.0075.B03.0811141325 11/14/08 > > [ 657.802150] task: 88007f161520 ti: 88007defe000 task.ti: > > 88007defe000 > > [ 657.802154] RIP: 0010:[] [] > > device_del+0x10/0x1b0 > > [ 657.802165] RSP: 0018:88007deff9f8 EFLAGS: 00010292 > > [ 657.802168] RAX: RBX: 6b6b6b6b6b6b6b6b RCX: > > 81a6f237 > > [ 657.802173] RDX: 81876dea RSI: 81a6e811 RDI: > > 6b6b6b6b6b6b6b6b > > [ 657.802177] RBP: 88007deffa18 R08: 6b6b6b6b R09: > > > > [ 657.802181] R10: 880078801d00 R11: 002e R12: > > 6b6b6b6b6b6b6b6b > > [ 657.802185] R13: 88007f5720f8 R14: a010e7a0 R15: > > ffea > > [ 657.802189] FS: 7f3c23d75700() GS:88007b00() > > knlGS: > > [ 657.802194] CS: 0010 DS: ES: CR0: 8005003b > > [ 657.802198] CR2: 7f27436e40f0 CR3: 7db4e000 CR4: > > 07f0 > > [ 657.802201] Stack: > > [ 657.802204] 8134fd0b 6b6b6b6b6b6b6b6b 88007f572060 > > 88007f5720f8 > > [ 657.802211] 88007deffa38 813d2ca1 88007d938058 > > 88007da01ca8 > > [ 657.802217] 88007deffa58 813bdd6a 88007f572060 > > 88007da01ca8 > > [ 657.802224] Call Trace: > > [ 657.802231] [] ? acpi_pci_irq_disable+0x3c/0x49 > > [ 657.802237] [] device_unregister+0x11/0x20 > > [ 657.802243] [] drm_sysfs_device_remove+0x1a/0x30 > > [ 657.802249] [] drm_unplug_minor+0x1d/0x40 > > [ 657.80225
[Bug 64781] RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 --- Comment #7 from Giannis --- I tested with various rates (44100-48000-92000) and problem is not fixed. Also I tested kernel 3.13-RC1 and bug is still there. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64781] RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 --- Comment #8 from Giannis --- plus, I did a video playback with VLC. In this case video speed is ok but audio has gaps every 0.5 seconds approximately. -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC PATCH v3] mipi-dsi-bus: add MIPI DSI bus support
MIPI DSI bus allows to model DSI hosts and DSI devices using Linux bus.
DSI host should be registered by DSI master driver. During registration
DSI devices will be created according to Device Tree sub-nodes,
registration based on board info will be added later.
DSI host exposes operations which can be used by slave drivers
to access associated devices.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
Hi Thierry,
This is the 3rd version of MIPI DSI bus patch.
Most of changes comes from Thierry comments.
The main difference is complete change of 'philosophy' behind it.
In previous version DSI host could be standalone driver without DRM
dependency. In the current version it should be DRM device.
This change breaks my drivers so I cannot test this version of patch on live
system yet.
There are few things which still bother me:
- DSI mode flags - some of them seems to be too specific for my HW,
- other DSI parameters, probably there should be more, like max clock,
supported pixel modes,
Regards
Andrzej
drivers/gpu/drm/Kconfig| 3 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_mipi_dsi.c | 316 +
include/drm/drm_mipi_dsi.h | 155
4 files changed, 475 insertions(+)
create mode 100644 drivers/gpu/drm/drm_mipi_dsi.c
create mode 100644 include/drm/drm_mipi_dsi.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f864275..30fb2ad 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -20,6 +20,9 @@ menuconfig DRM
details. You should also select and configure AGP
(/dev/agpgart) support if it is available for your platform.
+config DRM_MIPI_DSI
+ bool
+
config DRM_USB
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index cc08b84..6266c6c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
CFLAGS_drm_trace_points.o := -I$(src)
obj-$(CONFIG_DRM) += drm.o
+obj-$(CONFIG_DRM_MIPI_DSI) += mipi_dsi.o
obj-$(CONFIG_DRM_USB) += drm_usb.o
obj-$(CONFIG_DRM_TTM) += ttm/
obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
new file mode 100644
index 000..047e632
--- /dev/null
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -0,0 +1,316 @@
+/*
+ * MIPI DSI Bus
+ *
+ * Copyright (C) 2012-2013, Samsung Electronics, Co., Ltd.
+ * Andrzej Hajda
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static struct mipi_dsi_device *of_mipi_dsi_device_new(struct mipi_dsi_host
*host,
+ struct device_node *node);
+
+int mipi_dsi_host_register(struct mipi_dsi_host *host)
+{
+ struct device_node *node;
+
+ for_each_available_child_of_node(host->dev->of_node, node)
+ of_mipi_dsi_device_new(host, node);
+
+ return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_host_register);
+
+static int mipi_dsi_remove_device_fn(struct device *dev, void *priv)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(dev);
+
+ device_unregister(&dsi->dev);
+
+ return 0;
+}
+
+void mipi_dsi_host_unregister(struct mipi_dsi_host *host)
+{
+ device_for_each_child(host->dev, NULL, mipi_dsi_remove_device_fn);
+}
+EXPORT_SYMBOL(mipi_dsi_host_unregister);
+
+static int mipi_dsi_device_match(struct device *dev, struct device_driver *drv)
+{
+ return of_driver_match_device(dev, drv);
+}
+
+static const struct dev_pm_ops mipi_dsi_device_pm_ops = {
+ .runtime_suspend = pm_generic_runtime_suspend,
+ .runtime_resume = pm_generic_runtime_resume,
+ .suspend = pm_generic_suspend,
+ .resume = pm_generic_resume,
+
[Bug 72307] [radeonsi] radeonsi_dri.so undefined symbol: setupterm
https://bugs.freedesktop.org/show_bug.cgi?id=72307 --- Comment #2 from Tom Stellard --- Are you using gentoo's - ebuild for LLVM or are you building it yourself? Can you post the output of llvm-config --ldflags and also equery u ncurses -- 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/20131204/ed90da46/attachment.html>
[PATCH 0/4] Add dt support for exynos hdmiphy settings
For various revisions of a chipset if the signal pattern is changed for every revision, then the phy setting need to be updated correspondingly by measuring the signal. For getting correct signals the clock level and data de-emphasis levels needs to be adjusted. Since only these 2 values matter,we can move the same to dt, wherein we can have different dt files for every revision. This is an initial patchset towards achieving the same for exynos 5250 and can be later extended to future chipsets. V2: replaced moving of entire phy config structure with only required and justifiable conf registers. V3: Incorporated Mark Rutland's comments. V4: Rebased and included cros5250-common.dtsi. V5: removed nr-configs feild and also the constraint of having the exact number of configs in the dt file as in the driver, the programmer can add only the pixel clock that needs to be updated. V6: V7: removed nr-configs form the dtsi files. V8: Fixed build error V9: rebased and incorporated Tomasz comments. Shirish S (4): ARM: dts: smdk5250: Add hdmi phy settings ARM: dts: arndale: Add hdmi phy settings ARM: exynos: dts: cros5250: Add hdmi phy settings drm: exynos: hdmi: Add dt support for hdmiphy settings .../devicetree/bindings/video/exynos_hdmi.txt | 34 arch/arm/boot/dts/cros5250-common.dtsi | 74 arch/arm/boot/dts/exynos5250-arndale.dts | 74 arch/arm/boot/dts/exynos5250-smdk5250.dts | 74 drivers/gpu/drm/exynos/exynos_hdmi.c | 89 5 files changed, 327 insertions(+), 18 deletions(-) -- 1.7.9.5
[PATCH 2/4] ARM: dts: arndale: Add hdmi phy settings
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-arndale.dts | 74 ++
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index cee55fa..6bc562c 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -475,6 +475,80 @@
vdd_osc-supply = <&ldo10_reg>;
vdd_pll-supply = <&ldo8_reg>;
vdd-supply = <&ldo8_reg>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ config0: config0 {
+ samsung,pixel-clock = <2520>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ samsung,pixel-clock = <2700>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ samsung,pixel-clock = <27027000>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ samsung,pixel-clock = <3600>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ samsung,pixel-clock = <4000>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ samsung,pixel-clock = <6500>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ samsung,pixel-clock = <74176000>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ samsung,pixel-clock = <7425>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ samsung,pixel-clock = <8350>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ samsung,pixel-clock = <10650>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ samsung,pixel-clock = <10800>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ samsung,pixel-clock = <14625>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ samsung,pixel-clock = <14850>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
regulators {
--
1.7.9.5
[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings
Hi Tomasz,
Thanks for the reivew, please see my replies inline.
On Fri, Nov 29, 2013 at 10:56 PM, Tomasz Figa wrote:
> Hi Shirish,
>
> Please see my comments inline.
>
> On Monday 25 of November 2013 14:24:39 Shirish S wrote:
>> This patch adds dt support to hdmiphy config settings
>> as it is board specific and depends on the signal pattern
>> of board.
>>
>> Signed-off-by: Shirish S
>> ---
>> .../devicetree/bindings/video/exynos_hdmi.txt | 31
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 77
>> +++-
>> 2 files changed, 104 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> index 323983b..6eeb333 100644
>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> @@ -13,6 +13,30 @@ Required properties:
>> b) pin number within the gpio controller.
>> c) optional flags and pull up/down.
>>
>> +- hdmiphy-configs: following information about the hdmiphy config settings.
>
> Is this node required or optional? If it's required, then it breaks
> compatibility with already existing DTBs, which is not desirable.
>
Yes its an Optional-but-recommended node, and i have mentioned the same
in this document in next patch set(v9).
>> + a) "config: config" specifies the phy configuration settings,
>> + where 'N' denotes the number of configuration, since every
>> + pixel clock can have its unique configuration.
>
> Node names should not have any semantic meaning for parsing code. I know
> that there are already existing bindings which rely on presence of
> particularly named nodes, but that's not right and new bindings should
> not follow that.
>
I referred Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
for the implementation, am not clear with what you want me to do here, however
the requirement seems similar as pinctrl, can u kindly suggest any
existing newer
implementations to refer.
> Also what do you need the label of each config node for?
>
Each label here is a different pixel clock and corresponding phy setting, and
it may vary from one pixel clock to other hence i need one for each config node.
> Generally from parsing perspective you shouldn't really care about node
> names. All you seem to do in the driver is iterating over all specified
> nodes and matching them with internal driver data using pixel clock
> frequency.
>
True, that is what i intended to do.I think for the requirement
at hand, this should be fine.
>> + "pixel-clock" specifies the pixel clock
>
> Vendor-specific properties should have vendor prefix, so this one should
> be called "samsung,pixel-clock".
>
Agreed, updated in the next patch set(v9).
>> + "conifig-de-emphasis-level" provides fine control of TMDS data
>
> Typo: s/conifig/config
>
> Also it should be called "samsung,de-emphasis-level".
>
Agreed, updated in the next patch set(v9).
>> + pre emphasis, below shown is example for
>> + data de-emphasis register at address 0x145D0040.
>> + hdmiphy at 38[16] for bits[3:0] permitted values are in
>> + the range of 760 mVdiff to 1400 mVdiff at 20mVdiff
>> + increments for every LSB
>> + hdmiphy at 38[16] for bits[7:4] permitted values are in
>> + the range of 0dB to -7.45dB at increments of -0.45dB
>> + for every LSB.
>> + "config-clock-level" provides fine control of TMDS data
>
> "samsung,clock-level"
>
Agreed, updated in the next patch set(v9).
>> + amplitude for each channel,
>> + for example if 0x145D005C is the address of clock level
> [snip]
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 32ce9a6..5f599e3 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> [snip]
>> +static int drm_hdmi_dt_parse_phy_conf(struct platform_device *pdev,
>> + struct hdmi_context *hdata)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct device_node *dev_np = dev->of_node;
>> + struct device_node *phy_conf, *cfg_np;
>> + int i, pixel_clock = 0;
>> +
>> + /* Initialize with default config */
>> + hdata->confs = hdmiphy_v14_configs;
>> + hdata->nr_confs = ARRAY_SIZE(hdmiphy_v14_configs);
>> +
>> + phy_conf = of_find_node_by_name(dev_np, "hdmiphy-configs");
>
> of_find_node_by_name() does not do what you need here. Please refer to
> its implementation to learn why.
>
> What you need here is of_get_child_by_name().
>
Agreed, updated in the next patch set(v9).
>> + if (phy_conf == NULL) {
>> + hdata->nr_confs = ARRAY_SIZE(hdmiphy_v14_configs);
>> + DRM_ERROR("Did
[PATCH 3/4] ARM: exynos: dts: cros5250: Add hdmi phy settings
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/cros5250-common.dtsi | 74
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index dc259e8b..45c8583 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -301,6 +301,80 @@
hdmi {
hpd-gpio = <&gpx3 7 0>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ config0: config0 {
+ samsung,pixel-clock = <2520>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ samsung,pixel-clock = <2700>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ samsung,pixel-clock = <27027000>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ samsung,pixel-clock = <3600>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ samsung,pixel-clock = <4000>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ samsung,pixel-clock = <6500>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ samsung,pixel-clock = <74176000>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ samsung,pixel-clock = <7425>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ samsung,pixel-clock = <8350>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ samsung,pixel-clock = <10650>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ samsung,pixel-clock = <10800>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ samsung,pixel-clock = <14625>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ samsung,pixel-clock = <14850>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
gpio-keys {
--
1.7.9.5
[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings
This patch adds dt support to hdmiphy config settings
as it is board specific and depends on the signal pattern
of board.
Signed-off-by: Shirish S
---
.../devicetree/bindings/video/exynos_hdmi.txt | 34
drivers/gpu/drm/exynos/exynos_hdmi.c | 89
2 files changed, 105 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 323983b..0766e6e 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -13,6 +13,31 @@ Required properties:
b) pin number within the gpio controller.
c) optional flags and pull up/down.
+Optional-but-recommended properties:
+- hdmiphy-configs: following information about the hdmiphy config settings.
+ a) "config: config" specifies the phy configuration settings,
+ where 'N' denotes the number of configuration, since every
+ pixel clock can have its unique configuration.
+ "samsung,pixel-clock" specifies the pixel clock
+ "samsung,de-emphasis-level" provides fine control of TMDS data
+pre emphasis, below shown is example for
+ data de-emphasis register at address 0x145D0040.
+ hdmiphy at 38[16] for bits[3:0] permitted values are in
+ the range of 760 mVdiff to 1400 mVdiff at 20mVdiff
+ increments for every LSB
+ hdmiphy at 38[16] for bits[7:4] permitted values are in
+ the range of 0dB to -7.45dB at increments of -0.45dB
+ for every LSB.
+ "samsung,clock-level" provides fine control of TMDS data
+ amplitude for each channel,
+ for example if 0x145D005C is the address of clock level
+ register then,
+ hdmiphy at 38[23] for bits [1:0] permitted values are in
+ the range of 0 mVdiff & 60 mVdiff for each channel at
+ increments 20 mVdiff of amplitude levels for every LSB,
+ hdmiphy at 38[23] for bits [7:3] permitted values are in
+ the range of 790 and 1430 mV at 20mV increments for
+ every LSB.
Example:
hdmi {
@@ -20,4 +45,13 @@ Example:
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = <&gpx3 7 1>;
+ hdmiphy-configs {
+ config0: config0 {
+ samsung,pixel-clock = <2520>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+
+ /* ... */
+ }
};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a0e10ae..2fa0074 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -200,6 +200,9 @@ struct hdmi_context {
struct hdmi_resources res;
+ struct hdmiphy_config *confs;
+ int nr_confs;
+
int hpd_gpio;
enum hdmi_type type;
@@ -259,7 +262,7 @@ static const struct hdmiphy_config hdmiphy_v13_configs[] = {
},
};
-static const struct hdmiphy_config hdmiphy_v14_configs[] = {
+static struct hdmiphy_config hdmiphy_v14_configs[] = {
{
.pixel_clock = 2520,
.conf = {
@@ -771,20 +774,10 @@ static struct edid *hdmi_get_edid(void *ctx, struct
drm_connector *connector)
static int hdmi_find_phy_conf(struct hdmi_context *hdata, u32 pixel_clock)
{
- const struct hdmiphy_config *confs;
- int count, i;
-
- if (hdata->type == HDMI_TYPE13) {
- confs = hdmiphy_v13_configs;
- count = ARRAY_SIZE(hdmiphy_v13_configs);
- } else if (hdata->type == HDMI_TYPE14) {
- confs = hdmiphy_v14_configs;
- count = ARRAY_SIZE(hdmiphy_v14_configs);
- } else
- return -EINVAL;
+ int i;
- for (i = 0; i < count; i++)
- if (confs[i].pixel_clock == pixel_clock)
+ for (i = 0; i < hdata->nr_confs; i++)
+ if (hdata->confs[i].pixel_clock == pixel_clock)
return i;
DRM_DEBUG_KMS("Could not find phy config for %d\n", pixel_clock);
@@ -1363,10 +1356,7 @@ static void hdmiphy_conf_apply(struct hdmi_context
*hdata)
return;
}
- if (hdata->type == HDMI_TYPE13)
- hdmiphy_data = hdmiphy_v13_configs[i].conf;
- else
- hdmiphy_data = hdmiphy_v14_configs[i].conf;
+ hdmiphy_data = hdata-
[PATCH 1/4] ARM: dts: smdk5250: Add hdmi phy settings
This patch moves the hdmi phy setting to smdk5250
dts,as its more of a per board configuration and
also shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 74 +
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 2538b32..10da02f 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -220,6 +220,80 @@
hdmi {
hpd-gpio = <&gpx3 7 0>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ config0: config0 {
+ samsung,pixel-clock = <2520>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ samsung,pixel-clock = <2700>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ samsung,pixel-clock = <27027000>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ samsung,pixel-clock = <3600>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ samsung,pixel-clock = <4000>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ samsung,pixel-clock = <6500>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ samsung,pixel-clock = <74176000>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ samsung,pixel-clock = <7425>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ samsung,pixel-clock = <8350>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ samsung,pixel-clock = <10650>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ samsung,pixel-clock = <10800>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ samsung,pixel-clock = <14625>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ samsung,pixel-clock = <14850>;
+ samsung,de-emphasis-level = /bits/ 8 <0x26>;
+ samsung,clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
codec at 1100 {
--
1.7.9.5
Radeon driver crashes when rebooting with 3.13-rc2
I keep on getting this: Any thoughts? I hadn't tried to do a bisection or such. [ 1784.126124] Console: switching to colour VGA+ 80x25 [ 1784.128286] drm_kms_helper: drm: unregistered panic notifier [ 1784.133601] [drm] radeon: finishing device. [ 1784.135934] BUG: unable to handle kernel NULL pointer dereference at 0378 [ 1784.135942] IP: [] post_xfer+0x18/0xb0 [radeon] [ 1784.135965] PGD 0 [ 1784.135968] Oops: [#1] SMP [ 1784.135972] Modules linked in: bnep bluetooth fuse tun xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn xenfs xen_privcmd snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec eeepc_wmi asus_wmi sparse_keymap snd_hwdep rfkill snd_seq snd_seq_device snd_pcm crc32c_intel ghash_clmulni_intel joydev snd_page_alloc serio_raw edac_core snd_timer pcspkr k10temp fam15h_power snd edac_mce_amd sp5100_tco r8169 i2c_piix4 soundcore mii shpchp uinput nouveau radeon video i2c_algo_bit drm_kms_helper ttm mxm_wmi drm usb_storage hid_logitech_dj i2c_core wmi ecryptfs encrypted_keys trusted tpm [last unloaded: iptable_raw] [ 1784.136027] CPU: 0 PID: 128 Comm: kworker/0:2 Tainted: GW 3.13.0-rc2+ #21 [ 1784.136031] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE R2.0, BIOS 1903 07/11/2013 [ 1784.136047] Workqueue: events radeon_hotplug_work_func [radeon] [ 1784.136051] task: 880130fc4860 ti: 88000a64a000 task.ti: 88000a64a000 [ 1784.136055] RIP: e030:[] [] post_xfer+0x18/0xb0 [radeon] [ 1784.136070] RSP: e02b:88000a64bbf8 EFLAGS: 00010246 [ 1784.136073] RAX: RBX: RCX: [ 1784.136076] RDX: f761bf4d RSI: 7e28 RDI: 880009d9e848 [ 1784.136080] RBP: 88000a64bc08 R08: 0200 R09: a00b9120 [ 1784.136084] R10: R11: 0001 R12: [ 1784.136087] R13: 0007 R14: 88000a64bd38 R15: [ 1784.136094] FS: 7f2c95b48740() GS:88013fe0() knlGS: [ 1784.136098] CS: e033 DS: ES: CR0: 8005003b [ 1784.136102] CR2: 0378 CR3: 01c0c000 CR4: 00040660 [ 1784.136106] Stack: [ 1784.136108] 0002 88000a64bc88 a00659e3 [ 1784.136115] 880009d9e848 880009d9eb80 0002 0002 [ 1784.136121] 88000a64bd30 0001f59b42d1 880009d9e800 0a64bd370007 [ 1784.136128] Call Trace: [ 1784.136134] [] bit_xfer+0x273/0x890 [i2c_algo_bit] [ 1784.136142] [] __i2c_transfer+0x5c/0x70 [i2c_core] [ 1784.136149] [] i2c_transfer+0x5c/0xe0 [i2c_core] [ 1784.136164] [] radeon_ddc_probe+0xde/0x120 [radeon] [ 1784.136179] [] radeon_dvi_detect+0x69/0x500 [radeon] [ 1784.136186] [] ? sched_clock+0x9/0x10 [ 1784.136193] [] drm_helper_hpd_irq_event+0x9d/0x160 [drm_kms_helper] [ 1784.136212] [] radeon_hotplug_work_func+0x5d/0x70 [radeon] [ 1784.136218] [] process_one_work+0x17b/0x460 [ 1784.136223] [] worker_thread+0x11b/0x400 [ 1784.136228] [] ? rescuer_thread+0x3e0/0x3e0 [ 1784.136233] [] kthread+0xd2/0xf0 [ 1784.136238] [] ? kthread_create_on_node+0x180/0x180 [ 1784.136244] [] ret_from_fork+0x7c/0xb0 [ 1784.136249] [] ? kthread_create_on_node+0x180/0x180 [ 1784.136252] Code: 44 d1 31 c9 09 c2 e8 48 d5 00 00 5b 41 5c 41 5d 5d c3 90 66 66 66 66 90 55 48 83 c7 48 48 89 e5 41 54 53 e8 1b 92 2b e1 48 89 c3 <48> 8b 80 78 03 00 00 31 d2 8b b3 cc 03 4.136301] RIP [] post_xfer+0x18/0xb0 [radeon] [ 1784.136316] RSP [ 1784.136318] CR2: 0378 [ 1784.136322] ---[ end trace ce465373f0865c07 ]--- [ 1784.136421] BUG: unable to handle kernel paging request at ffd8 [ 1784.136426] IP: [] kthread_data+0x10/0x20 [ 1784.136430] PGD 1c0f067 PUD 1c11067 PMD 0 [ 1784.136435] Oops: [#2] SMP [ 1784.136438] Modules linked in: bnep bluetooth fuse tun xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn xenfs xen_privcmd snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec eeepc_wmi asus_wmi sparse_keymap snd_hwdep rfkill snd_seq snd_seq_device snd_pcm crc32c_intel ghash_clmulni_intel joydev snd_page_alloc serio_raw edac_core snd_timer pcspkr k10temp fam15h_power snd edac_mce_amd sp5100_tco r8169 i2c_piix4 soundcore mii shpchp uinput nouveau radeon video i2c_algo_bit drm_kms_helper ttm mxm_wmi drm usb_storage hid_logitech_dj i2c_core wmi ecryptfs encrypted_keys trusted tpm [last unloaded: iptable_raw] [ 1784.136492] CPU: 0 PID: 128 Comm: kworker/0:2 Tainted: G D W 3.13.0-rc2+ #21 [ 1784.136495] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 LE R2.0, BIOS 1903 07/11/2013 [ 1784.136511] task: 880130fc4860 ti: 88000a64a000 task.ti: 88000a64a000 [ 1784.136514] RIP: e030:[] [] kthread_data+0x10/0x20 [ 1784.136520] RSP: e02b:88000a64b838 EFLAGS: 00010002 [ 1784.136523] RAX: RBX: RCX: 0001
[RFC PATCH v3] mipi-dsi-bus: add MIPI DSI bus support
On Wed, Dec 04, 2013 at 04:35:12PM +0100, Andrzej Hajda wrote: > MIPI DSI bus allows to model DSI hosts and DSI devices using Linux bus. > DSI host should be registered by DSI master driver. During registration > DSI devices will be created according to Device Tree sub-nodes, > registration based on board info will be added later. > DSI host exposes operations which can be used by slave drivers > to access associated devices. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Kyungmin Park > --- > Hi Thierry, > > This is the 3rd version of MIPI DSI bus patch. > Most of changes comes from Thierry comments. > The main difference is complete change of 'philosophy' behind it. > In previous version DSI host could be standalone driver without DRM > dependency. In the current version it should be DRM device. > This change breaks my drivers so I cannot test this version of patch on live > system yet.
[PATCH] drm: shmob_drm: Check clk_prepare_enable() return value
On Wed, Dec 04, 2013 at 03:37:48PM +0100, Laurent Pinchart wrote: > Hi Thierry, > > On Wednesday 04 December 2013 11:01:07 Thierry Reding wrote: > > On Wed, Dec 04, 2013 at 02:38:21AM +0100, Laurent Pinchart wrote: > > > On Tuesday 03 December 2013 10:59:24 Thierry Reding wrote: > > > > On Mon, Dec 02, 2013 at 01:52:20AM +0100, Laurent Pinchart wrote: > > > > [...] > > > > > > > > > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c > > > > > b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c > > > > > > > > [...] > > > > > > > > > @@ -170,7 +178,9 @@ static void shmob_drm_crtc_start(struct > > > > > shmob_drm_crtc > > > > > *scrtc) > > > > > > > > > > return; > > > > > > > > > > /* Enable clocks before accessing the hardware. */ > > > > > > > > > > - shmob_drm_clk_on(sdev); > > > > > + ret = shmob_drm_clk_on(sdev); > > > > > + if (ret < 0) > > > > > + return; > > > > > > > > Perhaps this should be printing an error or using WARN_ON()? Otherwise > > > > it might be very difficult to diagnose what's going wrong. > > > > > > That's a good point. In practice, as the driver always uses a Renesas SoC > > > MSTP clock, the clock code will print a message to the kernel log though, > > > so I'm not sure whether we should duplicate that here. If you think we > > > should I'll submit a new patch. > > > > Is that one of the clocks implemented in drivers/sh/clk? > > Correct, and in drivers/clk/shmobile/clk-mstp.c when > http://www.spinics.net/lists/devicetree/msg12696.html will be merged. > > > There don't seem to be any error messages in the clk_enable() > > implementation. > > There will be one when http://www.spinics.net/lists/linux-sh/msg25650.html > will get merged :-) Before that enabling the clock never failed, with the > patch applied the failure is logged. Alright, Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131204/8691ddb4/attachment.pgp>
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 Alex Deucher changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |DUPLICATE --- Comment #39 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 60389 *** -- 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/20131204/58298279/attachment.html>
[Bug 72307] [radeonsi] radeonsi_dri.so undefined symbol: setupterm
https://bugs.freedesktop.org/show_bug.cgi?id=72307 --- Comment #3 from Tom --- Yes It's gentoo's - ebuild. The rest of packages (mesa-, libdrm-, glamor-, xf86 driver-) is from x11 overlay. I reinstalled gentoo system with systemd and kde environment yesterday. It's a new gentoo system. I've never had such problem before (gnome 2 + openrc). $ llvm-config --ldflags -L/usr/lib/llvm -lpthread -lffi -ldl -lm ncurses flags enabled: cxx gpm unicode disabled: -ada -debug -doc -minimal -profile -static-libs -tinfo -trace Update. Thanks for a tip about ncurses. Gentoo KDE profile has set globally ncurses flag what carried it also to llvm. Ncurses support built in llvm leads to this error. I've disabled ncurses flag in llvm, rebuilt llvm and mesa and KDE desktop is working without any problem. -- 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/20131204/ab364c4f/attachment.html>
[Bug 66341] Screen dead
https://bugzilla.kernel.org/show_bug.cgi?id=66341 --- Comment #4 from Alex Deucher --- It looks like maybe you have a loose or bad connection to the LCD panel. As you can see in your log, the driver isn't even detecting a panel: [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA-1 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] HDMI-A-1 [drm] HPD1 [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 72283] [] dce6_afmt_write_speaker_allocation+0xdb/0x140 [radeon]
https://bugs.freedesktop.org/show_bug.cgi?id=72283 --- Comment #3 from Alex Deucher --- (In reply to comment #2) > this patch did not fix the issue. > > should I attach newer logs? Does the patch fix the segfault in dce6_afmt_write_speaker_allocation? -- 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/20131204/8d7ec03a/attachment.html>
[Bug 72283] [] dce6_afmt_write_speaker_allocation+0xdb/0x140 [radeon]
https://bugs.freedesktop.org/show_bug.cgi?id=72283 --- Comment #4 from Alex Deucher --- (In reply to comment #2) > this patch did not fix the issue. > > should I attach newer logs? Yes, please attach the logs with the patch applied. -- 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/20131204/d8849136/attachment.html>
[PATCH] drm: shmob_drm: Check clk_prepare_enable() return value
Hello, On Wednesday 04 December 2013 16:59:22 Thierry Reding wrote: > On Wed, Dec 04, 2013 at 03:37:48PM +0100, Laurent Pinchart wrote: > > On Wednesday 04 December 2013 11:01:07 Thierry Reding wrote: > > > On Wed, Dec 04, 2013 at 02:38:21AM +0100, Laurent Pinchart wrote: > > > > On Tuesday 03 December 2013 10:59:24 Thierry Reding wrote: > > > > > On Mon, Dec 02, 2013 at 01:52:20AM +0100, Laurent Pinchart wrote: > > > > > [...] > > > > > > > > > > > diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c > > > > > > b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c > > > > > > > > > > [...] > > > > > > > > > > > @@ -170,7 +178,9 @@ static void shmob_drm_crtc_start(struct > > > > > > shmob_drm_crtc *scrtc) > > > > > > return; > > > > > > > > > > > > /* Enable clocks before accessing the hardware. */ > > > > > > - shmob_drm_clk_on(sdev); > > > > > > + ret = shmob_drm_clk_on(sdev); > > > > > > + if (ret < 0) > > > > > > + return; > > > > > > > > > > Perhaps this should be printing an error or using WARN_ON()? > > > > > Otherwise it might be very difficult to diagnose what's going wrong. > > > > > > > > That's a good point. In practice, as the driver always uses a Renesas > > > > SoC MSTP clock, the clock code will print a message to the kernel log > > > > though, so I'm not sure whether we should duplicate that here. If you > > > > think we should I'll submit a new patch. > > > > > > Is that one of the clocks implemented in drivers/sh/clk? > > > > Correct, and in drivers/clk/shmobile/clk-mstp.c when > > http://www.spinics.net/lists/devicetree/msg12696.html will be merged. > > > > > There don't seem to be any error messages in the clk_enable() > > > implementation. > > > > There will be one when http://www.spinics.net/lists/linux-sh/msg25650.html > > will get merged :-) Before that enabling the clock never failed, with the > > patch applied the failure is logged. > > Alright, > > Reviewed-by: Thierry Reding Thank you. Dave, could you please pick this patch up for v3.14 ? -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131204/cc565036/attachment-0001.pgp>
[Bug 66241] radeon fails to initialise the monitor
https://bugzilla.kernel.org/show_bug.cgi?id=66241 Alex Deucher changed: What|Removed |Added Attachment #117321|0 |1 is obsolete|| --- Comment #6 from Alex Deucher --- Created attachment 117461 --> https://bugzilla.kernel.org/attachment.cgi?id=117461&action=edit possible fix Does this patch work any better? -- You are receiving this mail because: You are watching the assignee of the bug.
exynos-drm 1024x768 HDMI output
On Tue, Dec 3, 2013 at 5:07 PM, Daniel Drake wrote: > Hi, > > Thanks a lot for this exynos-drm commit: > > commit 62747fe0ad5169a767987d9009e3398466555cde > Author: Sean Paul > Date: Tue Jan 15 08:11:08 2013 -0500 > > drm/exynos: hdmi: support extra resolutions using drm_display_mode timings > > As you probably know, many people had written off the Exynos4's > capability to output to non-TV resolutions over HDMI. Now, with your > patch, 640x480 works perfectly, and other resolutions are hopefully > within reach. > Awesome, I'm glad it improved things :) > I would like to get 1024x768 working on Exynos4412. I'm using a Sony > TV which has an EDID that offers 1024x768 in its established timing > bitmap - i.e. it supports 1024x768 via the standard/ancient VESA > timings. I have tested the TV with other devices, it seems to work > fine at this res. > I assume this is the "1024x768 at 60Hz" mode in drm_edid.c? ie: hdisplay = 1024 hsync_start = 1048 hsync_end = 1184 htotal = 1344 vdisplay = 768 vsync_start = 771 vsync_end = 777 vtotal = 806 > However, on Exynos4412 with exynos-drm, running at this resolution is > not quite right. The very first row of pixels is rendered perfectly, > but all off the others are offset and wrapped. I'll try to explain > with some ASCII art: > > A > X > B > > Imagine that is the complete first 3 rows of pixels shown on my display. > The first row, with pixels A, is complete, and starts and finishes > where it should do on the physical display. > > However, the second row on the display starts with a series of > always-black pixels, this is the region marked X, which occupies 257 > pixels. Immediately after, the second row of pixels of the output > image starts (B), then when it hits the end of the screen, it wraps > around onto the next row of pixels on the screen. Then the third row > of the image pixels starts (C) and so on. > > Sounds like a hsync issue, right? I have been playing with the > register writes in hdmi_v14_mode_set() but I can't quite get a perfect > output. > > Is there any documentation available for these registers? Why do we > have to program the numbers twice (once in HDMI regs, once in timing > generator regs)? > I don't have any documentation for the 4412, so I'm flying blind as well. > Specifically, I have not yet found an explanation for why the first > row gets rendered right, and I haven't found a way to reduce the size > of region X, although I have figured out how to move it around: > > The standard timings for 1024x768 are: > hdisplay=1024 > hsync_start=1048 > hsync_end=1185 > htotal=1344 > > Using these numbers, exynos-drm writes: > tg->hact_st = 320 > tg->hact_sz = 1024 > > If I subtract and add 257 (the size of the black region X) respectively, i.e. > tg->hact_st = 63 > tg->hact_sz = 1288 > > Then I get the following: > > X > B > C > Have you tried: hact_st = 320 h_fsz += 257? hact_st specifies where to start scanning out the buffer, so it's not surprising that you're missing the first 257 pixels in this case. Maybe bumping up the full size of the h_line will help? Sean > i.e. all rows of displayed output are now fine, except for the first. > On the first row, the leftmost 257 pixels of output are no longer > visible anywhere, the rest of them start in the wrong place (top left, > rather than 257 pixels in), and the black region X is now positioned > at the right hand side of the first row. > > That is the closest I have found so far. > > Any thoughts or tips much appreciated. > > Thanks > Daniel
[Bug 58661] Chat text and other things flashing in Minecraft on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58661 Thomas Rohloff changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Thomas Rohloff --- I didn#t use r600g for some time now (used fglrx instead) but now this finally seems to be fixed! :) -- 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/20131204/3183dd94/attachment.html>
[Bug 58658] Minecraft menu broken on CAYMAN (caused by r600g: add htile support v16 patch)
https://bugs.freedesktop.org/show_bug.cgi?id=58658 Thomas Rohloff changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Thomas Rohloff --- I didn#t use r600g for some time now (used fglrx instead) but now this finally seems to be fixed! :) -- 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/20131204/4c72004e/attachment.html>
[Bug 53630] compiz + glamor = screen corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53630 Thomas Rohloff changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Thomas Rohloff --- I guess this is fixed (but can't tell for sure as I'm no longer using compiz). -- 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/20131204/0a8d846f/attachment.html>
[Bug 64781] RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 bpaterni at gmail.com changed: What|Removed |Added CC||bpaterni at gmail.com --- Comment #9 from bpaterni at gmail.com --- duplicate of freedesktop.org bug 71975? https://bugs.freedesktop.org/show_bug.cgi?id=71975 -- You are receiving this mail because: You are watching the assignee of the bug.
Nouveau failing during probe followed by GPF on 3.13-rc2
On Wed, Dec 4, 2013 at 6:15 AM, Ilia Mirkin wrote: > On Wed, Dec 4, 2013 at 6:01 AM, Bruno Pr?mont > wrote: >> [ 657.800140] nouveau E[ DRM] failed to create 0x8080, -22 >> [ 657.802123] general protection fault: [#1] SMP >> [ 657.802130] Modules linked in: nouveau(+) ttm drm_kms_helper >> [ 657.802140] CPU: 0 PID: 2999 Comm: modprobe Not tainted 3.13.0-rc2-air+ #5 >> [ 657.802144] Hardware name: Apple Inc. MacBookAir2,1/Mac-F42D88C8, BIOS >> MBA21.88Z.0075.B03.0811141325 11/14/08 >> [ 657.802150] task: 88007f161520 ti: 88007defe000 task.ti: >> 88007defe000 >> [ 657.802154] RIP: 0010:[] [] >> device_del+0x10/0x1b0 >> [ 657.802165] RSP: 0018:88007deff9f8 EFLAGS: 00010292 >> [ 657.802168] RAX: RBX: 6b6b6b6b6b6b6b6b RCX: >> 81a6f237 >> [ 657.802173] RDX: 81876dea RSI: 81a6e811 RDI: >> 6b6b6b6b6b6b6b6b >> [ 657.802177] RBP: 88007deffa18 R08: 6b6b6b6b R09: >> >> [ 657.802181] R10: 880078801d00 R11: 002e R12: >> 6b6b6b6b6b6b6b6b >> [ 657.802185] R13: 88007f5720f8 R14: a010e7a0 R15: >> ffea >> [ 657.802189] FS: 7f3c23d75700() GS:88007b00() >> knlGS: >> [ 657.802194] CS: 0010 DS: ES: CR0: 8005003b >> [ 657.802198] CR2: 7f27436e40f0 CR3: 7db4e000 CR4: >> 07f0 >> [ 657.802201] Stack: >> [ 657.802204] 8134fd0b 6b6b6b6b6b6b6b6b 88007f572060 >> 88007f5720f8 >> [ 657.802211] 88007deffa38 813d2ca1 88007d938058 >> 88007da01ca8 >> [ 657.802217] 88007deffa58 813bdd6a 88007f572060 >> 88007da01ca8 >> [ 657.802224] Call Trace: >> [ 657.802231] [] ? acpi_pci_irq_disable+0x3c/0x49 >> [ 657.802237] [] device_unregister+0x11/0x20 >> [ 657.802243] [] drm_sysfs_device_remove+0x1a/0x30 >> [ 657.802249] [] drm_unplug_minor+0x1d/0x40 >> [ 657.802255] [] drm_put_minor+0x3d/0x50 >> [ 657.802260] [] drm_dev_free+0x18/0x80 >> [ 657.802265] [] drm_get_pci_dev+0xaf/0x150 >> [ 657.802272] [] ? pcibios_set_master+0x5e/0x90 >> [ 657.802315] [] nouveau_drm_probe+0x24a/0x290 [nouveau] >> [ 657.802321] [] pci_device_probe+0x9c/0xf0 >> [ 657.802328] [] driver_probe_device+0x76/0x240 >> [ 657.802333] [] __driver_attach+0x9b/0xa0 >> [ 657.802339] [] ? driver_probe_device+0x240/0x240 >> [ 657.802345] [] bus_for_each_dev+0x55/0x90 >> [ 657.802350] [] driver_attach+0x19/0x20 >> [ 657.802355] [] bus_add_driver+0x10c/0x210 >> [ 657.802360] [] ? 0xa0132fff >> [ 657.802365] [] driver_register+0x5f/0xf0 >> [ 657.802370] [] ? 0xa0132fff >> [ 657.802375] [] __pci_register_driver+0x47/0x50 >> [ 657.802381] [] drm_pci_init+0x115/0x130 >> [ 657.802386] [] ? 0xa0132fff >> [ 657.802390] [] ? 0xa0132fff >> [ 657.802414] [] nouveau_drm_init+0x43/0x1000 [nouveau] >> [ 657.802422] [] do_one_initcall+0x11a/0x170 >> [ 657.802429] [] ? set_memory_nx+0x43/0x50 >> [ 657.802435] [] ? __vunmap+0xb2/0x100 >> [ 657.802441] [] load_module+0x1966/0x21b0 >> [ 657.802446] [] ? show_initstate+0x50/0x50 >> [ 657.802453] [] ? vfs_read+0x114/0x160 >> [ 657.802458] [] SyS_finit_module+0x86/0x90 >> [ 657.802465] [] system_call_fastpath+0x16/0x1b >> [ 657.802469] Code: 74 24 18 48 89 df e8 90 ff ff ff 48 8b 5d e8 4c 8b 65 >> f0 4c 8b 6d f8 c9 c3 66 90 55 48 89 e5 41 55 41 54 49 89 fc 53 48 83 ec 08 >> <48> 8b 87 88 00 00 00 4c 8b 2f 48 85 c0 74 1b 48 8b b8 90 00 00 >> [ 657.802514] RIP [] device_del+0x10/0x1b0 >> [ 657.802520] RSP >> [ 657.802524] ---[ end trace 11e780c61d88afaf ]--- >> >> I'm booting with efi stub and SYSFB=y, FB_SIMPLE=y, DRM_NOUVEAU=m >> Same config did boot properly with 3.12. Above output contains complete >> output from the time of calling modprobe nouveau. > > Hrm that is a separate bug that we should probably figure out. > Looks like some use-after-free when nouveau fails to come up (note the > poison 0x6b values in various registers). But the above patch will > hopefully prevent that situation. OK, so it looks like here's what happens: nouveau_drm_probe -> drm_get_pci_dev -> drm_dev_register-> nouveau_drm_load The load fails. In its cleanup path, drm_dev_register cleans up dev->primary/render/control and propagates the error. Reasonable enough. drm_get_pci_dev, in turn, calls drm_dev_free. The first thing that does is... clean up dev->primary/render/control. So that's the most likely source of the double-free. I'm not sufficiently familiar with the drm internals to know which function shouldn't be cleaning up what, but it definitely seems like a problem. Dave, I leave this in your capable hands :) -ilia
[PULL] vmwgfx-fixes-3.13
Hi, Dave. A couple of fixes. The biggest thing is the DMA buffer accounting that was incorrect. The following changes since commit 1b28c3e628315ac0d9ef2d3fac0403f05ae692db: drm/qxl: fix memory leak in release list handling (2013-11-29 08:36:15 +1000) are available in the git repository at: git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-3.13 for you to fetch changes up to 6a0a7a9ead2aa18c13dd8f76c5849daf7be1f45a: drm/vmwgfx: Add our connectors to sysfs (2013-12-04 12:04:02 -0800) Thomas Hellstrom (4): drm/vmwgfx: Correctly set the enabled state on crtcs drm/vmwgfx: Fix up and comment the dumb buffer implementation drm/vmwgfx: Fix dma buffer memory size accounting drm/vmwgfx: Add our connectors to sysfs drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |2 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |1 + drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |4 + drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 118 -- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |5 ++ 6 files changed, 94 insertions(+), 37 deletions(-)
[PATCH] drm/radeon: Disable writeback by default on ppc
On 11/25/2013 10:11 PM, Kleber Sacilotto de Souza wrote:
> On 11/24/2013 09:15 PM, Benjamin Herrenschmidt wrote:
>> On Fri, 2013-11-08 at 11:43 -0200, Kleber Sacilotto de Souza wrote:
>>> On 11/07/2013 08:29 PM, Benjamin Herrenschmidt wrote:
On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote:
> Weird. I wonder if there is an issue with cache snoops on PPC. We
> currently use the gart in cached mode (GPU snoops CPU cache) with
> cached pages. I wonder if we need to use uncached pages on PPC.
There is no such issue and no known bugs with DMA writes on those
PCIe host bridges (and they do get hammered pretty bad here).
This needs further investigation by the lab/hw guys to find out what's
actually happening on the bus and the host bridge.
Thadeu, Kleber: Jerome suggested writing a test case in userspace that
continuously writes to a spare scratch register (thus triggering the
corresponding writeback DMA) and checks the memory location to compare
the writeback value (using a debugfs file for example, or mmap).
I was not able to reproduce the issue with this method, even after a
weekend run.
However, doing some more investigation it seems the problem is here,
where we read the ring rptr:
u32 radeon_ring_generic_get_rptr(struct radeon_device *rdev,
struct radeon_ring *ring)
{
u32 rptr;
if (rdev->wb.enabled)
rptr = le32_to_cpu(rdev->wb.wb[ring->rptr_offs/4]);
else
rptr = RREG32(ring->rptr_reg);
return rptr;
}
I realized that the DMA'ed rptr value has always the opposite byte order
from the MMIO value. Since RREG32 already returns the register value on
the CPU byte order, it seems we don't need to byte-swap the DMA'ed
value. If I remove the le32_to_cpu() call and use the DMA'ed value
directly, I don't get the IB scheduling failures and piglit results are
the same as with writeback disabled.
Is the adapter chipset swapping the bytes before doing the DMA to a
big-endian host?
--
Kleber Sacilotto de Souza
IBM Linux Technology Center
[Bug 66241] radeon fails to initialise the monitor
https://bugzilla.kernel.org/show_bug.cgi?id=66241 --- Comment #7 from Chris Rankin --- Created attachment 117501 --> https://bugzilla.kernel.org/attachment.cgi?id=117501&action=edit dmesg output from 3.12.3 + 3rd patch I have just updated a second system from 3.11.10 to 3.12.3. This new system also experienced this bug, and the 3rd patch fixes it :-). I will test the 3rd patch on the other system next. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 19/32] drm/exynos: Use mode_set to configure fimd
On Fri, Nov 15, 2013 at 8:53 AM, Daniel Kurtz wrote:
> Hi Sean, Tomasz,
>
> On Mon, Nov 11, 2013 at 6:03 AM, Tomasz Figa wrote:
>> Hi Sean,
>>
>> On Tuesday 29 of October 2013 12:13:05 Sean Paul wrote:
>>> This patch uses the mode passed into mode_set to configure fimd instead
>>> of directly using the panel from context. This will allow us to move
>>> the exynos_drm_display implementation from fimd into the DP driver
>>> where it belongs.
>>
>> Remember that DP is not the only possible way to connect a display driven
>> by FIMD. You also have the direct (RGB and i80) and DSI interfaces.
>>
>> Also, please see my comments inline.
>>
>>>
>>> Signed-off-by: Sean Paul
>>> ---
>>>
>>> Changes in v2: None
>>> Changes in v3: None
>>>
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 159
>>> ++-
>>> 1 file changed, 91 insertions(+), 68 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index d2b8ccb..f69d6e5 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -104,6 +104,20 @@ struct fimd_win_data {
>>> boolresume;
>>> };
>>>
>>> +struct fimd_mode_data {
>>> + unsignedvtotal;
>>
>> For consistency with rest of the code, unsigned int would prefered.
>>
>> However, I'm not sure what is this struct for, since it does not store
>> neither raw register values (1 needs to be subtracted from them) nor
>> any values hard to compute at commit time (maybe except clkdiv, but still
>> how often commit would be called?).
>>
>>> + unsignedvdisplay;
>>> + unsignedvsync_len;
>>> + unsignedvbpd;
>>> + unsignedvfpd;
>>> + unsignedhtotal;
>>> + unsignedhdisplay;
>>> + unsignedhsync_len;
>>> + unsignedhbpd;
>>> + unsignedhfpd;
>>> + u32 clkdiv;
>>> +};
>>> +
>>> struct fimd_context {
>>> struct device *dev;
>>> struct drm_device *drm_dev;
>>> @@ -112,8 +126,8 @@ struct fimd_context {
>>> struct clk *bus_clk;
>>> struct clk *lcd_clk;
>>> void __iomem*regs;
>>> + struct fimd_mode_data mode;
>>> struct fimd_win_datawin_data[WINDOWS_NR];
>>> - unsigned intclkdiv;
>>> unsigned intdefault_win;
>>> unsigned long irq_flags;
>>> u32 vidcon0;
>>> @@ -560,11 +574,56 @@ static void fimd_dpms(struct exynos_drm_manager *mgr,
>>> int mode)
>>> mutex_unlock(&ctx->lock);
>>> }
>>>
>>> +static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
>>> + const struct drm_display_mode *mode)
>>> +{
>>> + unsigned long ideal_clk = mode->htotal * mode->vtotal *
>>> mode->vrefresh;
>>> + u32 clkdiv;
>>> +
>>> + /* Find the clock divider value that gets us closest to ideal_clk */
>>> + clkdiv = DIV_ROUND_CLOSEST(clk_get_rate(ctx->lcd_clk), ideal_clk);
>>
>> This is a functional change unrelated to $subject. Before this patch,
>> DIV_ROUND_UP() had been used.
>>
>>> +
>>> + return (clkdiv < 0x100) ? clkdiv : 0xff;
>>> +}
>>> +
>>> +static bool fimd_mode_fixup(struct exynos_drm_manager *mgr,
>>> + const struct drm_display_mode *mode,
>>> + struct drm_display_mode *adjusted_mode)
>>> +{
>>> + if (adjusted_mode->vrefresh == 0)
>>> + adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
>
> The actual pixel clock will be clk_get_rate(ctx->lcd_clk) / clkdiv.
> Should we also be adjusting the "clock" field of adjusted_mode here?
>
Seems like we'll need the patchset you just merged in the chromium
tree to fix the mismatch between userspace/kernel (to avoid the
multiple modesets on boot). I don't think it'll make any functional
difference, maybe you can post that as a followup?
>>> +
>>> + return true;
>>> +}
>>> +
>>> +static void fimd_mode_set(struct exynos_drm_manager *mgr,
>>> + const struct drm_display_mode *in_mode)
>>> +{
>>> + struct fimd_context *ctx = mgr->ctx;
>>> + struct fimd_mode_data *mode = &ctx->mode;
>>> + int hblank, vblank;
>>> +
>>> + vblank = in_mode->crtc_vblank_end - in_mode->crtc_vblank_start;
>>> + mode->vtotal = in_mode->crtc_vtotal;
>>> + mode->vdisplay = in_mode->crtc_vdisplay;
>>> + mode->vsync_len = in_mode->crtc_vsync_end - in_mode->crtc_vsync_start;
>>> + mode->vbpd = (vblank - mode->vsync_len) / 2;
>>> + mode->vfpd = vblank - mode->vsync_len - mode->vbpd;
>>> +
>>> + hblank = in_mode->crtc_hblank_end - in_mode->crtc_hblank_start;
>>> + mode->htotal = in_mode->crtc_htotal;
>>> + mode->hdisplay = in_mode->crtc_hdisplay;
>>> +
[Bug 56534] [r600g] cayman msaa/mlaa/fxaa buggy
https://bugs.freedesktop.org/show_bug.cgi?id=56534 --- Comment #9 from Thomas Rohloff --- (In reply to comment #8) > Is this still an issue with mesa from git? There were some recent fixes for > MSAA on cayman. I used fglrx for some time now cause of other bugs, but now I'm on mesa again (10.0). Right now MSAA doesn't seem to do anything at all. I didn't test other anti-aliasing methods for now, but you told to track them in different bugs anyway. Should I still try latest mesa from git? -- 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/20131204/cfdc3205/attachment-0001.html>
[Bug 66241] radeon fails to initialise the monitor
https://bugzilla.kernel.org/show_bug.cgi?id=66241 --- Comment #8 from Chris Rankin --- Created attachment 117511 --> https://bugzilla.kernel.org/attachment.cgi?id=117511&action=edit dmesg output from 3.12.3 + 3rd patch; original system The 3rd patch allows my original system to boot 3.12.3 as well. dmesg output is attached. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
On Sun, Nov 10, 2013 at 8:32 PM, Tomasz Figa wrote: > On Tuesday 29 of October 2013 12:13:07 Sean Paul wrote: >> This patch moves the code from video/ to drm/ > > Again, rationale should be mentioned in patch description. > >> Signed-off-by: Sean Paul >> --- >> >> Changes in v2: None >> Changes in v3: None >> >> drivers/gpu/drm/exynos/Kconfig |7 + >> drivers/gpu/drm/exynos/Makefile |1 + >> drivers/gpu/drm/exynos/exynos_dp_core.c | 1213 >> ++ >> drivers/gpu/drm/exynos/exynos_dp_core.h | 210 ++ >> drivers/gpu/drm/exynos/exynos_dp_reg.c | 1245 >> +++ >> drivers/gpu/drm/exynos/exynos_dp_reg.h | 366 + >> drivers/video/exynos/Kconfig|7 - >> drivers/video/exynos/Makefile |1 - >> drivers/video/exynos/exynos_dp_core.c | 1213 >> -- >> drivers/video/exynos/exynos_dp_core.h | 210 -- >> drivers/video/exynos/exynos_dp_reg.c| 1245 >> --- >> drivers/video/exynos/exynos_dp_reg.h| 366 - >> 12 files changed, 3042 insertions(+), 3042 deletions(-) >> create mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.c >> create mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h >> create mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c >> create mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.h >> delete mode 100644 drivers/video/exynos/exynos_dp_core.c >> delete mode 100644 drivers/video/exynos/exynos_dp_core.h >> delete mode 100644 drivers/video/exynos/exynos_dp_reg.c >> delete mode 100644 drivers/video/exynos/exynos_dp_reg.h >> >> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig >> index 45b6ef5..3ace74f 100644 >> --- a/drivers/gpu/drm/exynos/Kconfig >> +++ b/drivers/gpu/drm/exynos/Kconfig >> @@ -30,6 +30,13 @@ config DRM_EXYNOS_FIMD >> help >> Choose this option if you want to use Exynos FIMD for DRM. >> >> +config DRM_EXYNOS_DP > > I would keep the symbol name as it was, so configs used by people remain > valid. > I don't really want to do that. All of the other configs are named DRM_EXYNOS_BLAH, DP should follow this convention. There are a few ways around this: 1) Make DRM_EXYNOS_DP default to on if DRM_EXYNOS is selected 2) Make a shadow EXYNOS_DP config that selects DRM_EXYNOS_DP Either of those work for you? > Also, don't you need some kind of dependency on DRM_EXYNOS? > Yep, will do. Sean > Otherwise this patch is fine. > > Best regards, > Tomasz >
[Bug 66341] Screen dead
https://bugzilla.kernel.org/show_bug.cgi?id=66341 --- Comment #5 from svily0 at yahoo.com --- Yes, that is the problem, the screen is dead! If I attach a brand new LCD panel it works... but I don't really want to buy a second one now. There isn't any obvious damage on the panel, but today I swapped it with the original one and they both doesn't work. Kernel reports disconnection, but it's a damage or malfunction. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 70687] vgaswitcheroo issues on Linux 3.12
https://bugs.freedesktop.org/show_bug.cgi?id=70687 --- Comment #6 from christian_obst at gmx.de --- It only crashes after disabling the DIS, did you try doing that? Because with me, it still happens in 3.12.2, just as it does in the previous releases. -- 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/20131204/c60bd26c/attachment.html>
[PATCH] drm/radeon: Disable writeback by default on ppc
On Wed, Dec 4, 2013 at 5:16 PM, Kleber Sacilotto de Souza
wrote:
> On 11/25/2013 10:11 PM, Kleber Sacilotto de Souza wrote:
>>
>> On 11/24/2013 09:15 PM, Benjamin Herrenschmidt wrote:
>>>
>>> On Fri, 2013-11-08 at 11:43 -0200, Kleber Sacilotto de Souza wrote:
On 11/07/2013 08:29 PM, Benjamin Herrenschmidt wrote:
>
> On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote:
>
>> Weird. I wonder if there is an issue with cache snoops on PPC. We
>> currently use the gart in cached mode (GPU snoops CPU cache) with
>> cached pages. I wonder if we need to use uncached pages on PPC.
>
> There is no such issue and no known bugs with DMA writes on those
> PCIe host bridges (and they do get hammered pretty bad here).
>
> This needs further investigation by the lab/hw guys to find out what's
> actually happening on the bus and the host bridge.
>
> Thadeu, Kleber: Jerome suggested writing a test case in userspace that
> continuously writes to a spare scratch register (thus triggering the
> corresponding writeback DMA) and checks the memory location to compare
> the writeback value (using a debugfs file for example, or mmap).
>
>
> I was not able to reproduce the issue with this method, even after a weekend
> run.
>
> However, doing some more investigation it seems the problem is here, where
> we read the ring rptr:
>
> u32 radeon_ring_generic_get_rptr(struct radeon_device *rdev,
> struct radeon_ring *ring)
> {
> u32 rptr;
>
> if (rdev->wb.enabled)
> rptr = le32_to_cpu(rdev->wb.wb[ring->rptr_offs/4]);
> else
> rptr = RREG32(ring->rptr_reg);
>
> return rptr;
> }
>
> I realized that the DMA'ed rptr value has always the opposite byte order
> from the MMIO value. Since RREG32 already returns the register value on the
> CPU byte order, it seems we don't need to byte-swap the DMA'ed value. If I
> remove the le32_to_cpu() call and use the DMA'ed value directly, I don't get
> the IB scheduling failures and piglit results are the same as with writeback
> disabled.
>
> Is the adapter chipset swapping the bytes before doing the DMA to a
> big-endian host?
Setting CP_RB_CNTL.BUF_SWAP causes the CP to use the selected byte
swapping for just about everything accessed by the CP (rptr writeback,
indirect buffers, etc.). Looks like the DMA ring supports and enables
rptr writeback as well (DMA_RB_CNTL.DMA_RPTR_WRITEBACK_SWAP_ENABLE) so
I think we can drop the swapping of the rptr writeback.
Alex
>
>
>
> --
> Kleber Sacilotto de Souza
> IBM Linux Technology Center
>
[PATCH] drm/radeon: Disable writeback by default on ppc
On Wed, Dec 4, 2013 at 6:56 PM, Alex Deucher wrote:
> On Wed, Dec 4, 2013 at 5:16 PM, Kleber Sacilotto de Souza
> wrote:
>> On 11/25/2013 10:11 PM, Kleber Sacilotto de Souza wrote:
>>>
>>> On 11/24/2013 09:15 PM, Benjamin Herrenschmidt wrote:
>>>>
>>>> On Fri, 2013-11-08 at 11:43 -0200, Kleber Sacilotto de Souza wrote:
>>>>>
>>>>> On 11/07/2013 08:29 PM, Benjamin Herrenschmidt wrote:
>>>>>>
>>>>>> On Mon, 2013-06-17 at 18:57 -0400, Alex Deucher wrote:
>>>>>>
>>>>>>> Weird. I wonder if there is an issue with cache snoops on PPC. We
>>>>>>> currently use the gart in cached mode (GPU snoops CPU cache) with
>>>>>>> cached pages. I wonder if we need to use uncached pages on PPC.
>>>>>>
>>>>>> There is no such issue and no known bugs with DMA writes on those
>>>>>> PCIe host bridges (and they do get hammered pretty bad here).
>>>>>>
>>>>>> This needs further investigation by the lab/hw guys to find out what's
>>>>>> actually happening on the bus and the host bridge.
>>>>>>
>>>>>> Thadeu, Kleber: Jerome suggested writing a test case in userspace that
>>>>>> continuously writes to a spare scratch register (thus triggering the
>>>>>> corresponding writeback DMA) and checks the memory location to compare
>>>>>> the writeback value (using a debugfs file for example, or mmap).
>>
>>
>> I was not able to reproduce the issue with this method, even after a weekend
>> run.
>>
>> However, doing some more investigation it seems the problem is here, where
>> we read the ring rptr:
>>
>> u32 radeon_ring_generic_get_rptr(struct radeon_device *rdev,
>> struct radeon_ring *ring)
>> {
>> u32 rptr;
>>
>> if (rdev->wb.enabled)
>> rptr = le32_to_cpu(rdev->wb.wb[ring->rptr_offs/4]);
>> else
>> rptr = RREG32(ring->rptr_reg);
>>
>> return rptr;
>> }
>>
>> I realized that the DMA'ed rptr value has always the opposite byte order
>> from the MMIO value. Since RREG32 already returns the register value on the
>> CPU byte order, it seems we don't need to byte-swap the DMA'ed value. If I
>> remove the le32_to_cpu() call and use the DMA'ed value directly, I don't get
>> the IB scheduling failures and piglit results are the same as with writeback
>> disabled.
>>
>> Is the adapter chipset swapping the bytes before doing the DMA to a
>> big-endian host?
>
> Setting CP_RB_CNTL.BUF_SWAP causes the CP to use the selected byte
> swapping for just about everything accessed by the CP (rptr writeback,
> indirect buffers, etc.). Looks like the DMA ring supports and enables
> rptr writeback as well (DMA_RB_CNTL.DMA_RPTR_WRITEBACK_SWAP_ENABLE) so
> I think we can drop the swapping of the rptr writeback.
>
Obvious patch attached.
Alex
> Alex
>
>>
>>
>>
>> --
>> Kleber Sacilotto de Souza
>> IBM Linux Technology Center
>>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-don-t-byteswap-readback-of-rptr-writeback.patch
Type: text/x-diff
Size: 994 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131204/a92e67e4/attachment-0001.patch>
[PATCH] drm: don't double-free on driver load error
All instances of drm_dev_register are followed by drm_dev_free on
failure. Don't free dev->control/render/primary on failure, as they will
be freed by drm_dev_free since commit 8f6599da8e (drm: delay minor
destruction to drm_dev_free()).
Reported-by: Bruno Pr?mont
Signed-off-by: Ilia Mirkin
---
Bruno, would be nice if you could test this out on your setup without
the patch that makes load succeed. Ideally this will make drm not die
in the case that nouveau load fails.
drivers/gpu/drm/drm_stub.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index f53d524..cd427b8 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -536,17 +536,17 @@ int drm_dev_register(struct drm_device *dev, unsigned
long flags)
if (drm_core_check_feature(dev, DRIVER_RENDER) && drm_rnodes) {
ret = drm_get_minor(dev, &dev->render, DRM_MINOR_RENDER);
if (ret)
- goto err_control_node;
+ goto err_agp;
}
ret = drm_get_minor(dev, &dev->primary, DRM_MINOR_LEGACY);
if (ret)
- goto err_render_node;
+ goto err_agp;
if (dev->driver->load) {
ret = dev->driver->load(dev, flags);
if (ret)
- goto err_primary_node;
+ goto err_agp;
}
/* setup grouping for legacy outputs */
@@ -565,12 +565,6 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
err_unload:
if (dev->driver->unload)
dev->driver->unload(dev);
-err_primary_node:
- drm_put_minor(dev->primary);
-err_render_node:
- drm_put_minor(dev->render);
-err_control_node:
- drm_put_minor(dev->control);
err_agp:
if (dev->driver->bus->agp_destroy)
dev->driver->bus->agp_destroy(dev);
--
1.8.3.2
[i915] BUG: Bad page state in process Xorg
Am Samstag, den 30.11.2013, 08:55 -0500 schrieb Rob Clark:
> On Sat, Nov 30, 2013 at 3:33 AM, Thomas Meyer wrote:
> > Am Montag, den 25.11.2013, 08:23 -0500 schrieb Rob Clark:
> >> oh, hmm.. are you importing buffers from i915? It looks like this part:
> >
> > My computer has an i915 graphic card and I use an USB docking station,
> > that has an unconnected UDL device inside.
> >
> >>
> >> - if (obj->base.import_attach) {
> >> - drm_free_large(obj->pages);
> >> - obj->pages = NULL;
> >> - return;
> >> - }
> >>
> >> should not have been removed from udl_gem_put_pages()..
> >
> > Do you want me to test this? Can this please be fixed in the stable
> > tree?
> > I removed the UDL driver from my config for now, as I don't use it.
>
> It would be nice if you could test that (I can send you a patch if you
> prefer).. I don't actually have any UDL device to confirm. If this
> fixes the problem, send the patch to stable as well should not be a
> problem.
I did a quick test and above code makes the bad page bug disappear.
>
> BR,
> -R
>
>
> > *
> > best regards
> > thomas
> >
> >>
> >> BR,
> >> -R
> >>
> >> On Mon, Nov 25, 2013 at 8:17 AM, wrote:
> >> > Hi,
> >> >
> >> > It turns out that this seems to be a bug in udl DRM driver.
> >> >
> >> > I bisected the problem to this patch:
> >> >
> >> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/udl?id=5dc9e1e87229cb786a5bb58ddd0d60fee6eb4641
> >> >
> >> > With kind regards
> >> > Thomas
> >> >
> >> > Am 22.11.2013 17:18 schrieb Daniel Vetter :
> >> >>
> >> >> On Fri, Nov 22, 2013 at 4:54 PM, Thomas Meyer
> >> >> wrote:
> >> >> >> Am 22.11.2013 um 11:55 schrieb Daniel Vetter :
> >> >> >>
> >> >> >> On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie
> >> >> >> wrote:
> >> >> Hi,
> >> >> >>>
> >> >> >>> cc'ing mailing list,
> >> >> >>>
> >> >> >>> Daniel any ideas?
> >> >> >>
> >> >> >> Nope, not really :( And no ideas how to triage this further - if it
> >> >> >> takes 9 days to hit it eventually we'll have a real hard time. Or
> >> >> >> does
> >> >> >> this happen even after just a short X run?
> >> >> >
> >> >> > Seems to happen every time while stopping the x server. Also after a
> >> >> > short run time.
> >> >> >
> >> >> > The current fedora 3.11 kernel doesn't show this bug. I'm using
> >> >> > fedora 19, with a self compiled kernel.
> >> >> >
> >> >> > I did turn on config-debug-pagealloc but this didn't show any
> >> >> > wrongness.
> >> >>
> >> >> In that case I think the bisect is the fastest way to insight - atm
> >> >> I'm really at loss what could be wrong here.
> >> >> -Daniel
> >> >> --
> >> >> Daniel Vetter
> >> >> Software Engineer, Intel Corporation
> >> >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >
> >
> >
[pull] radeon fixes 3.13
Hi Dave, Some additional fixes for 3.13. Regression fixes for audio and hw_i2c, vram fix for some SI PX cards, race fix in the hwmon code, and a few other odds and ends. The following changes since commit 1b28c3e628315ac0d9ef2d3fac0403f05ae692db: drm/qxl: fix memory leak in release list handling (2013-11-29 08:36:15 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.13 for you to fetch changes up to ffd3d3361d583cb73fa65a5fed3a196ba6f261bb: drm/radeon/atom: fix bus probes when hw_i2c is set (v2) (2013-12-04 19:56:46 -0500) Alex Deucher (6): drm/radeon: fix typo in fetching mpll params drm/radeon: program DCE2 audio dto just like DCE3 drm/radeon/dpm: simplify state adjust logic for NI drm/radeon: fixup bad vram size on SI drm/radeon: fix null pointer dereference in dce6+ audio code drm/radeon/atom: fix bus probes when hw_i2c is set (v2) Alexandre Demers (1): drm/radeon: Fix a typo in Cayman and Evergreen registers Christian K?nig (2): drm/radeon: add VMID allocation trace point drm/radeon: add radeon_vm_bo_update trace point Dave Airlie (1): drm/radeon: fix VGT_GS_INSTANCE_CNT register Guenter Roeck (1): drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups drivers/gpu/drm/radeon/atombios_i2c.c | 15 ++ drivers/gpu/drm/radeon/dce6_afmt.c| 12 drivers/gpu/drm/radeon/ni_dpm.c | 28 +++--- drivers/gpu/drm/radeon/r600_hdmi.c| 8 ++--- drivers/gpu/drm/radeon/radeon.h | 8 ++--- drivers/gpu/drm/radeon/radeon_atombios.c | 2 +- drivers/gpu/drm/radeon/radeon_cs.c| 4 +-- drivers/gpu/drm/radeon/radeon_drv.h | 3 +- drivers/gpu/drm/radeon/radeon_gart.c | 16 ++ drivers/gpu/drm/radeon/radeon_pm.c| 49 --- drivers/gpu/drm/radeon/radeon_trace.h | 33 + drivers/gpu/drm/radeon/reg_srcs/cayman| 4 +-- drivers/gpu/drm/radeon/reg_srcs/evergreen | 4 +-- drivers/gpu/drm/radeon/si.c | 11 +-- 14 files changed, 106 insertions(+), 91 deletions(-)
