Already declared in our public header freedreno_drmif.h
Cc: Rob Clark
Cc: freedreno at lists.freedesktop.org
Signed-off-by: Emil Velikov
---
freedreno/freedreno_priv.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/freedreno/freedreno_priv.h b/freedreno/freedreno_priv.h
index 6bd1dec..41
This patch works on my hardware. Xorg starts up fine with fbdev now.
Thanks for the fix!
--G?nther
Daniel Kurtz writes:
> Commit [0] stopped setting fix.smem_start and fix.smem_len when creating
> the fbdev.
>
> [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3
> drm/exynos/fbdev: don't set fix.
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
Remove the left-over #ifndef check that will allways match since
the corresponding arch-specific define is gone with above patch.
Signed-off-by: Bruno Pr?mont
CC: Matthew Garrett
---
No funda
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
For dual-GPU Apple computers above change represents a regression as
code in efifb did forcefully override vga_default_device while the
merge did not (vgaarb happens prior to PCI fixup).
To impr
Commit [0] stopped setting fix.smem_start and fix.smem_len when creating
the fbdev.
[0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3
drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}
However, smem_len is used by some userland applications to calculate the
size for mmap. In particular, it is us
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/9609d870/attachment.html>
22.8.2014 13.38 kirjoitti "David Herrmann" :
>
> Hi
>
> On Thu, Aug 21, 2014 at 8:18 PM, Tommi Rantala
> wrote:
> > Hello,
> >
> > Triggered this while fuzzing v3.17-rc1-51-g372b1db with Trinity.
> >
> > Tommi
> >
> >
> > [drm:drm_mode_legacy_fb_format] *ERROR* bad bpp, assuming x8r8g8b8 pixel
>
Hi Tim,
Gave the series another try, and there was some minor issues caused by commit
5d8357976a8 (configure: Support symbol visibility when available). Did not see
any of the originally mentioned issues. Are you sure that you've tried it on
top of fd.o/drm/master ?
Do you have any comments, woul
Will be used to consolidate the required sources lists as well as the
install-able headers. This is turn will help us to avoid the
duplication with the upcoming Android build support.
v2: Rename the headers variable to *_H_FILES.
v3: Rebase on top of symbol visibility patches.
Signed-off-by: Emil
Kinda unexpected, but DIV_ROUND_UP() can overflow if passed an argument
bigger than UINT_MAX - DIVISOR. Fix this by testing for "!cpp" before
using it in the following division.
Note that DIV_ROUND_UP() is defined as:
#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
..this will obviously
Hi
On Sun, Aug 24, 2014 at 7:12 PM, Tommi Rantala wrote:
> (gdb) info locals
> cpp = 0
> stride = 0
> size =
>
> (gdb) print /x *(struct drm_mode_create_dumb *)data
> $13 = {
> height = 0x,
> width = 0x,
> bpp = 0x,
> flags = 0x,
> handle = 0x,
>
-devel/attachments/20140824/36464a75/attachment.html>
On Sun, Aug 24, 2014 at 1:23 PM, David Herrmann
wrote:
> Kinda unexpected, but DIV_ROUND_UP() can overflow if passed an argument
> bigger than UINT_MAX - DIVISOR. Fix this by testing for "!cpp" before
> using it in the following division.
>
> Note that DIV_ROUND_UP() is defined as:
> #def
From: Christian K?nig
Activating the UVD support.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_uvd.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 1c1e569..fab6a1
From: Christian K?nig
Only the essentials, cause this hw generation is really buggy.
v2: start supporting RV670,RV620 and RV635 as well
v3: activate more workarounds
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r600d.h| 3 +++
drivers/gpu/drm/radeon/uvd_v1_0.c | 26 +
From: Christian K?nig
v2: cleanup R600 support
v3: rebased on current drm-fixes-3.12
v4: rebased on drm-next-3.14
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r600.c| 31 +++
drivers/gpu/drm/radeon/r600d.h | 8
drivers/gpu/drm/radeon/radeon_asic.c |
From: Alex Deucher
v2: wake up PLL, set [VD]CLK_SRC, cleanup code
v3: handle RV670,RV635,RV620 as well
v4: merge rv6xx and rs780/rs880 code, fix ref divider mask
Signed-off-by: Alex Deucher
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r600.c | 88
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r600.c | 4
drivers/gpu/drm/radeon/r600d.h | 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index c70a504..0e58d5c 100644
--
From: Christian K?nig
v2: only necessary on RS[78]80
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 1321491..c91d8c
Hello everyone,
the following patches add UVD support for older ASICs (RV6xx, RS[78]80,
RV7[79]0). For everybody wanting to test it I've also uploaded a branch to FDO:
http://cgit.freedesktop.org/~deathsimple/linux/log/?h=uvd-r600-release
Additionally to the patches you need UVD firmware as wel
From: Christian K?nig
Otherwise we won't test if the fallback to PCIe GART really worked.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_device.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/
based laptop it seems to work perfectly fine.
>
> Happy testing,
> Christian.
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/ed04d510/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/c3c07bed/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/d0cae9d4/attachment.html>
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/901dc97e/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140824/e9ef3882/attachment.html>
Hi all,
according to you request I would like to report that my Lenovo IdeaPad
y510p requires i915.invert_brightness=1 parameter to not dim screen
right after booting. I'm using 3.17.0-rc1.
PCI device ID, subsystem vendor and subsystem device ID data:
[12:39:34] pietrushnic:~ $ lspci -s 00:02.0
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140824/3c90bd30/attachment.html>
/archives/dri-devel/attachments/20140824/e5080ba2/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/22f9aa02/attachment.html>
yes I'm willing to open a new bug for this.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/119cd86b/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140824/c6e3614f/attachment.html>
Hi Linus,
post KS/LC git requests from i915 and radeon stacked up, they are all
fixes along with some new pci ids for radeon, and one maintainers file
entry.
i915: display fixes and irq fixes
radeon: pci ids, and misc gpuvm, dpm and hdp cache
Dave.
The following changes since commit 7d1311b
https://bugzilla.kernel.org/show_bug.cgi?id=78221
--- Comment #18 from t3st3r at mail.ru ---
This is getting even more interesting. After some investigation I got idea why
bisect never succeeds. It looks like there was no stable kernels at all: 3.15
is also broken. However it takes "almost forever
34 matches
Mail list logo