[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #12 from Alexandre Demers 2012-08-19 22:22:24 UTC --- I tried to trace RenderFeatTest (one of the other applications locking my system). It did as with the piglit test: it didn't crash. However, the rendering is corrupted where it locks when launched from a terminal. Trace is 75MB when compressed if you want me to upload it somewhere. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On 08/17/12 15:55, Dave Airlie wrote: > On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: >> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap >> wrote: >>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote: >>> for , we have verified cases on inteldrmfb, radeondrmfb, and cirrusdrmfb. This is the last message displayed before the system hangs. This seems to be hitting a large number of users in Fedora, though certainly not everyone. This started happening with the 3.5 updates, and is still an issue. It appears to be a race condition, because various things have allowed boot to continue for some users, though there is no clear work around. Has anyone else run across this? Any ideas. For more background we have the following bugs: inteldrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=843826 radeondrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=845745 cirrusdrmfb : https://bugzilla.redhat.com/show_bug.cgi?id=843860 It should be noted that the conflicting fb hw usage message is not new, it has been around for a while, but this is the last message seen before the hang. >>> >>> >>> Hi, (adding dri-devel mailing list) >>> >>> >>> I started seeing this problem on 3.5-rc6. >>> >>> AFAICT, the system is not actually hung, it's just that no output >>> is showing up on the real (physical) output device (display) -- it's >>> going somewhere else (or to the bit bucket). >>> >> >> Can we bisect this at all? I guess I'll have to try again. My first attempt did not prove anything, I think because the conflict does not happen 100% of the time (i.e., it feels like a timing problem). >> I worry the intel one will bisect to where we moved the conflict >> resolution earlier, but I'd like to see if applying that patch earlier >> causes the issue, since radeon has it. Do you know of a specific commit that I could revert and test? >> I haven't reproduced this on any hw I own, I also can't get it under qemu. > > I'm also wondering whether this grub2 related in some way, grub2 is > starting to mess with the graphics adapter pointlessly. > > Dave. -- ~Randy
[PATCH] nouveau: avoid excessive gart aperture for on-board cards
Commit d0f3c7e41d30859a638083654002b9b6faf7f67b ("drm/nouveau: give a
slightly larger pci(e)gart aperture on all chipsets") removed a test:
that caused an 8x increase in gart aperture, instead of a 2x one, for
on-board cards >= NV_40.
Signed-off-by: Michele Ballabio
---
Hi,
in Linux 3.5.x I experienced some crashes of the X server, and
noticed from the boot that while the gart aperture in 3.4.x was 64MB,
in 3.5.x became 512MB. So I came out with this quick patch: this seems
to work, since X did not crash anymore (and I tried quite hard to),
but I'm not sure if it is the right fix.
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 2 +-
1 file modificato, 1 inserzione(+). 1 rimozione(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 38483a0..ebc27f7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -341,7 +341,7 @@ nouveau_sgdma_init(struct drm_device *dev)
u32 aper_size, align;
int ret;
- if (dev_priv->card_type >= NV_40)
+ if (dev_priv->card_type >= NV_40 && pci_is_pcie(dev->pdev))
aper_size = 512 * 1024 * 1024;
else
aper_size = 128 * 1024 * 1024;
--
1.7.11.1
[PATCH] drm/radeon: fix checking of MSAA renderbuffers on r600-r700
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/r600_cs.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 1bec5b8..ab74e6b 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -420,7 +420,8 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
}
/* check offset */
- tmp = r600_fmt_get_nblocksy(format, height) *
r600_fmt_get_nblocksx(format, pitch) * r600_fmt_get_blocksize(format);
+ tmp = r600_fmt_get_nblocksy(format, height) *
r600_fmt_get_nblocksx(format, pitch) *
+ r600_fmt_get_blocksize(format) * track->nsamples;
switch (array_mode) {
default:
case V_0280A0_ARRAY_LINEAR_GENERAL:
@@ -611,7 +612,7 @@ static int r600_cs_track_validate_db(struct
radeon_cs_parser *p)
ntiles = G_028000_SLICE_TILE_MAX(track->db_depth_size) + 1;
nviews = G_028004_SLICE_MAX(track->db_depth_view) + 1;
- tmp = ntiles * bpe * 64 * nviews;
+ tmp = ntiles * bpe * 64 * nviews * track->nsamples;
if ((tmp + track->db_offset) > radeon_bo_size(track->db_bo)) {
dev_warn(p->dev, "z/stencil buffer (%d) too small
(0x%08X %d %d %d -> %u have %lu)\n",
array_mode,
@@ -1562,7 +1563,7 @@ unsigned r600_mip_minify(unsigned size, unsigned level)
}
static void r600_texture_size(unsigned nfaces, unsigned blevel, unsigned
llevel,
- unsigned w0, unsigned h0, unsigned d0, unsigned
format,
+ unsigned w0, unsigned h0, unsigned d0, unsigned
nsamples, unsigned format,
unsigned block_align, unsigned height_align,
unsigned base_align,
unsigned *l0_size, unsigned *mipmap_size)
{
@@ -1590,7 +1591,7 @@ static void r600_texture_size(unsigned nfaces, unsigned
blevel, unsigned llevel,
depth = r600_mip_minify(d0, i);
- size = nbx * nby * blocksize;
+ size = nbx * nby * blocksize * nsamples;
if (nfaces)
size *= nfaces;
else
@@ -1742,7 +1743,7 @@ static int r600_check_texture_resource(struct
radeon_cs_parser *p, u32 idx,
nfaces = larray - barray + 1;
}
- r600_texture_size(nfaces, blevel, llevel, w0, h0, d0, format,
+ r600_texture_size(nfaces, blevel, llevel, w0, h0, d0,
array_check.nsamples, format,
pitch_align, height_align, base_align,
_size, _size);
/* using get ib will give us the offset into the texture bo */
--
1.7.9.5
[Bug 44800] Radeon HD 6450 CAICOS screen corruption and kernel crashes
https://bugs.freedesktop.org/show_bug.cgi?id=44800 --- Comment #13 from Marko Kohtala 2012-08-19 18:09:19 UTC --- I applied "drm/radeon: cleanup and fix crtc while programming mc" and "drm/radeon: fence virtual address and free it once idle [3.5] v2" on top of 3.5.2. Did not change this. I saw the usual corruption in the fb console as well as in the xinit running only xterm. This time I run 64-bit kernel under my 32-bit userspace. I had problems getting the 32-bit kernel to boot on my EFI. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] r600g: fix allocation of MSAA surfaces on r600-r700
--- radeon/radeon_surface.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 892dca6..98f4aaf 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -165,7 +165,7 @@ static void surf_minify(struct radeon_surface *surf, surf->level[level].nblk_z = ALIGN(surf->level[level].nblk_z, zalign); surf->level[level].offset = offset; -surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe; +surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe * surf->nsamples; surf->level[level].slice_size = surf->level[level].pitch_bytes * surf->level[level].nblk_y; surf->bo_size = offset + surf->level[level].slice_size * surf->level[level].nblk_z * surf->array_size; -- 1.7.9.5
[PATCH] drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700
On Sat, Aug 18, 2012 at 8:22 PM, Marek Ol??k wrote:
> MSAA is impossible without them.
Reviewed-by: Jerome Glisse
> Signed-off-by: Marek Ol??k
> ---
> drivers/gpu/drm/radeon/r600_cs.c | 94
> +-
> drivers/gpu/drm/radeon/r600d.h | 17 ++
> drivers/gpu/drm/radeon/radeon_drv.c |3 +-
> drivers/gpu/drm/radeon/reg_srcs/r600 |8 ---
> 4 files changed, 101 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c
> b/drivers/gpu/drm/radeon/r600_cs.c
> index 3dab49c..1bec5b8 100644
> --- a/drivers/gpu/drm/radeon/r600_cs.c
> +++ b/drivers/gpu/drm/radeon/r600_cs.c
> @@ -47,13 +47,17 @@ struct r600_cs_track {
> u32 npipes;
> /* value we track */
> u32 sq_config;
> + u32 log_nsamples;
> u32 nsamples;
> u32 cb_color_base_last[8];
> struct radeon_bo*cb_color_bo[8];
> u64 cb_color_bo_mc[8];
> - u32 cb_color_bo_offset[8];
> - struct radeon_bo*cb_color_frag_bo[8]; /* unused */
> - struct radeon_bo*cb_color_tile_bo[8]; /* unused */
> + u64 cb_color_bo_offset[8];
> + struct radeon_bo*cb_color_frag_bo[8];
> + u64 cb_color_frag_offset[8];
> + struct radeon_bo*cb_color_tile_bo[8];
> + u64 cb_color_tile_offset[8];
> + u32 cb_color_mask[8];
> u32 cb_color_info[8];
> u32 cb_color_view[8];
> u32 cb_color_size_idx[8]; /* unused */
> @@ -349,10 +353,6 @@ static int r600_cs_track_validate_cb(struct
> radeon_cs_parser *p, int i)
> unsigned array_mode;
> u32 format;
>
> - if (G_0280A0_TILE_MODE(track->cb_color_info[i])) {
> - dev_warn(p->dev, "FMASK or CMASK buffer are not supported by
> this kernel\n");
> - return -EINVAL;
> - }
> size = radeon_bo_size(track->cb_color_bo[i]) -
> track->cb_color_bo_offset[i];
> format = G_0280A0_FORMAT(track->cb_color_info[i]);
> if (!r600_fmt_is_valid_color(format)) {
> @@ -441,7 +441,7 @@ static int r600_cs_track_validate_cb(struct
> radeon_cs_parser *p, int i)
> * broken userspace.
> */
> } else {
> - dev_warn(p->dev, "%s offset[%d] %d %d %d %lu too big
> (%d %d) (%d %d %d)\n",
> + dev_warn(p->dev, "%s offset[%d] %d %llu %d %lu too
> big (%d %d) (%d %d %d)\n",
> __func__, i, array_mode,
> track->cb_color_bo_offset[i], tmp,
> radeon_bo_size(track->cb_color_bo[i]),
> @@ -458,6 +458,51 @@ static int r600_cs_track_validate_cb(struct
> radeon_cs_parser *p, int i)
> tmp = S_028060_PITCH_TILE_MAX((pitch / 8) - 1) |
> S_028060_SLICE_TILE_MAX(slice_tile_max - 1);
> ib[track->cb_color_size_idx[i]] = tmp;
> +
> + /* FMASK/CMASK */
> + switch (G_0280A0_TILE_MODE(track->cb_color_info[i])) {
> + case V_0280A0_TILE_DISABLE:
> + break;
> + case V_0280A0_FRAG_ENABLE:
> + if (track->nsamples > 1) {
> + uint32_t tile_max =
> G_028100_FMASK_TILE_MAX(track->cb_color_mask[i]);
> + /* the tile size is 8x8, but the size is in units of
> bits.
> +* for bytes, do just * 8. */
> + uint32_t bytes = track->nsamples *
> track->log_nsamples * 8 * (tile_max + 1);
> +
> + if (bytes + track->cb_color_frag_offset[i] >
> + radeon_bo_size(track->cb_color_frag_bo[i])) {
> + dev_warn(p->dev, "%s FMASK_TILE_MAX too large
> "
> +"(tile_max=%u, bytes=%u,
> offset=%llu, bo_size=%lu)\n",
> +__func__, tile_max, bytes,
> +track->cb_color_frag_offset[i],
> +
> radeon_bo_size(track->cb_color_frag_bo[i]));
> + return -EINVAL;
> + }
> + }
> + /* fall through */
> + case V_0280A0_CLEAR_ENABLE:
> + {
> + uint32_t block_max =
> G_028100_CMASK_BLOCK_MAX(track->cb_color_mask[i]);
> + /* One block = 128x128 pixels, one 8x8 tile has 4 bits..
> +* (128*128) / (8*8) / 2 = 128 bytes per block. */
> + uint32_t bytes = (block_max + 1) * 128;
> +
> + if (bytes + track->cb_color_tile_offset[i] >
> + radeon_bo_size(track->cb_color_tile_bo[i])) {
[PATCH] r600g: fix allocation of MSAA surfaces on r600-r700
On Sun, Aug 19, 2012 at 9:25 AM, Marek Ol??k wrote: Reviewed-by: Jerome Glisse > --- > radeon/radeon_surface.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c > index 892dca6..98f4aaf 100644 > --- a/radeon/radeon_surface.c > +++ b/radeon/radeon_surface.c > @@ -165,7 +165,7 @@ static void surf_minify(struct radeon_surface *surf, > surf->level[level].nblk_z = ALIGN(surf->level[level].nblk_z, zalign); > > surf->level[level].offset = offset; > -surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe; > +surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe * > surf->nsamples; > surf->level[level].slice_size = surf->level[level].pitch_bytes * > surf->level[level].nblk_y; > > surf->bo_size = offset + surf->level[level].slice_size * > surf->level[level].nblk_z * surf->array_size; > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 --- Comment #6 from ojab 2012-08-19 11:28:23 UTC --- It also happens with default xorg.conf (without "ColorTiling2D" and "AccelDFS"). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 --- Comment #5 from ojab 2012-08-19 11:15:46 UTC --- Created attachment 65773 --> https://bugs.freedesktop.org/attachment.cgi?id=65773 Kernel log, second panic -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 ojab changed: What|Removed |Added Attachment #65771|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 --- Comment #4 from ojab 2012-08-19 11:15:03 UTC --- Created attachment 65772 --> https://bugs.freedesktop.org/attachment.cgi?id=65772 glxinfo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 --- Comment #3 from ojab 2012-08-19 11:13:50 UTC --- Created attachment 65771 --> https://bugs.freedesktop.org/attachment.cgi?id=65771 Xorg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 --- Comment #2 from ojab 2012-08-19 11:13:09 UTC --- Created attachment 65770 --> https://bugs.freedesktop.org/attachment.cgi?id=65770 Karnel panic #2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 ojab changed: What|Removed |Added Attachment #65768|0 |1 is obsolete|| --- Comment #1 from ojab 2012-08-19 11:12:42 UTC --- Created attachment 65769 --> https://bugs.freedesktop.org/attachment.cgi?id=65769 Kernel panic #1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53707] New: [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 Bug #: 53707 Summary: [RS780] Kernel panick after opening 6K?6K image in firefox Classification: Unclassified Product: DRI Version: DRI CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: ojab at ojab.ru Created attachment 65768 --> https://bugs.freedesktop.org/attachment.cgi?id=65768 Kernel panic #1 I've got kernel panic two times in a row after opening http://apod.nasa.gov/apod/image/1207/orion_hubble_6000.jpg in firefox on vanilla kernel-3.5.2 with libdrm/mesa/xf86-video-ati from latest git. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 52256] Trinity (ARUBA) DP link training problems
https://bugs.freedesktop.org/show_bug.cgi?id=52256 --- Comment #7 from Christian K?nig 2012-08-19 10:25:18 UTC --- I also have DP link problems on the trinity testing board I have. Always thought that this is just a problem because it is a beta or even alpha board, but that doesn't seems to be the case. @Alex: So I can test any patches/ideas you've got. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 52256] Trinity (ARUBA) DP link training problems
https://bugs.freedesktop.org/show_bug.cgi?id=52256 --- Comment #6 from LRN 2012-08-19 10:19:17 UTC --- http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=f59abbf28696389c91c2697c7db31f20cfa91d8a doesn't work either. Are you sure there are no patches that i could try? I've tried to look up the ones on #27314 , but they are against an old kernel version, and some of them were (apparently) applied in some manner. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 46181] No Brightness control-nouveau
https://bugzilla.kernel.org/show_bug.cgi?id=46181 --- Comment #1 from Lakshminarayanan 2012-08-19 05:34:14 --- PS: This problem ahs been there for the past year atleast and i have tried all kernels from 2.35 to 3.5. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46181] New: No Brightness control-nouveau
https://bugzilla.kernel.org/show_bug.cgi?id=46181 Summary: No Brightness control-nouveau Product: Drivers Version: 2.5 Kernel Version: 3.4.9-1-ARCH Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: jujojujo_2003 at yahoo.co.in Regression: No I completely have no brightness control on my laptop(M17 r3 3D verison). dmesg log is spammed with the following message every few seconds , [ 589.813022] Raw EDID: [ 589.813032] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813037] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813041] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813045] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813050] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813054] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813058] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813062] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.815666] Raw EDID: [ 589.815669] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815673] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815677] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815682] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815686] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815690] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815695] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815699] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.818304] Raw EDID: [ 589.818308] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818312] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818316] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818321] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818325] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818329] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818333] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818337] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.820946] Raw EDID: [ 589.820949] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820953] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820958] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820962] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820966] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820970] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820975] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820979] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.820987] nouveau :01:00.0: eDP-1: Ignoring invalid EDID block 1. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700
MSAA is impossible without them.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/r600_cs.c | 94 +-
drivers/gpu/drm/radeon/r600d.h | 17 ++
drivers/gpu/drm/radeon/radeon_drv.c |3 +-
drivers/gpu/drm/radeon/reg_srcs/r600 |8 ---
4 files changed, 101 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 3dab49c..1bec5b8 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -47,13 +47,17 @@ struct r600_cs_track {
u32 npipes;
/* value we track */
u32 sq_config;
+ u32 log_nsamples;
u32 nsamples;
u32 cb_color_base_last[8];
struct radeon_bo*cb_color_bo[8];
u64 cb_color_bo_mc[8];
- u32 cb_color_bo_offset[8];
- struct radeon_bo*cb_color_frag_bo[8]; /* unused */
- struct radeon_bo*cb_color_tile_bo[8]; /* unused */
+ u64 cb_color_bo_offset[8];
+ struct radeon_bo*cb_color_frag_bo[8];
+ u64 cb_color_frag_offset[8];
+ struct radeon_bo*cb_color_tile_bo[8];
+ u64 cb_color_tile_offset[8];
+ u32 cb_color_mask[8];
u32 cb_color_info[8];
u32 cb_color_view[8];
u32 cb_color_size_idx[8]; /* unused */
@@ -349,10 +353,6 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
unsigned array_mode;
u32 format;
- if (G_0280A0_TILE_MODE(track->cb_color_info[i])) {
- dev_warn(p->dev, "FMASK or CMASK buffer are not supported by
this kernel\n");
- return -EINVAL;
- }
size = radeon_bo_size(track->cb_color_bo[i]) -
track->cb_color_bo_offset[i];
format = G_0280A0_FORMAT(track->cb_color_info[i]);
if (!r600_fmt_is_valid_color(format)) {
@@ -441,7 +441,7 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
* broken userspace.
*/
} else {
- dev_warn(p->dev, "%s offset[%d] %d %d %d %lu too big
(%d %d) (%d %d %d)\n",
+ dev_warn(p->dev, "%s offset[%d] %d %llu %d %lu too big
(%d %d) (%d %d %d)\n",
__func__, i, array_mode,
track->cb_color_bo_offset[i], tmp,
radeon_bo_size(track->cb_color_bo[i]),
@@ -458,6 +458,51 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
tmp = S_028060_PITCH_TILE_MAX((pitch / 8) - 1) |
S_028060_SLICE_TILE_MAX(slice_tile_max - 1);
ib[track->cb_color_size_idx[i]] = tmp;
+
+ /* FMASK/CMASK */
+ switch (G_0280A0_TILE_MODE(track->cb_color_info[i])) {
+ case V_0280A0_TILE_DISABLE:
+ break;
+ case V_0280A0_FRAG_ENABLE:
+ if (track->nsamples > 1) {
+ uint32_t tile_max =
G_028100_FMASK_TILE_MAX(track->cb_color_mask[i]);
+ /* the tile size is 8x8, but the size is in units of
bits.
+* for bytes, do just * 8. */
+ uint32_t bytes = track->nsamples * track->log_nsamples
* 8 * (tile_max + 1);
+
+ if (bytes + track->cb_color_frag_offset[i] >
+ radeon_bo_size(track->cb_color_frag_bo[i])) {
+ dev_warn(p->dev, "%s FMASK_TILE_MAX too large "
+"(tile_max=%u, bytes=%u, offset=%llu,
bo_size=%lu)\n",
+__func__, tile_max, bytes,
+track->cb_color_frag_offset[i],
+
radeon_bo_size(track->cb_color_frag_bo[i]));
+ return -EINVAL;
+ }
+ }
+ /* fall through */
+ case V_0280A0_CLEAR_ENABLE:
+ {
+ uint32_t block_max =
G_028100_CMASK_BLOCK_MAX(track->cb_color_mask[i]);
+ /* One block = 128x128 pixels, one 8x8 tile has 4 bits..
+* (128*128) / (8*8) / 2 = 128 bytes per block. */
+ uint32_t bytes = (block_max + 1) * 128;
+
+ if (bytes + track->cb_color_tile_offset[i] >
+ radeon_bo_size(track->cb_color_tile_bo[i])) {
+ dev_warn(p->dev, "%s CMASK_BLOCK_MAX too large "
+"(block_max=%u, bytes=%u, offset=%llu,
bo_size=%lu)\n",
+__func__, block_max, bytes,
+track->cb_color_tile_offset[i],
+
[Bug 46181] New: No Brightness control-nouveau
https://bugzilla.kernel.org/show_bug.cgi?id=46181 Summary: No Brightness control-nouveau Product: Drivers Version: 2.5 Kernel Version: 3.4.9-1-ARCH Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: jujojujo_2...@yahoo.co.in Regression: No I completely have no brightness control on my laptop(M17 r3 3D verison). dmesg log is spammed with the following message every few seconds , [ 589.813022] Raw EDID: [ 589.813032] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813037] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813041] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813045] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813050] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813054] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813058] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813062] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.815666] Raw EDID: [ 589.815669] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815673] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815677] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815682] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815686] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815690] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815695] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815699] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.818304] Raw EDID: [ 589.818308] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818312] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818316] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818321] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818325] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818329] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818333] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818337] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.820946] Raw EDID: [ 589.820949] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820953] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820958] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820962] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820966] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820970] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820975] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820979] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.820987] nouveau :01:00.0: eDP-1: Ignoring invalid EDID block 1. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46181] No Brightness control-nouveau
https://bugzilla.kernel.org/show_bug.cgi?id=46181 --- Comment #1 from Lakshminarayanan jujojujo_2...@yahoo.co.in 2012-08-19 05:34:14 --- PS: This problem ahs been there for the past year atleast and i have tried all kernels from 2.35 to 3.5. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52256] Trinity (ARUBA) DP link training problems
https://bugs.freedesktop.org/show_bug.cgi?id=52256 --- Comment #6 from LRN lrn1...@gmail.com 2012-08-19 10:19:17 UTC --- http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=f59abbf28696389c91c2697c7db31f20cfa91d8a doesn't work either. Are you sure there are no patches that i could try? I've tried to look up the ones on #27314 , but they are against an old kernel version, and some of them were (apparently) applied in some manner. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52256] Trinity (ARUBA) DP link training problems
https://bugs.freedesktop.org/show_bug.cgi?id=52256 --- Comment #7 from Christian König deathsim...@vodafone.de 2012-08-19 10:25:18 UTC --- I also have DP link problems on the trinity testing board I have. Always thought that this is just a problem because it is a beta or even alpha board, but that doesn't seems to be the case. @Alex: So I can test any patches/ideas you've got. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53707] New: [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 Bug #: 53707 Summary: [RS780] Kernel panick after opening 6K×6K image in firefox Classification: Unclassified Product: DRI Version: DRI CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: o...@ojab.ru Created attachment 65768 -- https://bugs.freedesktop.org/attachment.cgi?id=65768 Kernel panic #1 I've got kernel panic two times in a row after opening http://apod.nasa.gov/apod/image/1207/orion_hubble_6000.jpg in firefox on vanilla kernel-3.5.2 with libdrm/mesa/xf86-video-ati from latest git. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 ojab o...@ojab.ru changed: What|Removed |Added Attachment #65768|0 |1 is obsolete|| --- Comment #1 from ojab o...@ojab.ru 2012-08-19 11:12:42 UTC --- Created attachment 65769 -- https://bugs.freedesktop.org/attachment.cgi?id=65769 Kernel panic #1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 --- Comment #2 from ojab o...@ojab.ru 2012-08-19 11:13:09 UTC --- Created attachment 65770 -- https://bugs.freedesktop.org/attachment.cgi?id=65770 Karnel panic #2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 --- Comment #3 from ojab o...@ojab.ru 2012-08-19 11:13:50 UTC --- Created attachment 65771 -- https://bugs.freedesktop.org/attachment.cgi?id=65771 Xorg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 --- Comment #4 from ojab o...@ojab.ru 2012-08-19 11:15:03 UTC --- Created attachment 65772 -- https://bugs.freedesktop.org/attachment.cgi?id=65772 glxinfo -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 ojab o...@ojab.ru changed: What|Removed |Added Attachment #65771|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 --- Comment #5 from ojab o...@ojab.ru 2012-08-19 11:15:46 UTC --- Created attachment 65773 -- https://bugs.freedesktop.org/attachment.cgi?id=65773 Kernel log, second panic -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53707] [RS780] Kernel panick after opening 6K×6K image in firefox
https://bugs.freedesktop.org/show_bug.cgi?id=53707 --- Comment #6 from ojab o...@ojab.ru 2012-08-19 11:28:23 UTC --- It also happens with default xorg.conf (without ColorTiling2D and AccelDFS). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] r600g: fix allocation of MSAA surfaces on r600-r700
--- radeon/radeon_surface.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 892dca6..98f4aaf 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -165,7 +165,7 @@ static void surf_minify(struct radeon_surface *surf, surf-level[level].nblk_z = ALIGN(surf-level[level].nblk_z, zalign); surf-level[level].offset = offset; -surf-level[level].pitch_bytes = surf-level[level].nblk_x * surf-bpe; +surf-level[level].pitch_bytes = surf-level[level].nblk_x * surf-bpe * surf-nsamples; surf-level[level].slice_size = surf-level[level].pitch_bytes * surf-level[level].nblk_y; surf-bo_size = offset + surf-level[level].slice_size * surf-level[level].nblk_z * surf-array_size; -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] r600g: fix allocation of MSAA surfaces on r600-r700
On Sun, Aug 19, 2012 at 9:25 AM, Marek Olšák mar...@gmail.com wrote: Reviewed-by: Jerome Glisse jgli...@redhat.com --- radeon/radeon_surface.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 892dca6..98f4aaf 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -165,7 +165,7 @@ static void surf_minify(struct radeon_surface *surf, surf-level[level].nblk_z = ALIGN(surf-level[level].nblk_z, zalign); surf-level[level].offset = offset; -surf-level[level].pitch_bytes = surf-level[level].nblk_x * surf-bpe; +surf-level[level].pitch_bytes = surf-level[level].nblk_x * surf-bpe * surf-nsamples; surf-level[level].slice_size = surf-level[level].pitch_bytes * surf-level[level].nblk_y; surf-bo_size = offset + surf-level[level].slice_size * surf-level[level].nblk_z * surf-array_size; -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700
On Sat, Aug 18, 2012 at 8:22 PM, Marek Olšák mar...@gmail.com wrote:
MSAA is impossible without them.
Reviewed-by: Jerome Glisse jgli...@redhat.com
Signed-off-by: Marek Olšák mar...@gmail.com
---
drivers/gpu/drm/radeon/r600_cs.c | 94
+-
drivers/gpu/drm/radeon/r600d.h | 17 ++
drivers/gpu/drm/radeon/radeon_drv.c |3 +-
drivers/gpu/drm/radeon/reg_srcs/r600 |8 ---
4 files changed, 101 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c
b/drivers/gpu/drm/radeon/r600_cs.c
index 3dab49c..1bec5b8 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -47,13 +47,17 @@ struct r600_cs_track {
u32 npipes;
/* value we track */
u32 sq_config;
+ u32 log_nsamples;
u32 nsamples;
u32 cb_color_base_last[8];
struct radeon_bo*cb_color_bo[8];
u64 cb_color_bo_mc[8];
- u32 cb_color_bo_offset[8];
- struct radeon_bo*cb_color_frag_bo[8]; /* unused */
- struct radeon_bo*cb_color_tile_bo[8]; /* unused */
+ u64 cb_color_bo_offset[8];
+ struct radeon_bo*cb_color_frag_bo[8];
+ u64 cb_color_frag_offset[8];
+ struct radeon_bo*cb_color_tile_bo[8];
+ u64 cb_color_tile_offset[8];
+ u32 cb_color_mask[8];
u32 cb_color_info[8];
u32 cb_color_view[8];
u32 cb_color_size_idx[8]; /* unused */
@@ -349,10 +353,6 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
unsigned array_mode;
u32 format;
- if (G_0280A0_TILE_MODE(track-cb_color_info[i])) {
- dev_warn(p-dev, FMASK or CMASK buffer are not supported by
this kernel\n);
- return -EINVAL;
- }
size = radeon_bo_size(track-cb_color_bo[i]) -
track-cb_color_bo_offset[i];
format = G_0280A0_FORMAT(track-cb_color_info[i]);
if (!r600_fmt_is_valid_color(format)) {
@@ -441,7 +441,7 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
* broken userspace.
*/
} else {
- dev_warn(p-dev, %s offset[%d] %d %d %d %lu too big
(%d %d) (%d %d %d)\n,
+ dev_warn(p-dev, %s offset[%d] %d %llu %d %lu too
big (%d %d) (%d %d %d)\n,
__func__, i, array_mode,
track-cb_color_bo_offset[i], tmp,
radeon_bo_size(track-cb_color_bo[i]),
@@ -458,6 +458,51 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
tmp = S_028060_PITCH_TILE_MAX((pitch / 8) - 1) |
S_028060_SLICE_TILE_MAX(slice_tile_max - 1);
ib[track-cb_color_size_idx[i]] = tmp;
+
+ /* FMASK/CMASK */
+ switch (G_0280A0_TILE_MODE(track-cb_color_info[i])) {
+ case V_0280A0_TILE_DISABLE:
+ break;
+ case V_0280A0_FRAG_ENABLE:
+ if (track-nsamples 1) {
+ uint32_t tile_max =
G_028100_FMASK_TILE_MAX(track-cb_color_mask[i]);
+ /* the tile size is 8x8, but the size is in units of
bits.
+* for bytes, do just * 8. */
+ uint32_t bytes = track-nsamples *
track-log_nsamples * 8 * (tile_max + 1);
+
+ if (bytes + track-cb_color_frag_offset[i]
+ radeon_bo_size(track-cb_color_frag_bo[i])) {
+ dev_warn(p-dev, %s FMASK_TILE_MAX too large
+(tile_max=%u, bytes=%u,
offset=%llu, bo_size=%lu)\n,
+__func__, tile_max, bytes,
+track-cb_color_frag_offset[i],
+
radeon_bo_size(track-cb_color_frag_bo[i]));
+ return -EINVAL;
+ }
+ }
+ /* fall through */
+ case V_0280A0_CLEAR_ENABLE:
+ {
+ uint32_t block_max =
G_028100_CMASK_BLOCK_MAX(track-cb_color_mask[i]);
+ /* One block = 128x128 pixels, one 8x8 tile has 4 bits..
+* (128*128) / (8*8) / 2 = 128 bytes per block. */
+ uint32_t bytes = (block_max + 1) * 128;
+
+ if (bytes + track-cb_color_tile_offset[i]
+ radeon_bo_size(track-cb_color_tile_bo[i])) {
+ dev_warn(p-dev, %s CMASK_BLOCK_MAX too large
+
[Bug 44800] Radeon HD 6450 CAICOS screen corruption and kernel crashes
https://bugs.freedesktop.org/show_bug.cgi?id=44800 --- Comment #13 from Marko Kohtala marko.koht...@gmail.com 2012-08-19 18:09:19 UTC --- I applied drm/radeon: cleanup and fix crtc while programming mc and drm/radeon: fence virtual address and free it once idle [3.5] v2 on top of 3.5.2. Did not change this. I saw the usual corruption in the fb console as well as in the xinit running only xterm. This time I run 64-bit kernel under my 32-bit userspace. I had problems getting the 32-bit kernel to boot on my EFI. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix checking of MSAA renderbuffers on r600-r700
Signed-off-by: Marek Olšák mar...@gmail.com
---
drivers/gpu/drm/radeon/r600_cs.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 1bec5b8..ab74e6b 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -420,7 +420,8 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
}
/* check offset */
- tmp = r600_fmt_get_nblocksy(format, height) *
r600_fmt_get_nblocksx(format, pitch) * r600_fmt_get_blocksize(format);
+ tmp = r600_fmt_get_nblocksy(format, height) *
r600_fmt_get_nblocksx(format, pitch) *
+ r600_fmt_get_blocksize(format) * track-nsamples;
switch (array_mode) {
default:
case V_0280A0_ARRAY_LINEAR_GENERAL:
@@ -611,7 +612,7 @@ static int r600_cs_track_validate_db(struct
radeon_cs_parser *p)
ntiles = G_028000_SLICE_TILE_MAX(track-db_depth_size) + 1;
nviews = G_028004_SLICE_MAX(track-db_depth_view) + 1;
- tmp = ntiles * bpe * 64 * nviews;
+ tmp = ntiles * bpe * 64 * nviews * track-nsamples;
if ((tmp + track-db_offset) radeon_bo_size(track-db_bo)) {
dev_warn(p-dev, z/stencil buffer (%d) too small
(0x%08X %d %d %d - %u have %lu)\n,
array_mode,
@@ -1562,7 +1563,7 @@ unsigned r600_mip_minify(unsigned size, unsigned level)
}
static void r600_texture_size(unsigned nfaces, unsigned blevel, unsigned
llevel,
- unsigned w0, unsigned h0, unsigned d0, unsigned
format,
+ unsigned w0, unsigned h0, unsigned d0, unsigned
nsamples, unsigned format,
unsigned block_align, unsigned height_align,
unsigned base_align,
unsigned *l0_size, unsigned *mipmap_size)
{
@@ -1590,7 +1591,7 @@ static void r600_texture_size(unsigned nfaces, unsigned
blevel, unsigned llevel,
depth = r600_mip_minify(d0, i);
- size = nbx * nby * blocksize;
+ size = nbx * nby * blocksize * nsamples;
if (nfaces)
size *= nfaces;
else
@@ -1742,7 +1743,7 @@ static int r600_check_texture_resource(struct
radeon_cs_parser *p, u32 idx,
nfaces = larray - barray + 1;
}
- r600_texture_size(nfaces, blevel, llevel, w0, h0, d0, format,
+ r600_texture_size(nfaces, blevel, llevel, w0, h0, d0,
array_check.nsamples, format,
pitch_align, height_align, base_align,
l0_size, mipmap_size);
/* using get ib will give us the offset into the texture bo */
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] nouveau: avoid excessive gart aperture for on-board cards
Commit d0f3c7e41d30859a638083654002b9b6faf7f67b (drm/nouveau: give a slightly larger pci(e)gart aperture on all chipsets) removed a test: that caused an 8x increase in gart aperture, instead of a 2x one, for on-board cards = NV_40. Signed-off-by: Michele Ballabio barra_c...@katamail.com --- Hi, in Linux 3.5.x I experienced some crashes of the X server, and noticed from the boot that while the gart aperture in 3.4.x was 64MB, in 3.5.x became 512MB. So I came out with this quick patch: this seems to work, since X did not crash anymore (and I tried quite hard to), but I'm not sure if it is the right fix. drivers/gpu/drm/nouveau/nouveau_sgdma.c | 2 +- 1 file modificato, 1 inserzione(+). 1 rimozione(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c b/drivers/gpu/drm/nouveau/nouveau_sgdma.c index 38483a0..ebc27f7 100644 --- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c +++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c @@ -341,7 +341,7 @@ nouveau_sgdma_init(struct drm_device *dev) u32 aper_size, align; int ret; - if (dev_priv-card_type = NV_40) + if (dev_priv-card_type = NV_40 pci_is_pcie(dev-pdev)) aper_size = 512 * 1024 * 1024; else aper_size = 128 * 1024 * 1024; -- 1.7.11.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700
Please can someone tell me if this patch will end up in kernel 3.6 or 3.7.
If it is merged in Linus's tree in the coming days, I'll try to
complete R600-R700 MSAA support (and therefore GL3.0) for Mesa 9.0.
Marek
On Sun, Aug 19, 2012 at 2:22 AM, Marek Olšák mar...@gmail.com wrote:
MSAA is impossible without them.
Signed-off-by: Marek Olšák mar...@gmail.com
---
drivers/gpu/drm/radeon/r600_cs.c | 94
+-
drivers/gpu/drm/radeon/r600d.h | 17 ++
drivers/gpu/drm/radeon/radeon_drv.c |3 +-
drivers/gpu/drm/radeon/reg_srcs/r600 |8 ---
4 files changed, 101 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c
b/drivers/gpu/drm/radeon/r600_cs.c
index 3dab49c..1bec5b8 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -47,13 +47,17 @@ struct r600_cs_track {
u32 npipes;
/* value we track */
u32 sq_config;
+ u32 log_nsamples;
u32 nsamples;
u32 cb_color_base_last[8];
struct radeon_bo*cb_color_bo[8];
u64 cb_color_bo_mc[8];
- u32 cb_color_bo_offset[8];
- struct radeon_bo*cb_color_frag_bo[8]; /* unused */
- struct radeon_bo*cb_color_tile_bo[8]; /* unused */
+ u64 cb_color_bo_offset[8];
+ struct radeon_bo*cb_color_frag_bo[8];
+ u64 cb_color_frag_offset[8];
+ struct radeon_bo*cb_color_tile_bo[8];
+ u64 cb_color_tile_offset[8];
+ u32 cb_color_mask[8];
u32 cb_color_info[8];
u32 cb_color_view[8];
u32 cb_color_size_idx[8]; /* unused */
@@ -349,10 +353,6 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
unsigned array_mode;
u32 format;
- if (G_0280A0_TILE_MODE(track-cb_color_info[i])) {
- dev_warn(p-dev, FMASK or CMASK buffer are not supported by
this kernel\n);
- return -EINVAL;
- }
size = radeon_bo_size(track-cb_color_bo[i]) -
track-cb_color_bo_offset[i];
format = G_0280A0_FORMAT(track-cb_color_info[i]);
if (!r600_fmt_is_valid_color(format)) {
@@ -441,7 +441,7 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
* broken userspace.
*/
} else {
- dev_warn(p-dev, %s offset[%d] %d %d %d %lu too big
(%d %d) (%d %d %d)\n,
+ dev_warn(p-dev, %s offset[%d] %d %llu %d %lu too
big (%d %d) (%d %d %d)\n,
__func__, i, array_mode,
track-cb_color_bo_offset[i], tmp,
radeon_bo_size(track-cb_color_bo[i]),
@@ -458,6 +458,51 @@ static int r600_cs_track_validate_cb(struct
radeon_cs_parser *p, int i)
tmp = S_028060_PITCH_TILE_MAX((pitch / 8) - 1) |
S_028060_SLICE_TILE_MAX(slice_tile_max - 1);
ib[track-cb_color_size_idx[i]] = tmp;
+
+ /* FMASK/CMASK */
+ switch (G_0280A0_TILE_MODE(track-cb_color_info[i])) {
+ case V_0280A0_TILE_DISABLE:
+ break;
+ case V_0280A0_FRAG_ENABLE:
+ if (track-nsamples 1) {
+ uint32_t tile_max =
G_028100_FMASK_TILE_MAX(track-cb_color_mask[i]);
+ /* the tile size is 8x8, but the size is in units of
bits.
+* for bytes, do just * 8. */
+ uint32_t bytes = track-nsamples *
track-log_nsamples * 8 * (tile_max + 1);
+
+ if (bytes + track-cb_color_frag_offset[i]
+ radeon_bo_size(track-cb_color_frag_bo[i])) {
+ dev_warn(p-dev, %s FMASK_TILE_MAX too large
+(tile_max=%u, bytes=%u,
offset=%llu, bo_size=%lu)\n,
+__func__, tile_max, bytes,
+track-cb_color_frag_offset[i],
+
radeon_bo_size(track-cb_color_frag_bo[i]));
+ return -EINVAL;
+ }
+ }
+ /* fall through */
+ case V_0280A0_CLEAR_ENABLE:
+ {
+ uint32_t block_max =
G_028100_CMASK_BLOCK_MAX(track-cb_color_mask[i]);
+ /* One block = 128x128 pixels, one 8x8 tile has 4 bits..
+* (128*128) / (8*8) / 2 = 128 bytes per block. */
+ uint32_t bytes = (block_max + 1) * 128;
+
+ if (bytes +
Re: [PATCH] drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700
On Mon, Aug 20, 2012 at 7:51 AM, Marek Olšák mar...@gmail.com wrote: Please can someone tell me if this patch will end up in kernel 3.6 or 3.7. If it is merged in Linus's tree in the coming days, I'll try to complete R600-R700 MSAA support (and therefore GL3.0) for Mesa 9.0. I'll try and get it merged to 3.6 sometime this week. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #12 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-08-19 22:22:24 UTC --- I tried to trace RenderFeatTest (one of the other applications locking my system). It did as with the piglit test: it didn't crash. However, the rendering is corrupted where it locks when launched from a terminal. Trace is 75MB when compressed if you want me to upload it somewhere. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #13 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-08-19 23:03:48 UTC --- (In reply to comment #12) I tried to trace RenderFeatTest (one of the other applications locking my system). It did as with the piglit test: it didn't crash. However, the rendering is corrupted where it locks when launched from a terminal. Trace is 75MB when compressed if you want me to upload it somewhere. I forgot to say: it doesn't lock anymore at all. I should have written ... where it locked when launched from a terminal. It was locking at test 7. I'm attaching a screenshot from that test. I'll bisect to see if I can find which commit fixed the lock. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #14 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-08-19 23:04:33 UTC --- Created attachment 65813 -- https://bugs.freedesktop.org/attachment.cgi?id=65813 bad rendereing on test 7, where it used to lock -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46231] New: Radeon NI: evergreen_resume fails after GPU lockup
https://bugzilla.kernel.org/show_bug.cgi?id=46231 Summary: Radeon NI: evergreen_resume fails after GPU lockup Product: Drivers Version: 2.5 Kernel Version: 3.6-rc2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: b...@b1c1l1.com Regression: No I've always had GPU lockups on my Radeon HD 6750M (MacBookPro8,2) but have not been able to get good kernel messages until upgrading to 3.6-rc2: [88296.175333] radeon :01:00.0: GPU lockup CP stall for more than 1msec [88296.175348] radeon :01:00.0: GPU lockup (waiting for 0x004f368c last fence id 0x004f3681) [88296.176433] radeon :01:00.0: Saved 439 dwords of commands on ring 0. [88296.176439] radeon :01:00.0: GPU softreset [88296.176445] radeon :01:00.0: GRBM_STATUS=0xA00038A0 [88296.176450] radeon :01:00.0: GRBM_STATUS_SE0=0x0007 [88296.176455] radeon :01:00.0: GRBM_STATUS_SE1=0x0007 [88296.176460] radeon :01:00.0: SRBM_STATUS=0x20C0 [88296.176466] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x0100 [88296.176471] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x00011002 [88296.176476] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x00028506 [88296.176482] radeon :01:00.0: R_008680_CP_STAT = 0x80838647 [88296.176493] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [88296.176600] radeon :01:00.0: GRBM_STATUS=0x800038A0 [88296.176605] radeon :01:00.0: GRBM_STATUS_SE0=0x0007 [88296.176610] radeon :01:00.0: GRBM_STATUS_SE1=0x0007 [88296.176615] radeon :01:00.0: SRBM_STATUS=0x20C0 [88296.176620] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [88296.176625] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [88296.176630] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [88296.176636] radeon :01:00.0: R_008680_CP_STAT = 0x [88296.177642] radeon :01:00.0: GPU reset succeeded, trying to resume [88296.177647] radeon :01:00.0: GPU softreset [88296.177652] radeon :01:00.0: GRBM_STATUS=0x800038A0 [88296.177657] radeon :01:00.0: GRBM_STATUS_SE0=0x0007 [88296.177662] radeon :01:00.0: GRBM_STATUS_SE1=0x0007 [88296.177667] radeon :01:00.0: SRBM_STATUS=0x20C0 [88296.177672] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [88296.177677] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [88296.177682] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [88296.177687] radeon :01:00.0: R_008680_CP_STAT = 0x [88296.177698] radeon :01:00.0: GRBM_SOFT_RESET=0x7F6B [88296.177805] radeon :01:00.0: GRBM_STATUS=0x800038A0 [88296.177810] radeon :01:00.0: GRBM_STATUS_SE0=0x0007 [88296.177814] radeon :01:00.0: GRBM_STATUS_SE1=0x0007 [88296.177819] radeon :01:00.0: SRBM_STATUS=0x20C0 [88296.177824] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [88296.177829] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [88296.177835] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [88296.177840] radeon :01:00.0: R_008680_CP_STAT = 0x [88296.183915] [drm] probing gen 2 caps for device 8086:101 = 2/0 [88296.183918] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [88296.187771] [drm] PCIE GART of 512M enabled (table at 0x0004). [88296.187948] radeon :01:00.0: WB enabled [88296.187957] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x880265260c00 [88296.417147] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) [88296.417150] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume blee@supra ~ $ lspci -nn | grep VGA 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Whistler [AMD Radeon HD 6600M Series] [1002:6741] -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/13] drm/exynos: separated subdrv-probe call and encoder/connector creation.
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch separates sub driver's probe call and encoder/connector creation
so that exynos drm core module can take exception when some operation was
failed properly.
Which exceptions? I don't know this patch gives any benefit to us.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 93 +-
1 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..1c8d5fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,30 +34,15 @@
static LIST_HEAD(exynos_drm_subdrv_list);
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
+ int ret;
DRM_DEBUG_DRIVER(%s\n, __FILE__);
- if (subdrv-probe) {
- int ret;
-
- /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for modularization.
-*/
- ret = subdrv-probe(dev, subdrv-dev);
- if (ret)
- return ret;
- }
-
if (!subdrv-manager)
return 0;
@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR(failed to create connector\n);
- encoder-funcs-destroy(encoder);
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_destroy_encoder;
}
subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
+
+err_destroy_encoder:
+ encoder-funcs-destroy(encoder);
+ return ret;
}
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
{
- DRM_DEBUG_DRIVER(%s\n, __FILE__);
-
- if (subdrv-remove)
- subdrv-remove(dev);
-
if (subdrv-encoder) {
struct drm_encoder *encoder = subdrv-encoder;
encoder-funcs-destroy(encoder);
@@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device *dev,
}
}
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ if (subdrv-probe) {
+ int ret;
+
+ subdrv-drm_dev = dev;
+
+ /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for modularization.
+*/
+ ret = subdrv-probe(dev, subdrv-dev);
+ if (ret)
+ return ret;
+ }
+
+ if (!subdrv-manager)
+ return -EINVAL;
+
+ subdrv-manager-dev = subdrv-dev;
+
+ return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ DRM_DEBUG_DRIVER(%s\n, __FILE__);
+
+ if (subdrv-remove)
+ subdrv-remove(dev, subdrv-dev);
+}
+
int exynos_drm_device_register(struct drm_device *dev)
{
struct exynos_drm_subdrv *subdrv, *n;
+ unsigned int fine_cnt = 0;
int err;
DRM_DEBUG_DRIVER(%s\n, __FILE__);
@@ -120,14 +142,27 @@ int exynos_drm_device_register(struct drm_device *dev)
return -EINVAL;
list_for_each_entry_safe(subdrv, n, exynos_drm_subdrv_list, list) {
- subdrv-drm_dev = dev;
err = exynos_drm_subdrv_probe(dev, subdrv);
if (err) {
DRM_DEBUG(exynos drm subdrv probe failed.\n);
list_del(subdrv-list);
+ continue;
}
+
+ err = exynos_drm_create_enc_conn(dev, subdrv);
+ if (err) {
+ DRM_DEBUG(failed to create encoder and connector.\n);
+ exynos_drm_subdrv_remove(dev, subdrv);
+
Re: [PATCH 04/13] drm/exynos: use empty function instead of drm_helper_connector_dpms
On 08/17/2012 06:50 PM, Inki Dae wrote:
crtc and encoder's dpms callback will be called before connector's dpms
is called so drm_helper_connector_dpms doesn't need to be called.
I can't understand this description. I know crtc and encoder dpms are called
by drm_helper_connector_dpms.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index d956819..65acf0d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -226,6 +226,13 @@ static struct drm_connector_helper_funcs
exynos_connector_helper_funcs = {
.best_encoder = exynos_drm_best_encoder,
};
+static void exynos_drm_connector_dpms(struct drm_connector *connector, int mode)
+{
+ DRM_DEBUG_KMS(%s\n, __FILE__);
+
+ /* drm framework doesn't check NULL. */
+}
+
static int exynos_drm_connector_fill_modes(struct drm_connector *connector,
unsigned int max_width, unsigned int max_height)
{
@@ -285,7 +292,7 @@ static void exynos_drm_connector_destroy(struct
drm_connector *connector)
}
static struct drm_connector_funcs exynos_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
+ .dpms = exynos_drm_connector_dpms,
.fill_modes = exynos_drm_connector_fill_modes,
.detect = exynos_drm_connector_detect,
.destroy= exynos_drm_connector_destroy,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/13] drm/exynos: removed exynos_drm_encoder_dpms call
On 08/17/2012 06:50 PM, Inki Dae wrote:
encoder's mode_set callback isn't specific to hardware so it doesn't
need to call exynos_drm_encoder_dpms().
Then, where is exynos_drm_encoder_dpms() called?
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 2c037cd..3dae250 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -138,8 +138,6 @@ static void exynos_drm_encoder_mode_set(struct drm_encoder
*encoder,
DRM_DEBUG_KMS(%s\n, __FILE__);
- exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
-
list_for_each_entry(connector, dev-mode_config.connector_list, head) {
if (connector-encoder == encoder)
if (manager_ops manager_ops-mode_set)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd-handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 65 +++-
drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
4 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..2d1bc3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
* exynos specific framebuffer structure.
*
* @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
* @exynos_gem_obj: array of exynos specific gem object containing a gem
object.
*/
struct exynos_drm_fb {
struct drm_framebuffer fb;
+ unsigned intbuf_cnt;
struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
};
@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs exynos_drm_fb_funcs = {
.dirty = exynos_drm_fb_dirty,
};
+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+ unsigned int cnt)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ exynos_fb-buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ return exynos_fb-buf_cnt;
+}
+
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return exynos_fb-fb;
}
+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ unsigned int cnt = 0;
+
+ if (mode_cmd-pixel_format == DRM_FORMAT_NV12MT)
+ return 2;
+
+ while (cnt != MAX_FB_BUFFER) {
+ if (!mode_cmd-handles[cnt])
+ break;
+ cnt++;
+ }
+
+ /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+ if (cnt == 2) {
+ /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+ if (mode_cmd-offsets[1]
+ mode_cmd-handles[0] == mode_cmd-handles[1])
+ cnt = 1;
+ }
+
+ return cnt;
+}
No, please don't add specific function. There is already
drm_format_num_planes() function
+
static struct drm_framebuffer *
exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
struct drm_mode_fb_cmd2 *mode_cmd)
@@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
struct exynos_drm_fb *exynos_fb;
- int nr;
int i;
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -152,9 +209,11 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
}
exynos_fb = to_exynos_fb(fb);
- nr = exynos_drm_format_num_buffers(fb-pixel_format);
+ exynos_fb-buf_cnt = exynos_drm_format_num_buffers(mode_cmd);
+
+ DRM_DEBUG_KMS(buf_cnt = %d\n, exynos_fb-buf_cnt);
- for (i = 1; i nr; i++) {
+ for (i = 1; i exynos_fb-buf_cnt; i++) {
obj = drm_gem_object_lookup(dev, file_priv,
mode_cmd-handles[i]);
if (!obj) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h
b/drivers/gpu/drm/exynos/exynos_drm_fb.h
index 5082375..96262e5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
@@ -28,19 +28,6 @@
#ifndef _EXYNOS_DRM_FB_H_
#define _EXYNOS_DRM_FB_H
-static inline int exynos_drm_format_num_buffers(uint32_t format)
-{
- switch (format) {
- case DRM_FORMAT_NV12:
- case DRM_FORMAT_NV12MT:
- return 2;
- case DRM_FORMAT_YUV420:
-
Re: [PATCH 10/13] drm/exynos: update crtc to plane safely
On 08/17/2012 06:50 PM, Inki Dae wrote:
if old_crtc isn't same as encoder-crtc then it means that
user changed crtc id to another one so a plane to old_crtc
should be disabled so that current plane can be updated safely
and plane-crtc should be set to new crtc(encoder-crtc)
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 59 +-
1 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index a562a94..7bcace8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -44,6 +44,7 @@
* @dpms: store the encoder dpms value.
*/
struct exynos_drm_encoder {
+ struct drm_crtc *old_crtc;
struct drm_encoder drm_encoder;
struct exynos_drm_manager *manager;
int dpms;
@@ -106,22 +107,74 @@ exynos_drm_encoder_mode_fixup(struct drm_encoder *encoder,
return true;
}
+static void disable_plane_to_crtc(struct drm_device *dev,
+ struct drm_crtc *old_crtc,
+ struct drm_crtc *new_crtc)
+{
+ struct drm_plane *plane;
+
+ /*
+* if old_crtc isn't same as encoder-crtc then it means that
+* user changed crtc id to another one so the plane to old_crtc
+* should be disabled and plane-crtc should be set to new_crtc
+* (encoder-crtc)
+*/
+ list_for_each_entry(plane, dev-mode_config.plane_list, head) {
+ if (plane-crtc == old_crtc) {
+ /*
+* do not change below call order.
+*
+* plane-funcs-disable_plane call checks
+* if encoder-crtc is same as plane-crtc and if same
+* then overlay_ops-disable callback will be called
+* to diasble current hw overlay so plane-crtc should
+* have new_crtc because new_crtc was set to
+* encoder-crtc in advance.
+*/
+ plane-crtc = new_crtc;
+ plane-funcs-disable_plane(plane);
+ }
+ }
+}
+
static void exynos_drm_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_device *dev = encoder-dev;
struct drm_connector *connector;
- struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
- struct exynos_drm_manager_ops *manager_ops = manager-ops;
+ struct exynos_drm_manager *manager;
+ struct exynos_drm_manager_ops *manager_ops;
DRM_DEBUG_KMS(%s\n, __FILE__);
list_for_each_entry(connector, dev-mode_config.connector_list, head) {
- if (connector-encoder == encoder)
+ if (connector-encoder == encoder) {
+ struct exynos_drm_encoder *exynos_encoder;
+
+ exynos_encoder = to_exynos_encoder(encoder);
Does needs to do this in for statement?
+
+ if (exynos_encoder-old_crtc != encoder-crtc
+ exynos_encoder-old_crtc) {
+
+ /*
+* disable a plane to old crtc and change
+* crtc of the plane to new one.
+*/
+ disable_plane_to_crtc(dev,
+ exynos_encoder-old_crtc,
+ encoder-crtc);
+ }
+
+ manager = exynos_drm_get_manager(encoder);
+ manager_ops = manager-ops;
Does needs to do this in for statement?
+
if (manager_ops manager_ops-mode_set)
manager_ops-mode_set(manager-dev,
adjusted_mode);
+
+ exynos_encoder-old_crtc = encoder-crtc;
+ }
}
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/13] drm/exynos: changed context name of hdmi and mixer
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch changes ctx variable name in exynos_drm_hdmi_context
structure to client because the use of ctx variable makes it confused.
I don't prefer client name. This is not client and server relationship.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 38 +++---
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 12
drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 3fdf0b6..bced38e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-is_connected)
- return hdmi_ops-is_connected(ctx-hdmi_ctx-ctx);
+ return hdmi_ops-is_connected(ctx-hdmi_ctx-client);
return false;
}
@@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-get_edid)
- return hdmi_ops-get_edid(ctx-hdmi_ctx-ctx, connector, edid,
- len);
+ return hdmi_ops-get_edid(ctx-hdmi_ctx-client, connector,
+ edid, len);
return 0;
}
@@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev, void
*timing)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-check_timing)
- return hdmi_ops-check_timing(ctx-hdmi_ctx-ctx, timing);
+ return hdmi_ops-check_timing(ctx-hdmi_ctx-client, timing);
return 0;
}
@@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev, int mode)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-power_on)
- return hdmi_ops-power_on(ctx-hdmi_ctx-ctx, mode);
+ return hdmi_ops-power_on(ctx-hdmi_ctx-client, mode);
return 0;
}
@@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device *subdrv_dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (mixer_ops mixer_ops-enable_vblank)
- return mixer_ops-enable_vblank(ctx-mixer_ctx-ctx,
+ return mixer_ops-enable_vblank(ctx-mixer_ctx-client,
manager-pipe);
return 0;
@@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct device
*subdrv_dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (mixer_ops mixer_ops-disable_vblank)
- return mixer_ops-disable_vblank(ctx-mixer_ctx-ctx);
+ return mixer_ops-disable_vblank(ctx-mixer_ctx-client);
}
static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
struct drm_connector *connector,
- const struct drm_display_mode *mode,
+ struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_hdmi_context *ctx = to_context(subdrv_dev);
@@ -150,7 +150,7 @@ static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-mode_fixup)
- hdmi_ops-mode_fixup(ctx-hdmi_ctx-ctx, connector, mode,
+ hdmi_ops-mode_fixup(ctx-hdmi_ctx-client, connector, mode,
adjusted_mode);
}
@@ -161,7 +161,7 @@ static void drm_hdmi_mode_set(struct device *subdrv_dev, void *mode)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-mode_set)
- hdmi_ops-mode_set(ctx-hdmi_ctx-ctx, mode);
+ hdmi_ops-mode_set(ctx-hdmi_ctx-client, mode);
}
static void drm_hdmi_get_max_resol(struct device *subdrv_dev,
@@ -172,7 +172,7 @@ static void drm_hdmi_get_max_resol(struct device
*subdrv_dev,
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-get_max_resol)
- hdmi_ops-get_max_resol(ctx-hdmi_ctx-ctx, width, height);
+ hdmi_ops-get_max_resol(ctx-hdmi_ctx-client, width, height);
}
static void drm_hdmi_commit(struct device *subdrv_dev)
@@ -182,7 +182,7 @@ static void drm_hdmi_commit(struct device *subdrv_dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-commit)
- hdmi_ops-commit(ctx-hdmi_ctx-ctx);
+ hdmi_ops-commit(ctx-hdmi_ctx-client);
}
static void drm_hdmi_dpms(struct device *subdrv_dev, int mode)
@@ -192,10 +192,10 @@ static void drm_hdmi_dpms(struct device *subdrv_dev, int
mode)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (mixer_ops mixer_ops-dpms)
-
Re: [PATCH V3 2/2] video: drm: exynos: Add device tree support
On 08/17/2012 06:37 PM, Leela Krishna Amudala wrote:
Hello,
On Fri, Aug 17, 2012 at 6:55 AM, Joonyoung Shim dofm...@gmail.com wrote:
Hi,
2012/8/16 Leela Krishna Amudala l.kris...@samsung.com:
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95 -
2 files changed, 173 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt
diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt
b/Documentation/devicetree/bindings/fb/drm-fimd.txt
new file mode 100644
index 000..8ad8814
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
@@ -0,0 +1,80 @@
+* Samsung Display Controller using DRM frame work
+
+The display controller is used to transfer image data from memory to an
+external LCD driver interface. It supports various color formats such as
+rgb and yuv.
+
+Required properties:
+ - compatible: Should be samsung,exynos5-drm for fimd using DRM frame work.
Just use samsung,exynos5-fb and add to support exynos4-fb
In the first version of this patch set I used samsung,exynos5-fb,
but as per Kyungmin Park's suggestion changed it to exynos5-drm.
OK, but this doesn't mean drm device so it is right to use exynos5-fimd.
Add exynos5-fimd compatible and also use exynos5-fb, it is used in
s3c-fb driver.
+ - reg: physical base address of the controller and length of memory
+ mapped region.
+ - interrupts: Three interrupts should be specified. The interrupts should be
+ specified in the following order.
+ - VSYNC interrupt
+ - FIFO level interrupt
+ - FIMD System Interrupt
+
+ - samsung,fimd-display: This property should specify the phandle of the
+ display device node which holds the video interface timing with the
+ below mentioned properties.
+
+ - lcd-htiming: Specifies the horizontal timing for the overlay. The
+ horizontal timing includes four parameters in the following order.
+
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - Display panels X resolution.
+
+ - lcd-vtiming: Specifies the vertical timing for the overlay. The
+ vertical timing includes four parameters in the following order.
+
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Display panels Y resolution.
+
+
+ - samsung,default-window: Specifies the default window number of the fimd
controller.
+
+ - samsung,fimd-win-bpp: Specifies the bits per pixel.
+
+Optional properties:
+ - supports-mipi-panel: Specifies the lcd is mipi panel type
How is this property used?
As this driver can be interfaced through MIPI or eDP, Arch side code
will check whether this property is available or not, if it is
available then it assumes mipi panel is connected and certain clock
rate will be set to fimd clock, otherwise assumes other panel is
connected and other clock rate will be set at arch side.
But it is not used currently in the driver.
+ - samsung,fimd-vidout-rgb: Video output format is RGB.
+ - samsung,fimd-inv-vclk: invert video clock polarity.
+ - samsung,fimd-frame-rate: Number of video frames per second.
+
+Example:
+
+ The following is an example for the fimd controller is split into
+ two portions. The SoC specific portion can be specified in the SoC
+ specific dts file. The board specific portion can be specified in the
+ board specific dts file.
+
+ - SoC Specific portion
+
+ fimd {
+ compatible = samsung,exynos5-drm;
+ interrupt-parent = combiner;
+ reg = 0x1440 0x4;
+ interrupts = 18 5, 18 4, 18 6;
+ };
+
+ - Board Specific portion
+
+ lcd_fimd0: lcd_panel0 {
+ lcd-htiming = 4 4 4 480;
+ lcd-vtiming = 4 4 4 320;
+ supports-mipi-panel;
+ };
+
+ fimd {
+ samsung,fimd-display = lcd_fimd0;
+ samsung,fimd-vidout-rgb;
+ samsung,fimd-inv-vclk;
+ samsung,fimd-frame-rate = 60;
+ samsung,default-window = 0;
+ samsung,fimd-win-bpp = 32;
+ };
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 8379c59..1753846 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/clk.h
#include linux/pm_runtime.h
+#include linux/of.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -103,9 +104,18 @@ struct fimd_context {
struct
Re: [PATCH 02/13] drm/exynos: separated subdrv-probe call and encoder/connector creation.
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch separates sub driver's probe call and encoder/connector
creation
so that exynos drm core module can take exception when some operation was
failed properly.
Which exceptions? I don't know this patch gives any benefit to us.
previous code didn't take exception when exynos_drm_encoder_create()
is falied. and for now, exynos_drm_encoder/connector_create functions
was called at exynos_drm_subdrv_probe() so know that this patch is for
code clean by separating them into two parts also.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 93
+-
1 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..1c8d5fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,30 +34,15 @@
static LIST_HEAD(exynos_drm_subdrv_list);
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
+ int ret;
DRM_DEBUG_DRIVER(%s\n, __FILE__);
- if (subdrv-probe) {
- int ret;
-
- /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by
load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for
modularization.
-*/
- ret = subdrv-probe(dev, subdrv-dev);
- if (ret)
- return ret;
- }
-
if (!subdrv-manager)
return 0;
@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device
*dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR(failed to create connector\n);
- encoder-funcs-destroy(encoder);
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_destroy_encoder;
}
subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
+
+err_destroy_encoder:
+ encoder-funcs-destroy(encoder);
+ return ret;
}
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
{
- DRM_DEBUG_DRIVER(%s\n, __FILE__);
-
- if (subdrv-remove)
- subdrv-remove(dev);
-
if (subdrv-encoder) {
struct drm_encoder *encoder = subdrv-encoder;
encoder-funcs-destroy(encoder);
@@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device
*dev,
}
}
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ if (subdrv-probe) {
+ int ret;
+
+ subdrv-drm_dev = dev;
+
+ /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by
load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for
modularization.
+*/
+ ret = subdrv-probe(dev, subdrv-dev);
+ if (ret)
+ return ret;
+ }
+
+ if (!subdrv-manager)
+ return -EINVAL;
+
+ subdrv-manager-dev = subdrv-dev;
+
+ return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ DRM_DEBUG_DRIVER(%s\n, __FILE__);
+
+ if (subdrv-remove)
+ subdrv-remove(dev, subdrv-dev);
+}
+
int exynos_drm_device_register(struct drm_device *dev)
{
struct exynos_drm_subdrv *subdrv, *n;
+ unsigned int fine_cnt = 0;
int err;
DRM_DEBUG_DRIVER(%s\n, __FILE__);
@@ -120,14 +142,27 @@ int exynos_drm_device_register(struct drm_device
*dev)
return -EINVAL;
list_for_each_entry_safe(subdrv, n, exynos_drm_subdrv_list, list)
{
- subdrv-drm_dev = dev;
err = exynos_drm_subdrv_probe(dev, subdrv);
Re: [PATCH 02/13] drm/exynos: separated subdrv-probe call and encoder/connector creation.
On 08/20/2012 10:52 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch separates sub driver's probe call and encoder/connector
creation
so that exynos drm core module can take exception when some operation was
failed properly.
Which exceptions? I don't know this patch gives any benefit to us.
previous code didn't take exception when exynos_drm_encoder_create()
is falied.
No, it is considered.
and for now, exynos_drm_encoder/connector_create functions
was called at exynos_drm_subdrv_probe() so know that this patch is for
code clean by separating them into two parts also.
It's ok, but it just splitting.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 93
+-
1 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..1c8d5fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,30 +34,15 @@
static LIST_HEAD(exynos_drm_subdrv_list);
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
+ int ret;
DRM_DEBUG_DRIVER(%s\n, __FILE__);
- if (subdrv-probe) {
- int ret;
-
- /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by
load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for
modularization.
-*/
- ret = subdrv-probe(dev, subdrv-dev);
- if (ret)
- return ret;
- }
-
if (!subdrv-manager)
return 0;
@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device
*dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR(failed to create connector\n);
- encoder-funcs-destroy(encoder);
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_destroy_encoder;
}
subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
+
+err_destroy_encoder:
+ encoder-funcs-destroy(encoder);
+ return ret;
}
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
{
- DRM_DEBUG_DRIVER(%s\n, __FILE__);
-
- if (subdrv-remove)
- subdrv-remove(dev);
-
if (subdrv-encoder) {
struct drm_encoder *encoder = subdrv-encoder;
encoder-funcs-destroy(encoder);
@@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device
*dev,
}
}
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ if (subdrv-probe) {
+ int ret;
+
+ subdrv-drm_dev = dev;
+
+ /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by
load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for
modularization.
+*/
+ ret = subdrv-probe(dev, subdrv-dev);
+ if (ret)
+ return ret;
+ }
+
+ if (!subdrv-manager)
+ return -EINVAL;
+
+ subdrv-manager-dev = subdrv-dev;
+
+ return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ DRM_DEBUG_DRIVER(%s\n, __FILE__);
+
+ if (subdrv-remove)
+ subdrv-remove(dev, subdrv-dev);
+}
+
int exynos_drm_device_register(struct drm_device *dev)
{
struct exynos_drm_subdrv *subdrv, *n;
+ unsigned int fine_cnt = 0;
int err;
DRM_DEBUG_DRIVER(%s\n, __FILE__);
@@ -120,14 +142,27 @@ int exynos_drm_device_register(struct drm_device
*dev)
return -EINVAL;
list_for_each_entry_safe(subdrv, n, exynos_drm_subdrv_list, list)
{
- subdrv-drm_dev = dev;
err = exynos_drm_subdrv_probe(dev, subdrv);
Re: [PATCH 05/13] drm/exynos: removed exynos_drm_encoder_dpms call
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
encoder's mode_set callback isn't specific to hardware so it doesn't
need to call exynos_drm_encoder_dpms().
Then, where is exynos_drm_encoder_dpms() called?
with this patch series, exynos_drm_encoder_dpms() will call apply
callback to set local overlay data to real hardware registers and
exynos_drm_crtc_dpms() will be used to enable/disable fimd or hdmi
power(clock and regulator). actually, previous codes called mode_set
two times so this could make it messed up other display sub devices
such as mDNIe.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 2c037cd..3dae250 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -138,8 +138,6 @@ static void exynos_drm_encoder_mode_set(struct
drm_encoder *encoder,
DRM_DEBUG_KMS(%s\n, __FILE__);
- exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
-
list_for_each_entry(connector, dev-mode_config.connector_list,
head) {
if (connector-encoder == encoder)
if (manager_ops manager_ops-mode_set)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/13] drm/exynos: make sure that hardware overlay for fimd is disabled
On 08/17/2012 06:50 PM, Inki Dae wrote:
the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 17 +
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 10 ++
drivers/gpu/drm/exynos/exynos_drm_fimd.c| 12
Please split patch to exynos_drm part and fimd part.
3 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 24c45d8..00e4bdc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -37,6 +37,20 @@
#define MAX_FB_BUFFER 4
#define DEFAULT_ZPOS -1
+#define _wait_for(COND, MS) ({ \
+ unsigned long timeout__ = jiffies + msecs_to_jiffies(MS); \
+ int ret__ = 0; \
+ while (!(COND)) { \
+ if (time_after(jiffies, timeout__)) { \
+ ret__ = -ETIMEDOUT; \
+ break; \
+ } \
+ } \
+ ret__; \
+})
+
+#define wait_for(COND, MS) _wait_for(COND, MS)
+
struct drm_device;
struct exynos_drm_overlay;
struct drm_connector;
@@ -61,6 +75,8 @@ enum exynos_drm_output_type {
* @commit: apply hardware specific overlay data to registers.
* @enable: enable hardware specific overlay.
* @disable: disable hardware specific overlay.
+ * @wait_for_vblank: wait for vblank interrupt to make sure that
+ * dma transfer is completed.
*/
struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
@@ -68,6 +84,7 @@ struct exynos_drm_overlay_ops {
void (*commit)(struct device *subdrv_dev, int zpos);
void (*enable)(struct device *subdrv_dev, int zpos);
void (*disable)(struct device *subdrv_dev, int zpos);
+ void (*wait_for_vblank)(struct device *subdrv_dev);
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 7da5714..a562a94 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -399,4 +399,14 @@ void exynos_drm_encoder_plane_disable(struct drm_encoder
*encoder, void *data)
if (overlay_ops overlay_ops-disable)
overlay_ops-disable(manager-dev, zpos);
+
+ /*
+* wait for vblank interrupt
+* - with iommu, the dma operation could induce page fault
+* when accessed to memory after gem buffer was released so
+* make sure that the dma operation is completed before releasing
+* the gem bufer.
+*/
+ if (overlay_ops-wait_for_vblank)
+ overlay_ops-wait_for_vblank(manager-dev);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0ec9d86..2378d80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -570,10 +570,22 @@ static void fimd_win_disable(struct device *dev, int zpos)
win_data-enabled = false;
}
+static void fimd_wait_for_vblank(struct device *dev)
+{
+ struct fimd_context *ctx = get_fimd_context(dev);
+ int ret;
+
+ ret = wait_for((__raw_readl(ctx-regs + VIDCON1)
+ VIDCON1_VSTATUS_BACKPORCH), 50);
+ if (ret 0)
+ DRM_DEBUG_KMS(vblank wait timed out.\n);
+}
+
static struct exynos_drm_overlay_ops fimd_overlay_ops = {
.mode_set = fimd_win_mode_set,
.commit = fimd_win_commit,
.disable = fimd_win_disable,
+ .wait_for_vblank = fimd_wait_for_vblank,
};
static struct exynos_drm_manager fimd_manager = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd-handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
+++-
drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
4 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..2d1bc3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
* exynos specific framebuffer structure.
*
* @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
* @exynos_gem_obj: array of exynos specific gem object containing a gem
object.
*/
struct exynos_drm_fb {
struct drm_framebuffer fb;
+ unsigned intbuf_cnt;
struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
};
@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
exynos_drm_fb_funcs = {
.dirty = exynos_drm_fb_dirty,
};
+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+ unsigned int cnt)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ exynos_fb-buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ return exynos_fb-buf_cnt;
+}
+
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return exynos_fb-fb;
}
+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
*mode_cmd)
+{
+ unsigned int cnt = 0;
+
+ if (mode_cmd-pixel_format == DRM_FORMAT_NV12MT)
+ return 2;
+
+ while (cnt != MAX_FB_BUFFER) {
+ if (!mode_cmd-handles[cnt])
+ break;
+ cnt++;
+ }
+
+ /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+ if (cnt == 2) {
+ /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+ if (mode_cmd-offsets[1]
+ mode_cmd-handles[0] == mode_cmd-handles[1])
+ cnt = 1;
+ }
+
+ return cnt;
+}
No, please don't add specific function. There is already
drm_format_num_planes() function
I know that, but NV12M format is specific to Exynos. for this, we
already had a discussion and you can refer to below link,
http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
+
static struct drm_framebuffer *
exynos_user_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
struct drm_mode_fb_cmd2 *mode_cmd)
@@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
struct exynos_drm_fb *exynos_fb;
- int nr;
int i;
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -152,9 +209,11 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
}
exynos_fb = to_exynos_fb(fb);
- nr = exynos_drm_format_num_buffers(fb-pixel_format);
+ exynos_fb-buf_cnt = exynos_drm_format_num_buffers(mode_cmd);
+
+ DRM_DEBUG_KMS(buf_cnt = %d\n, exynos_fb-buf_cnt);
- for (i = 1; i nr; i++) {
+ for (i = 1; i exynos_fb-buf_cnt; i++) {
obj = drm_gem_object_lookup(dev, file_priv,
mode_cmd-handles[i]);
if (!obj) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h
b/drivers/gpu/drm/exynos/exynos_drm_fb.h
index 5082375..96262e5 100644
---
Re: [PATCH 11/13] drm/exynos: changed context name of hdmi and mixer
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch changes ctx variable name in exynos_drm_hdmi_context
structure to client because the use of ctx variable makes it confused.
I don't prefer client name. This is not client and server relationship.
Okay, give me your opinion. which one do you prefer?
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 38
+++---
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 12
drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 3fdf0b6..bced38e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-is_connected)
- return hdmi_ops-is_connected(ctx-hdmi_ctx-ctx);
+ return hdmi_ops-is_connected(ctx-hdmi_ctx-client);
return false;
}
@@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-get_edid)
- return hdmi_ops-get_edid(ctx-hdmi_ctx-ctx, connector,
edid,
- len);
+ return hdmi_ops-get_edid(ctx-hdmi_ctx-client,
connector,
+ edid, len);
return 0;
}
@@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev,
void *timing)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-check_timing)
- return hdmi_ops-check_timing(ctx-hdmi_ctx-ctx, timing);
+ return hdmi_ops-check_timing(ctx-hdmi_ctx-client,
timing);
return 0;
}
@@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev, int
mode)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-power_on)
- return hdmi_ops-power_on(ctx-hdmi_ctx-ctx, mode);
+ return hdmi_ops-power_on(ctx-hdmi_ctx-client, mode);
return 0;
}
@@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device
*subdrv_dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (mixer_ops mixer_ops-enable_vblank)
- return mixer_ops-enable_vblank(ctx-mixer_ctx-ctx,
+ return mixer_ops-enable_vblank(ctx-mixer_ctx-client,
manager-pipe);
return 0;
@@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct device
*subdrv_dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (mixer_ops mixer_ops-disable_vblank)
- return mixer_ops-disable_vblank(ctx-mixer_ctx-ctx);
+ return mixer_ops-disable_vblank(ctx-mixer_ctx-client);
}
static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
struct drm_connector *connector,
- const struct drm_display_mode *mode,
+ struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_hdmi_context *ctx = to_context(subdrv_dev);
@@ -150,7 +150,7 @@ static void drm_hdmi_mode_fixup(struct device
*subdrv_dev,
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-mode_fixup)
- hdmi_ops-mode_fixup(ctx-hdmi_ctx-ctx, connector, mode,
+ hdmi_ops-mode_fixup(ctx-hdmi_ctx-client, connector,
mode,
adjusted_mode);
}
@@ -161,7 +161,7 @@ static void drm_hdmi_mode_set(struct device
*subdrv_dev, void *mode)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-mode_set)
- hdmi_ops-mode_set(ctx-hdmi_ctx-ctx, mode);
+ hdmi_ops-mode_set(ctx-hdmi_ctx-client, mode);
}
static void drm_hdmi_get_max_resol(struct device *subdrv_dev,
@@ -172,7 +172,7 @@ static void drm_hdmi_get_max_resol(struct device
*subdrv_dev,
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-get_max_resol)
- hdmi_ops-get_max_resol(ctx-hdmi_ctx-ctx, width,
height);
+ hdmi_ops-get_max_resol(ctx-hdmi_ctx-client, width,
height);
}
static void drm_hdmi_commit(struct device *subdrv_dev)
@@ -182,7 +182,7 @@ static void drm_hdmi_commit(struct device *subdrv_dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-commit)
- hdmi_ops-commit(ctx-hdmi_ctx-ctx);
+ hdmi_ops-commit(ctx-hdmi_ctx-client);
}
static void drm_hdmi_dpms(struct device
Re: [PATCH 04/13] drm/exynos: use empty function instead of drm_helper_connector_dpms
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
crtc and encoder's dpms callback will be called before connector's dpms
is called so drm_helper_connector_dpms doesn't need to be called.
I can't understand this description. I know crtc and encoder dpms are called
by drm_helper_connector_dpms.
Ah, right. there is my missing point. for pm, we need
drm_helper_connector_dpms call. actually, this patch is for avoiding
duplicated call of mode_set but I didn't consider pm.
Thanks.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index d956819..65acf0d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -226,6 +226,13 @@ static struct drm_connector_helper_funcs
exynos_connector_helper_funcs = {
.best_encoder = exynos_drm_best_encoder,
};
+static void exynos_drm_connector_dpms(struct drm_connector *connector,
int mode)
+{
+ DRM_DEBUG_KMS(%s\n, __FILE__);
+
+ /* drm framework doesn't check NULL. */
+}
+
static int exynos_drm_connector_fill_modes(struct drm_connector
*connector,
unsigned int max_width, unsigned int
max_height)
{
@@ -285,7 +292,7 @@ static void exynos_drm_connector_destroy(struct
drm_connector *connector)
}
static struct drm_connector_funcs exynos_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
+ .dpms = exynos_drm_connector_dpms,
.fill_modes = exynos_drm_connector_fill_modes,
.detect = exynos_drm_connector_detect,
.destroy= exynos_drm_connector_destroy,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set gfxpayload=$linux_gfx_mode put the display in a flickering state
https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #19 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-08-20 03:00:22 UTC --- Fixed by attachment 64759 (proposed in bug 42373 which is similar to this bug but is not the same since it is not fixed by the attachment) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 --- Comment #31 from Alexandre Demers alexandre.f.dem...@gmail.com 2012-08-20 03:01:28 UTC --- (In reply to comment #16) Created attachment 64759 [details] [review] Fixup mc programing This patch should fix your issue. This patch doesn't apply correctly on kernel 3.6-rc2. Would it be possible to rebase or, even better, push it to kernel since it fixes problem with CAYMAN (bug 43655, which should not be considered as a duplicate (similar symptoms, different fix)) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/13] drm/exynos: separated subdrv-probe call and encoder/connector creation.
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/20/2012 10:52 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch separates sub driver's probe call and encoder/connector
creation
so that exynos drm core module can take exception when some operation
was
failed properly.
Which exceptions? I don't know this patch gives any benefit to us.
previous code didn't take exception when exynos_drm_encoder_create()
is falied.
No, it is considered.
where is subdrv-remove() called when exynos_drm_encoder_create() is
failed? I think if failed then subdrv-remove() should be called and
if exynos_drm_connector_create() is failed then not only
encoder-funcs-destory() but also subdrv-remove()
and for now, exynos_drm_encoder/connector_create functions
was called at exynos_drm_subdrv_probe() so know that this patch is for
code clean by separating them into two parts also.
It's ok, but it just splitting.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 93
+-
1 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..1c8d5fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,30 +34,15 @@
static LIST_HEAD(exynos_drm_subdrv_list);
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv
*subdrv)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
+ int ret;
DRM_DEBUG_DRIVER(%s\n, __FILE__);
- if (subdrv-probe) {
- int ret;
-
- /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by
load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for
modularization.
-*/
- ret = subdrv-probe(dev, subdrv-dev);
- if (ret)
- return ret;
- }
-
if (!subdrv-manager)
return 0;
@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct
drm_device
*dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR(failed to create connector\n);
- encoder-funcs-destroy(encoder);
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_destroy_encoder;
}
subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
+
+err_destroy_encoder:
+ encoder-funcs-destroy(encoder);
+ return ret;
}
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv
*subdrv)
{
- DRM_DEBUG_DRIVER(%s\n, __FILE__);
-
- if (subdrv-remove)
- subdrv-remove(dev);
-
if (subdrv-encoder) {
struct drm_encoder *encoder = subdrv-encoder;
encoder-funcs-destroy(encoder);
@@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct
drm_device
*dev,
}
}
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+ struct exynos_drm_subdrv
*subdrv)
+{
+ if (subdrv-probe) {
+ int ret;
+
+ subdrv-drm_dev = dev;
+
+ /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by
load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for
modularization.
+*/
+ ret = subdrv-probe(dev, subdrv-dev);
+ if (ret)
+ return ret;
+ }
+
+ if (!subdrv-manager)
+ return -EINVAL;
+
+ subdrv-manager-dev = subdrv-dev;
+
+ return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ DRM_DEBUG_DRIVER(%s\n, __FILE__);
+
+ if (subdrv-remove)
+ subdrv-remove(dev, subdrv-dev);
+}
+
int exynos_drm_device_register(struct drm_device *dev)
{
Re: [PATCH 02/13] drm/exynos: separated subdrv-probe call and encoder/connector creation.
On 08/20/2012 01:31 PM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/20/2012 10:52 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch separates sub driver's probe call and encoder/connector
creation
so that exynos drm core module can take exception when some operation
was
failed properly.
Which exceptions? I don't know this patch gives any benefit to us.
previous code didn't take exception when exynos_drm_encoder_create()
is falied.
No, it is considered.
where is subdrv-remove() called when exynos_drm_encoder_create() is
failed? I think if failed then subdrv-remove() should be called and
if exynos_drm_connector_create() is failed then not only
encoder-funcs-destory() but also subdrv-remove()
OK, but just add subdrv-remove(). Then if it needs, please split function.
and for now, exynos_drm_encoder/connector_create functions
was called at exynos_drm_subdrv_probe() so know that this patch is for
code clean by separating them into two parts also.
It's ok, but it just splitting.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 93
+-
1 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..1c8d5fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,30 +34,15 @@
static LIST_HEAD(exynos_drm_subdrv_list);
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv
*subdrv)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
+ int ret;
DRM_DEBUG_DRIVER(%s\n, __FILE__);
- if (subdrv-probe) {
- int ret;
-
- /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by
load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for
modularization.
-*/
- ret = subdrv-probe(dev, subdrv-dev);
- if (ret)
- return ret;
- }
-
if (!subdrv-manager)
return 0;
@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct
drm_device
*dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR(failed to create connector\n);
- encoder-funcs-destroy(encoder);
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_destroy_encoder;
}
subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
+
+err_destroy_encoder:
+ encoder-funcs-destroy(encoder);
+ return ret;
}
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv
*subdrv)
{
- DRM_DEBUG_DRIVER(%s\n, __FILE__);
-
- if (subdrv-remove)
- subdrv-remove(dev);
-
if (subdrv-encoder) {
struct drm_encoder *encoder = subdrv-encoder;
encoder-funcs-destroy(encoder);
@@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct
drm_device
*dev,
}
}
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+ struct exynos_drm_subdrv
*subdrv)
+{
+ if (subdrv-probe) {
+ int ret;
+
+ subdrv-drm_dev = dev;
+
+ /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by
load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for
modularization.
+*/
+ ret = subdrv-probe(dev, subdrv-dev);
+ if (ret)
+ return ret;
+ }
+
+ if (!subdrv-manager)
+ return -EINVAL;
+
+ subdrv-manager-dev = subdrv-dev;
+
+ return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ DRM_DEBUG_DRIVER(%s\n, __FILE__);
+
+ if (subdrv-remove)
+ subdrv-remove(dev, subdrv-dev);
+}
+
int exynos_drm_device_register(struct drm_device *dev)
Re: [PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
On 08/20/2012 11:23 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd-handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
+++-
drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
4 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..2d1bc3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
* exynos specific framebuffer structure.
*
* @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
* @exynos_gem_obj: array of exynos specific gem object containing a gem
object.
*/
struct exynos_drm_fb {
struct drm_framebuffer fb;
+ unsigned intbuf_cnt;
struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
};
@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
exynos_drm_fb_funcs = {
.dirty = exynos_drm_fb_dirty,
};
+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+ unsigned int cnt)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ exynos_fb-buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ return exynos_fb-buf_cnt;
+}
+
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return exynos_fb-fb;
}
+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
*mode_cmd)
+{
+ unsigned int cnt = 0;
+
+ if (mode_cmd-pixel_format == DRM_FORMAT_NV12MT)
+ return 2;
+
+ while (cnt != MAX_FB_BUFFER) {
+ if (!mode_cmd-handles[cnt])
+ break;
+ cnt++;
+ }
+
+ /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+ if (cnt == 2) {
+ /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+ if (mode_cmd-offsets[1]
+ mode_cmd-handles[0] == mode_cmd-handles[1])
+ cnt = 1;
+ }
+
+ return cnt;
+}
No, please don't add specific function. There is already
drm_format_num_planes() function
I know that, but NV12M format is specific to Exynos. for this, we
already had a discussion and you can refer to below link,
http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
Yes, but this implementation is not clear, just get plane number using
drm_format_num_planes()
and check handle and offset argument when format is NV12.
+
static struct drm_framebuffer *
exynos_user_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
struct drm_mode_fb_cmd2 *mode_cmd)
@@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
struct exynos_drm_fb *exynos_fb;
- int nr;
int i;
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -152,9 +209,11 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
}
exynos_fb = to_exynos_fb(fb);
- nr = exynos_drm_format_num_buffers(fb-pixel_format);
+ exynos_fb-buf_cnt = exynos_drm_format_num_buffers(mode_cmd);
+
+ DRM_DEBUG_KMS(buf_cnt = %d\n, exynos_fb-buf_cnt);
- for (i = 1; i nr; i++) {
+ for (i = 1; i exynos_fb-buf_cnt; i++) {
obj = drm_gem_object_lookup(dev, file_priv,
mode_cmd-handles[i]);
if (!obj) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h
Re: [PATCH 11/13] drm/exynos: changed context name of hdmi and mixer
On 08/20/2012 11:29 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch changes ctx variable name in exynos_drm_hdmi_context
structure to client because the use of ctx variable makes it confused.
I don't prefer client name. This is not client and server relationship.
Okay, give me your opinion. which one do you prefer?
Just data.
Thanks.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 38
+++---
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 12
drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 3fdf0b6..bced38e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-is_connected)
- return hdmi_ops-is_connected(ctx-hdmi_ctx-ctx);
+ return hdmi_ops-is_connected(ctx-hdmi_ctx-client);
return false;
}
@@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-get_edid)
- return hdmi_ops-get_edid(ctx-hdmi_ctx-ctx, connector,
edid,
- len);
+ return hdmi_ops-get_edid(ctx-hdmi_ctx-client,
connector,
+ edid, len);
return 0;
}
@@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev,
void *timing)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-check_timing)
- return hdmi_ops-check_timing(ctx-hdmi_ctx-ctx, timing);
+ return hdmi_ops-check_timing(ctx-hdmi_ctx-client,
timing);
return 0;
}
@@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev, int
mode)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-power_on)
- return hdmi_ops-power_on(ctx-hdmi_ctx-ctx, mode);
+ return hdmi_ops-power_on(ctx-hdmi_ctx-client, mode);
return 0;
}
@@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device
*subdrv_dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (mixer_ops mixer_ops-enable_vblank)
- return mixer_ops-enable_vblank(ctx-mixer_ctx-ctx,
+ return mixer_ops-enable_vblank(ctx-mixer_ctx-client,
manager-pipe);
return 0;
@@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct device
*subdrv_dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (mixer_ops mixer_ops-disable_vblank)
- return mixer_ops-disable_vblank(ctx-mixer_ctx-ctx);
+ return mixer_ops-disable_vblank(ctx-mixer_ctx-client);
}
static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
struct drm_connector *connector,
- const struct drm_display_mode *mode,
+ struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_hdmi_context *ctx = to_context(subdrv_dev);
@@ -150,7 +150,7 @@ static void drm_hdmi_mode_fixup(struct device
*subdrv_dev,
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-mode_fixup)
- hdmi_ops-mode_fixup(ctx-hdmi_ctx-ctx, connector, mode,
+ hdmi_ops-mode_fixup(ctx-hdmi_ctx-client, connector,
mode,
adjusted_mode);
}
@@ -161,7 +161,7 @@ static void drm_hdmi_mode_set(struct device
*subdrv_dev, void *mode)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-mode_set)
- hdmi_ops-mode_set(ctx-hdmi_ctx-ctx, mode);
+ hdmi_ops-mode_set(ctx-hdmi_ctx-client, mode);
}
static void drm_hdmi_get_max_resol(struct device *subdrv_dev,
@@ -172,7 +172,7 @@ static void drm_hdmi_get_max_resol(struct device
*subdrv_dev,
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-get_max_resol)
- hdmi_ops-get_max_resol(ctx-hdmi_ctx-ctx, width,
height);
+ hdmi_ops-get_max_resol(ctx-hdmi_ctx-client, width,
height);
}
static void drm_hdmi_commit(struct device *subdrv_dev)
@@ -182,7 +182,7 @@ static void drm_hdmi_commit(struct device *subdrv_dev)
DRM_DEBUG_KMS(%s\n, __FILE__);
if (hdmi_ops hdmi_ops-commit)
- hdmi_ops-commit(ctx-hdmi_ctx-ctx);
+ hdmi_ops-commit(ctx-hdmi_ctx-client);
}
static void drm_hdmi_dpms(struct
Re: [PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/20/2012 11:23 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd-handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
+++-
drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
4 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..2d1bc3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
* exynos specific framebuffer structure.
*
* @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
* @exynos_gem_obj: array of exynos specific gem object containing a
gem
object.
*/
struct exynos_drm_fb {
struct drm_framebuffer fb;
+ unsigned intbuf_cnt;
struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
};
@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
exynos_drm_fb_funcs = {
.dirty = exynos_drm_fb_dirty,
};
+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+ unsigned int cnt)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ exynos_fb-buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ return exynos_fb-buf_cnt;
+}
+
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return exynos_fb-fb;
}
+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
*mode_cmd)
+{
+ unsigned int cnt = 0;
+
+ if (mode_cmd-pixel_format == DRM_FORMAT_NV12MT)
+ return 2;
+
+ while (cnt != MAX_FB_BUFFER) {
+ if (!mode_cmd-handles[cnt])
+ break;
+ cnt++;
+ }
+
+ /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+ if (cnt == 2) {
+ /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+ if (mode_cmd-offsets[1]
+ mode_cmd-handles[0] == mode_cmd-handles[1])
+ cnt = 1;
+ }
+
+ return cnt;
+}
No, please don't add specific function. There is already
drm_format_num_planes() function
I know that, but NV12M format is specific to Exynos. for this, we
already had a discussion and you can refer to below link,
http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
Yes, but this implementation is not clear, just get plane number using
drm_format_num_planes()
and check handle and offset argument when format is NV12.
drm_format_num_planes() doesn't include NV12MT format type so first
that format should be added and then we can get plane count using
drm_format_num_planes if not NV12. but if not,
exynos_drm_format_num_buffers() like below,
if (mode_cmd == DRM_FORMAT_NV12)
+
static struct drm_framebuffer *
exynos_user_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
struct drm_mode_fb_cmd2 *mode_cmd)
@@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
struct exynos_drm_fb *exynos_fb;
- int nr;
int i;
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -152,9 +209,11 @@ exynos_user_fb_create(struct drm_device *dev,
struct
drm_file *file_priv,
}
exynos_fb = to_exynos_fb(fb);
- nr =
Re: 3.5.x boot hang after conflicting fb hw usage driver vs VESA VGA - removing generic driver
On 08/17/12 15:55, Dave Airlie wrote: On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie airl...@gmail.com wrote: On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap rdun...@xenotime.net wrote: On 08/17/2012 03:25 PM, Justin M. Forbes wrote: for driver, we have verified cases on inteldrmfb, radeondrmfb, and cirrusdrmfb. This is the last message displayed before the system hangs. This seems to be hitting a large number of users in Fedora, though certainly not everyone. This started happening with the 3.5 updates, and is still an issue. It appears to be a race condition, because various things have allowed boot to continue for some users, though there is no clear work around. Has anyone else run across this? Any ideas. For more background we have the following bugs: inteldrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=843826 radeondrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=845745 cirrusdrmfb kvm: https://bugzilla.redhat.com/show_bug.cgi?id=843860 It should be noted that the conflicting fb hw usage message is not new, it has been around for a while, but this is the last message seen before the hang. Hi, (adding dri-devel mailing list) I started seeing this problem on 3.5-rc6. AFAICT, the system is not actually hung, it's just that no output is showing up on the real (physical) output device (display) -- it's going somewhere else (or to the bit bucket). Can we bisect this at all? I guess I'll have to try again. My first attempt did not prove anything, I think because the conflict does not happen 100% of the time (i.e., it feels like a timing problem). I worry the intel one will bisect to where we moved the conflict resolution earlier, but I'd like to see if applying that patch earlier causes the issue, since radeon has it. Do you know of a specific commit that I could revert and test? I haven't reproduced this on any hw I own, I also can't get it under qemu. I'm also wondering whether this grub2 related in some way, grub2 is starting to mess with the graphics adapter pointlessly. Dave. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
sorry, again.
2012/8/20 InKi Dae inki@samsung.com:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/20/2012 11:23 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd-handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
+++-
drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
4 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..2d1bc3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
* exynos specific framebuffer structure.
*
* @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
* @exynos_gem_obj: array of exynos specific gem object containing a
gem
object.
*/
struct exynos_drm_fb {
struct drm_framebuffer fb;
+ unsigned intbuf_cnt;
struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
};
@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
exynos_drm_fb_funcs = {
.dirty = exynos_drm_fb_dirty,
};
+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+ unsigned int cnt)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ exynos_fb-buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ return exynos_fb-buf_cnt;
+}
+
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return exynos_fb-fb;
}
+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
*mode_cmd)
+{
+ unsigned int cnt = 0;
+
+ if (mode_cmd-pixel_format == DRM_FORMAT_NV12MT)
+ return 2;
+
+ while (cnt != MAX_FB_BUFFER) {
+ if (!mode_cmd-handles[cnt])
+ break;
+ cnt++;
+ }
+
+ /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+ if (cnt == 2) {
+ /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+ if (mode_cmd-offsets[1]
+ mode_cmd-handles[0] == mode_cmd-handles[1])
+ cnt = 1;
+ }
+
+ return cnt;
+}
No, please don't add specific function. There is already
drm_format_num_planes() function
I know that, but NV12M format is specific to Exynos. for this, we
already had a discussion and you can refer to below link,
http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
Yes, but this implementation is not clear, just get plane number using
drm_format_num_planes()
and check handle and offset argument when format is NV12.
drm_format_num_planes() doesn't include NV12MT format type so first
that format should be added and then we can get plane count using
drm_format_num_planes if not NV12. but if not,
exynos_drm_format_num_buffers() like below,
if (mode_cmd == DRM_FORMAT_NV12)
if (mode_cmd-pixel_format == DRM_FORMAT_NV12)
exynos_fb-buf_cnt = exynos_drm_format_num_buffers(dev, ...);
else
exynos_fb-buf_cnt = drm_format_num_planes();
+
static struct drm_framebuffer *
exynos_user_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
struct drm_mode_fb_cmd2 *mode_cmd)
@@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
struct exynos_drm_fb *exynos_fb;
- int nr;
Re: [PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
On 08/20/2012 02:15 PM, InKi Dae wrote:
sorry, again.
2012/8/20 InKi Dae inki@samsung.com:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/20/2012 11:23 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd-handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
+++-
drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
4 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..2d1bc3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
* exynos specific framebuffer structure.
*
* @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
* @exynos_gem_obj: array of exynos specific gem object containing a
gem
object.
*/
struct exynos_drm_fb {
struct drm_framebuffer fb;
+ unsigned intbuf_cnt;
struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
};
@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
exynos_drm_fb_funcs = {
.dirty = exynos_drm_fb_dirty,
};
+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+ unsigned int cnt)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ exynos_fb-buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ return exynos_fb-buf_cnt;
+}
+
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return exynos_fb-fb;
}
+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
*mode_cmd)
+{
+ unsigned int cnt = 0;
+
+ if (mode_cmd-pixel_format == DRM_FORMAT_NV12MT)
+ return 2;
+
+ while (cnt != MAX_FB_BUFFER) {
+ if (!mode_cmd-handles[cnt])
+ break;
+ cnt++;
+ }
+
+ /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+ if (cnt == 2) {
+ /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+ if (mode_cmd-offsets[1]
+ mode_cmd-handles[0] == mode_cmd-handles[1])
+ cnt = 1;
+ }
+
+ return cnt;
+}
No, please don't add specific function. There is already
drm_format_num_planes() function
I know that, but NV12M format is specific to Exynos. for this, we
already had a discussion and you can refer to below link,
http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
Yes, but this implementation is not clear, just get plane number using
drm_format_num_planes()
and check handle and offset argument when format is NV12.
drm_format_num_planes() doesn't include NV12MT format type so first
that format should be added and then we can get plane count using
drm_format_num_planes if not NV12. but if not,
exynos_drm_format_num_buffers() like below,
if (mode_cmd == DRM_FORMAT_NV12)
if (mode_cmd-pixel_format == DRM_FORMAT_NV12)
exynos_fb-buf_cnt = exynos_drm_format_num_buffers(dev, ...);
else
exynos_fb-buf_cnt = drm_format_num_planes();
I think that just reuse exynos_drm_format_num_buffers(), and call
drm_format_num_planes() and check NV12 format in that function.
+
static struct drm_framebuffer *
exynos_user_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
struct drm_mode_fb_cmd2 *mode_cmd)
@@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
struct drm_gem_object *obj;
Re: 3.5.x boot hang after conflicting fb hw usage driver vs VESA VGA - removing generic driver
On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap rdun...@xenotime.net wrote: On 08/17/12 15:55, Dave Airlie wrote: On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie airl...@gmail.com wrote: On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap rdun...@xenotime.net wrote: On 08/17/2012 03:25 PM, Justin M. Forbes wrote: for driver, we have verified cases on inteldrmfb, radeondrmfb, and cirrusdrmfb. This is the last message displayed before the system hangs. This seems to be hitting a large number of users in Fedora, though certainly not everyone. This started happening with the 3.5 updates, and is still an issue. It appears to be a race condition, because various things have allowed boot to continue for some users, though there is no clear work around. Has anyone else run across this? Any ideas. For more background we have the following bugs: inteldrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=843826 radeondrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=845745 cirrusdrmfb kvm: https://bugzilla.redhat.com/show_bug.cgi?id=843860 It should be noted that the conflicting fb hw usage message is not new, it has been around for a while, but this is the last message seen before the hang. Hi, (adding dri-devel mailing list) I started seeing this problem on 3.5-rc6. AFAICT, the system is not actually hung, it's just that no output is showing up on the real (physical) output device (display) -- it's going somewhere else (or to the bit bucket). Can we bisect this at all? I guess I'll have to try again. My first attempt did not prove anything, I think because the conflict does not happen 100% of the time (i.e., it feels like a timing problem). I worry the intel one will bisect to where we moved the conflict resolution earlier, but I'd like to see if applying that patch earlier causes the issue, since radeon has it. Do you know of a specific commit that I could revert and test? 9f846a16d213523fbe6daea17e20df6b8ac5a1e5 might work, but it just changes the timing mostly. also testing 3.4 with that on top would be good. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix checking of MSAA renderbuffers on r600-r700
Dear Marek, thank you for all your work on MSAA. Am Sonntag, den 19.08.2012, 21:23 +0200 schrieb Marek Olšák: Unfortunately you do not provide any commit message. What is the problem and what are the symptoms? When was it introduced? How is it solved in your patch? Signed-off-by: Marek Olšák mar...@gmail.com --- drivers/gpu/drm/radeon/r600_cs.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) Thanks, Paul signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/13] drm/exynos: separated subdrv-probe call and encoder/connector creation.
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/20/2012 01:31 PM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/20/2012 10:52 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch separates sub driver's probe call and encoder/connector
creation
so that exynos drm core module can take exception when some operation
was
failed properly.
Which exceptions? I don't know this patch gives any benefit to us.
previous code didn't take exception when exynos_drm_encoder_create()
is falied.
No, it is considered.
where is subdrv-remove() called when exynos_drm_encoder_create() is
failed? I think if failed then subdrv-remove() should be called and
if exynos_drm_connector_create() is failed then not only
encoder-funcs-destory() but also subdrv-remove()
OK, but just add subdrv-remove(). Then if it needs, please split function.
now exynos_drm_subdrv_probe() creates encoder and connector so it
should be separated into meaningful parts.
and for now, exynos_drm_encoder/connector_create functions
was called at exynos_drm_subdrv_probe() so know that this patch is for
code clean by separating them into two parts also.
It's ok, but it just splitting.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 93
+-
1 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..1c8d5fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,30 +34,15 @@
static LIST_HEAD(exynos_drm_subdrv_list);
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv
*subdrv)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
+ int ret;
DRM_DEBUG_DRIVER(%s\n, __FILE__);
- if (subdrv-probe) {
- int ret;
-
- /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by
load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for
modularization.
-*/
- ret = subdrv-probe(dev, subdrv-dev);
- if (ret)
- return ret;
- }
-
if (!subdrv-manager)
return 0;
@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct
drm_device
*dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR(failed to create connector\n);
- encoder-funcs-destroy(encoder);
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_destroy_encoder;
}
subdrv-encoder = encoder;
subdrv-connector = connector;
return 0;
+
+err_destroy_encoder:
+ encoder-funcs-destroy(encoder);
+ return ret;
}
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv
*subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv
*subdrv)
{
- DRM_DEBUG_DRIVER(%s\n, __FILE__);
-
- if (subdrv-remove)
- subdrv-remove(dev);
-
if (subdrv-encoder) {
struct drm_encoder *encoder = subdrv-encoder;
encoder-funcs-destroy(encoder);
@@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct
drm_device
*dev,
}
}
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+ struct exynos_drm_subdrv
*subdrv)
+{
+ if (subdrv-probe) {
+ int ret;
+
+ subdrv-drm_dev = dev;
+
+ /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by
load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for
modularization.
+*/
+ ret = subdrv-probe(dev, subdrv-dev);
+ if (ret)
+ return ret;
+ }
+
+ if (!subdrv-manager)
+ return -EINVAL;
+
+ subdrv-manager-dev = subdrv-dev;
+
+ return 0;
+}
+
+static void
Re: [PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/20/2012 02:15 PM, InKi Dae wrote:
sorry, again.
2012/8/20 InKi Dae inki@samsung.com:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/20/2012 11:23 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim jy0922.s...@samsung.com:
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb
structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd-handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 65
+++-
drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
4 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..2d1bc3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
* exynos specific framebuffer structure.
*
* @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
* @exynos_gem_obj: array of exynos specific gem object
containing a
gem
object.
*/
struct exynos_drm_fb {
struct drm_framebuffer fb;
+ unsigned intbuf_cnt;
struct exynos_drm_gem_obj
*exynos_gem_obj[MAX_FB_BUFFER];
};
@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs
exynos_drm_fb_funcs = {
.dirty = exynos_drm_fb_dirty,
};
+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+ unsigned int cnt)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ exynos_fb-buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ return exynos_fb-buf_cnt;
+}
+
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device
*dev,
return exynos_fb-fb;
}
+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2
*mode_cmd)
+{
+ unsigned int cnt = 0;
+
+ if (mode_cmd-pixel_format == DRM_FORMAT_NV12MT)
+ return 2;
+
+ while (cnt != MAX_FB_BUFFER) {
+ if (!mode_cmd-handles[cnt])
+ break;
+ cnt++;
+ }
+
+ /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+ if (cnt == 2) {
+ /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+ if (mode_cmd-offsets[1]
+ mode_cmd-handles[0] == mode_cmd-handles[1])
+ cnt = 1;
+ }
+
+ return cnt;
+}
No, please don't add specific function. There is already
drm_format_num_planes() function
I know that, but NV12M format is specific to Exynos. for this, we
already had a discussion and you can refer to below link,
http://web.archiveorange.com/archive/v/hhSc5JAv767vo7fKZLPf
Yes, but this implementation is not clear, just get plane number using
drm_format_num_planes()
and check handle and offset argument when format is NV12.
drm_format_num_planes() doesn't include NV12MT format type so first
that format should be added and then we can get plane count using
drm_format_num_planes if not NV12. but if not,
exynos_drm_format_num_buffers() like below,
if (mode_cmd == DRM_FORMAT_NV12)
if (mode_cmd-pixel_format == DRM_FORMAT_NV12)
exynos_fb-buf_cnt = exynos_drm_format_num_buffers(dev, ...);
else
exynos_fb-buf_cnt = drm_format_num_planes();
I think that just reuse exynos_drm_format_num_buffers(), and call
drm_format_num_planes() and check NV12 format in that function.
Okey~
+
static struct drm_framebuffer *
exynos_user_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
