use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/8f220403/attachment.html>
ations.
> >
> > I have a plan to implement the CPU interface relevant APIs like video
> > mode ones, but I think they should be used under current DRM mode APIs
> > like fill_modes, get_modes and so on.
> > So after that implementation, this private field will be replaced by
> > new ones.
> >
> > Could you explain it in more detail?
>
> The idea is that the interface parameters (RD/WR signals timings in this
> case,
> but this could also include MIPI DSI lane configuration or any other kind of
> physical interface parameters) are distinct from the video modes.
We already have the lanes field in struct mipi_dsi_device. I think in
general I'd prefer to not spread these parameters around too wildly. If
this is a general requirement for DBI devices, perhaps what we need is
struct mipi_dbi_device?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/218162f0/attachment.sig>
On Thu, Apr 10, 2014 at 7:20 PM, Erik Faye-Lund wrote:
> On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
> wrote:
>> From: Thierry Reding
>>
>> This test opens a device, dumps the version information and checks that
>> a Tegra DRM context can be opened on it.
>>
>> Signed-off-by: Thierry Reding
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> This library provides helpers for common functionality needed by test
> programs.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - fix a couple of memory leaks and get rid of some unneeded code
>
> tes
Hi,
This is a first review, from someone who's clearly not a DRM/KMS expert
but who already thought about this specific driver :-).
I strongly recommend that you wait for DRM/KMS maintainers and/or
experienced developers reviews before modifying anything ;-).
On 18/04/2014 11:45, Jean-Jacques
u 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/20140428/fdf53ef2/attachment.html>
r/llvm/log/?h=si-spill-fixes-v2
--
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/20140428/e2108bd6/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/c2c136ba/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/17df4afe/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/463afd5b/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/49e2a2d7/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/6b62a688/attachment.html>
Daniel,
On Sun, Apr 27, 2014 at 6:25 PM, Daniel Vetter wrote:
> On Fri, Apr 25, 2014 at 8:17 AM, Ajay kumar wrote:
>> We can call panel_enable/disable at the right point. Even the bridge chips
>> expect the same. So, I am not ok with combining the bridge and panel and
>> calling the fxn pointers
Hi
On Mon, Apr 28, 2014 at 4:23 PM, Ilija Hadzic
wrote:
> inode argument is no longer in use (cf. f4aede2e3).
> Remove it.
>
> Signed-off-by: Ilija Hadzic
> Cc: David Herrmann
Reviewed-by: David Herrmann
Thanks
David
Hi YoungJun,
On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
> On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
> > Hi YoungJun,
> >
> > Thank you for the patch.
> >
> > On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
> >> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD
Am 28.04.2014 15:40, schrieb Leo Liu:
> Signed-off-by: Leo Liu
> Cc:stable at vger.kernel.org
There should be a space between the "CC:" and "stable at vger.kernel.org"
> ---
> drivers/gpu/drm/radeon/radeon_uvd.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/rad
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140428/3547b893/attachment-0002.obj>
-- next part --
A non-text attachment was scrubbed...
Name: dmesg-wq
Type: application/octet-stream
Size: 82461 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/arc
On Mon, Apr 28, 2014 at 11:19:29AM +0800, Aaron Lu wrote:
> When we set backlight on behalf of ACPI opregion, we will convert the
> backlight value in the 0-255 range defined in opregion to the actual
> hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow
> when doing scale) is me
On Mon, Apr 28, 2014 at 03:03:23PM +0200, Jan Moskyto Matejka wrote:
> This reverts commit 60f2b4af1258c05e6b037af866be81abc24438f7.
>
> The same warning has been fixed in e5081a538a565284fec5f30a937d98e460d5e780
> and
> these two commits got merged in 74e99a84de2d0980320612db8015ba606af42114 whi
OTC Commit: 426729dcc713b3d1ae802e314030e5556a62da53
Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
("drm/i915: create compact dma scatter lists for gem objects") makes
certain assumptions about the under laying DMA API that are not always
correct.
On a ThinkPad X230 with an Intel HD 4000 wi
Hi Dave,
drm-intel-next-2014-04-16:
- vlv infoframe fixes from Jesse
- dsi/mipi fixes from Shobhit
- gen8 pageflip fixes for LRI/SRM from Damien
- cmd parser fixes from Brad Volkin
- some prep patches for CHV, DRRS, ...
- and tons of little things all over
drm-intel-next-2014-04-04:
- cmd parser f
This reverts commit 60f2b4af1258c05e6b037af866be81abc24438f7.
The same warning has been fixed in e5081a538a565284fec5f30a937d98e460d5e780 and
these two commits got merged in 74e99a84de2d0980320612db8015ba606af42114 which
caused another warning. Simply, the reverted commit casted the pointer
differ
talyst, so
how can I help?
--
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/20140428/cbc6094a/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/643db8fa/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=74751
--- Comment #9 from Tasev Nikola ---
Hi,
I just tried now 3.15-rc3, the bug is still there.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Dear maintainers/reviewers, just an UP to remind you that this
patcheset is waiting for your feedback.
Patches 1-12 and 18-19 mainly concern drivers for the various hardware IP.
Patches 13-16 add debug to those drivers.
Patches 17 is the DRM driver.
I know that review 10K lines isn't easy, takes
>
> page_to_phys()/phys_to_page() can be used by drivers and will work
> just fine here since the CPU and GPU use the same physical addresses
> to access memory.
I'm wondering how this is going to pan out when we try adding IOMMU
support. But I guess we can cross that bridge when we come to it.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/e952897e/attachment.sig>
> -Original Message-
> From: Deucher, Alexander
> Sent: Monday, April 28, 2014 8:50 AM
> To: Koenig, Christian; Jerome Glisse; Thomas Schwinge
> Cc: Bjorn Helgaas; linux-pci at vger.kernel.org; Johannes Weiner; Mel Gorman;
> Rik van Riel; Andrea Arcangeli; Zlatko Calusic; Minchan Kim; linux
> -Original Message-
> From: Koenig, Christian
> Sent: Monday, April 28, 2014 3:30 AM
> To: Jerome Glisse; Thomas Schwinge
> Cc: Bjorn Helgaas; linux-pci at vger.kernel.org; Johannes Weiner; Mel Gorman;
> Rik van Riel; Andrea Arcangeli; Zlatko Calusic; Minchan Kim; linux-
> mm at kvack.org;
On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot
wrote:
> nvc0_graph_ctor() would only let the graphics engine be enabled if its
> oclass has a proper microcode linked to it. This prevents GR from being
> enabled at all on chips that rely exclusively on external firmware, even
> though such a u
n main of
/home/flo/flightgear-unstable/flightgear/flightgear-3.0.0/src/Main/bootstrap.cxx:278
Thanks in advance to anyone helping resolve this issue!
--
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/20140428/cc1e4684/attachment.html>
When we set backlight on behalf of ACPI opregion, we will convert the
backlight value in the 0-255 range defined in opregion to the actual
hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow
when doing scale) is meant to fix the overflow problem when doing the
conversion, but it
ater use in
drivers/gpu/drm/ttm/ttm_bo.c:ttm_bo_add_ttm, I assume. With that hack
applied, I have now rebooted a v3.14 build a few times, and so far things
"look" fine.
diff --git drivers/gpu/drm/radeon/radeon_device.c
drivers/gpu/drm/radeon/radeon_device.c
index 044bc98..90baf2f 100644
--- drivers/gpu/drm/radeon/radeon_device.c
+++ drivers/gpu/drm/radeon/radeon_device.c
@@ -1243,6 +1243,8 @@ int radeon_device_init(struct radeon_device *rdev,
rdev->need_dma32 = true;
dma_bits = rdev->need_dma32 ? 32 : 40;
+ dma_bits = 32;
+ rdev->need_dma32 = true;
r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
rdev->need_dma32 = true;
Gr??e,
Thomas
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/81e38fba/attachment-0001.sig>
On Mon, Apr 28, 2014 at 4:17 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Some RV7xx generation hardware crashes after you
> raise the UVD clocks for the first time. Try to
> avoid this by using the lower clocks to boot these.
>
> Workaround for: https://bugzilla.kernel.org/show_bug.cgi
From: Christian K?nig
Testing the update pending bit directly after issuing an
update is nonsense cause depending on the pixel clock the
CRTC needs a bit of time to execute the flip even when we
are in the VBLANK period.
This is just a non invasive patch to solve the problem at
hand, a more comp
inode argument is no longer in use (cf. f4aede2e3).
Remove it.
Signed-off-by: Ilija Hadzic
Cc: David Herrmann
---
drivers/gpu/drm/drm_fops.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index a0ce39c..78a181
On Fri, Apr 25, 2014 at 4:34 AM, Daniel Thompson
wrote:
> The 800x600 (SVGA) screen resolution was lacking in the set of
> built-in selectable EDID screen resolutions that can be used to
> repair misbehaving monitor firmware.
>
> This patch adds the related data set and expands the documentation.
https://bugzilla.kernel.org/show_bug.cgi?id=74911
--- Comment #4 from Ivan Bulatovic ---
[0.779800] ATOM BIOS: C63101
[0.779862] radeon :01:00.0: VRAM: 2048M 0x -
0x7FFF (2048M used)
[0.779867] radeon :01:00.0: GTT: 1024M 0x8000 -
0x
On Thu, Apr 24, 2014 at 7:29 AM, Maarten Lankhorst
wrote:
> It would appear this bug has been copy/pasted many times without being
> noticed.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Alex Deucher
> ---
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index
On Wed, Apr 23, 2014 at 2:49 AM, Mathias Fr?hlich
wrote:
>
> Hi Christian, Alex,
>
> While looking over the rest of the ring counts
> I noticed an other one, this time we reserve too
> much which cannot even be a potential problem.
> Anyway, it's nicer to be correct.
>
> Attached that patch to uvd
From: Christian K?nig
Some RV7xx generation hardware crashes after you
raise the UVD clocks for the first time. Try to
avoid this by using the lower clocks to boot these.
Workaround for: https://bugzilla.kernel.org/show_bug.cgi?id=71891
v2: lower clocks on IB test as well
Signed-off-by: Christ
signature
Size: 489 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/f01b3bbe/attachment-0001.sig>
> > > > > >TAbort- SERR- > > > > Kernel driver in use: amd64_edac
> > > > >
> > > > > 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] K8
> > > > > [Athlon64/Opteron] Miscellaneous Control
https://bugzilla.kernel.org/show_bug.cgi?id=74911
--- Comment #3 from Ivan Bulatovic ---
Apologies, it opts out after a minute just like you've said it would.
[0.793366] [drm] Loading PITCAIRN Microcode
[0.793478] radeon :01:00.0: Direct firmware load failed with error -2
[0.7934
Signed-off-by: Leo Liu
Cc:stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_uvd.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 5748bda..0f96c47 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
++
https://bugzilla.kernel.org/show_bug.cgi?id=74911
--- Comment #2 from Ivan Bulatovic ---
> How long have you waited for? Trying to load a non-existent firmware file
> may only time out after a minute or so.
I've left it once for a while, but I'll test for how long and report back,
seems to me it
> + /* We are living in a monstruous world in which you can have the pci
> + * root complex behind an hypertransport link which can not address
> + * anything above 32bit (well hypertransport specification says 40bits
> + * but hardware such as SIS761 only support 32bits).
That l
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/d9817f35/attachment.html>
next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/936133ac/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=74911
--- Comment #1 from Michel D?nzer ---
(In reply to Ivan Bulatovic from comment #0)
> After booting 3.15.0-rc2 kernel, I can only see a message from grub
> indicating that kernel and initram images are loaded and that's it. No
> response from keybo
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140428/87a75171/attachment-0001.html>
/0BxO6THtB865fMHpKb204ZUVRTGM/edit?usp=sharing
--
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/20140428/7a6f7cd1/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=74631
Lan Tianyu changed:
What|Removed |Added
Status|NEW |NEEDINFO
CC|
53 matches
Mail list logo
