https://bugs.freedesktop.org/show_bug.cgi?id=67982
--- Comment #7 from Kertesz Laszlo ---
With 3.12 rc3 and now rc4 kernels this bug seemso to be gone and replaced with
its opposite - the APU never reaches its maximum voltage (1.34) even under full
load (4 threads compiling) instead it stays at m
https://bugs.freedesktop.org/show_bug.cgi?id=67800
Kertesz Laszlo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=67107
Adam Honse changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
> static int exynos_drm_create_enc_conn(struct drm_device *dev,
> - struct exynos_drm_subdrv *subdrv)
> + struct exynos_drm_display *display)
> {
> struct drm_encoder *encoder;
> struct drm_connector *conn
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> The gr2d hardware in Tegra114 is compatible with that of Tegra20 and
> Tegra30. No functionaly changes are required.
Similarly here, if the HW is 100% backwards-compatible, there's no need
to add compatible values to the driver.
_
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> This commit adds support for both DSI outputs found on Tegra. Only very
> minimal functionality is implemented, so advanced features like ganged
> mode won't work.
>
> Due to the lack of other test hardware, some sections of the driver are
> hardcode
https://bugs.freedesktop.org/show_bug.cgi?id=67107
--- Comment #17 from Adam Honse ---
That kernel worked for getting Xorg to not crash, and GNOME 3.10 is working
smoothly. Now my problem is that with radeon.dpm=1 set, GNOME running, if I
try to play Team Fortress 2 it crashes right as it should
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> This driver adds support to perform calibration of the MIPI pads for CSI
> and DSI.
> diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
> +int tegra_mipi_calibrate(struct device *device)
...
> + err = of_parse_phandle_with_args(
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> Add a driver for simple panels. Such panels can have a regulator that
> provides the supply voltage and a separate GPIO to enable the panel.
> Optionally the panels can have a backlight associated with them so it
> can be enabled or disabled according
On 10/11/2013 04:19 PM, Stephen Warren wrote:
> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>> From: Mikko Perttunen
>>
>> Tegra114 TMDS configuration requires a new peak_current field and the
>> driver current override bit has changed position.
>
>> diff --git a/drivers/gpu/drm/tegra/hdmi.c b/
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> From: Mikko Perttunen
>
> Tegra114 TMDS configuration requires a new peak_current field and the
> driver current override bit has changed position.
> diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
> static const struct t
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> From: Mikko Perttunen
>
> The Tegra114 display controller is backwards-compatible with previous
> generations of the Tegra SoC. No code changes are required.
If the HW is backwards-compatible, then there's no need to add extra
compatible values to
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> Tegra114 uses a slightly updated version of host1x with an additional
> syncpoint.
> drivers/gpu/host1x/hw/host1x02.c| 42 +
> drivers/gpu/host1x/hw/host1x02.h| 26 +++
> drivers/gpu/host1x/hw/hw_host1x02_channel.h | 12
On 10/07/2013 02:34 AM, Thierry Reding wrote:
> In order to subsystem-wide changes easier, move the Tegra DRM driver
^^ make ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> This is my preferred method of fixing it as I don't think the lifetimes need
>> to be tied so closely, though this requires review my someone to make sure
>> my unregistering etc is correct and in the right place.
>
> Apparently this fixes the problem for Fengguang, and the code looks
> clean
On Fri, Oct 11, 2013 at 01:53:36PM +0800, Lee, Chon Ming wrote:
> On 10/09 09:18, Daniel Vetter wrote:
> > Boots Just Fine (tm)!
> >
> > The only glitch seems to be that at least on Fedora the boot splash
> > gets confused and doesn't display much at all.
> >
> > And since there's no ugly console
On Tue, Oct 08, 2013 at 12:52:53PM -0400, Rob Clark wrote:
> On Tue, Oct 8, 2013 at 11:44 AM, Daniel Vetter wrote:
> > For drivers which might want to disable fbdev legacy support.
> >
> > Select the new option in all drivers for now, so this shouldn't result
> > in any change. Drivers need some w
https://bugs.freedesktop.org/show_bug.cgi?id=70391
Jose P. changed:
What|Removed |Added
Attachment #87489|text/plain |application/zip
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=70391
--- Comment #1 from Jose P. ---
Sorry, I meant, I can poweroff the machine.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedes
https://bugs.freedesktop.org/show_bug.cgi?id=70391
Priority: medium
Bug ID: 70391
Assignee: dri-devel@lists.freedesktop.org
Summary: "atombios stuck executing D1FC" when switching back
from tty to X
Severity: normal
Class
Damien Lespiau writes:
> Hi,
>
> Would anyone be opposed to bumping the version number of libdrm right
> after a release? That would allow us to be able to depend on new APIs
> that are not yet in a released libdrm.
People should just release libdrm when they need a new API out of it.
pgpakQM6
https://bugs.freedesktop.org/show_bug.cgi?id=70385
Priority: medium
Bug ID: 70385
Assignee: dri-devel@lists.freedesktop.org
Summary: r600 glamor high X cpu usage and lag on some gtk2
applications
Severity: normal
Classifi
On Thu, Oct 10, 2013 at 10:28 PM, Dave Airlie wrote:
>
> and one pain in the ass revert, so we have VGA arbitration that when
> implemented 4-5 years ago really hoped that GPUs could remove themselves
> from arbitration completely once they had a kernel driver, it seems Intel
> hw designers decide
Hi,
Would anyone be opposed to bumping the version number of libdrm right
after a release? That would allow us to be able to depend on new APIs
that are not yet in a released libdrm.
--
Damien
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Thu, Oct 10, 2013 at 10:05 PM, Dave Airlie wrote:
>
> This is my preferred method of fixing it as I don't think the lifetimes need
> to be tied so closely, though this requires review my someone to make sure
> my unregistering etc is correct and in the right place.
Apparently this fixes the pr
On Fri, Oct 11, 2013 at 12:33 AM, Ilia Mirkin wrote:
> I was just looking at
> https://bugs.freedesktop.org/show_bug.cgi?id=20341 (see last comment).
> Basically he's able to to use the card with agpmode=2 but not the
> auto-detected agpmode=4. I also saw that the radeon driver has a large
> quirk
https://bugs.freedesktop.org/show_bug.cgi?id=41756
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=44647
--- Comment #1 from Sven Arvidsson ---
Still a problem with Wine 1.7.3 and Mesa 9.2.1.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@li
On Thu, Oct 10, 2013 at 02:19:15PM +0100, Thomas Wood wrote:
> + if ((multi_present == 1 || multi_present == 2) &&
You could use the awesome binary literals gcc extension here and 0b01
and 0b10 to be even closer to the spec wording.
There's a precedent in drivers/watchdog/sunxi_wdt.c!
--
Da
https://bugs.freedesktop.org/show_bug.cgi?id=68503
Grigori Goronzy changed:
What|Removed |Added
Attachment #85013|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=69942
fritz...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
This far we have used the remap_pfn_range() function directly to
map buffers to user space. Calling this function has worked as all
memory allocations have been contiguous. However, the function must
support also non-contiguous memory allocations as we later want to
turn on IOMMU.
This patch modif
On Fri, Oct 11, 2013 at 02:12:14PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 10, 2013 at 02:19:15PM +0100, Thomas Wood wrote:
> > +static int add_3d_struct_modes(struct drm_connector *connector, u16
> > structure,
> > + const u8 *video_db, u8 video_len, u8 video_index)
> >
On 10/11/2013 12:39 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Wed, Oct 09, 2013 at 02:54:08PM +0300, Arto Merilainen wrote:
This patch adds support for hardware syncpoint bases. This creates
a simple mechanism for waiting an operation to complete in the middle
of the command b
On Thu, 10 Oct 2013, Fred New wrote:
> I have found that I need to use i915.invert_brightness=1 for my HP
> Envy 17 with a Haswell processor (i7-4702MQ). The lspci command shows
> the following information about this device:
I am surprised... until recently [1] we've only seen this on gen4 Acer
b
On Thu, Oct 10, 2013 at 02:19:15PM +0100, Thomas Wood wrote:
> Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
> Specific Data Block to expose more stereo 3D modes.
>
> Signed-off-by: Thomas Wood
> ---
> drivers/gpu/drm/drm_edid.c | 93
>
https://bugs.freedesktop.org/show_bug.cgi?id=70176
dennisrid...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 10/11/2013 12:43 PM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Wed, Oct 09, 2013 at 02:54:09PM +0300, Arto Merilainen wrote:
This patch makes the necessary additions to deliver syncpoint base
to the user space.
This patch splits the index field in the drm_tegra_get_syncpt stru
On Thu, 3 Oct 2013, Daniel Vetter wrote:
> Can you please attach full dmesg from boot up to the first WARN with
> drm.debug=0xe? This really shouldn't happen and indicates a bug
> somewhere ...
OK, I haven't been able to reproduce this any more for ~week ... so please
disregard this, and I'll re
DRM driver for (virtual) vga cards using the bochs dispi interface,
such as the qemu standard vga (qemu -vga std).
Don't bother supporting anything but 32bpp for now.
Maybe add 16bpp later on.
Known issue: mmap(/dev/fb0) doesn't work.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/Kconfig
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_kms.c | 10 +++---
drivers/gpu/drm/qxl/qxl_ttm.c | 2 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index e0ddd5b..e5ca498 100644
--- a/drivers/gpu/drm/q
So they show up in /proc/{iomem,ioports}.
No error checking (yet?). Doesn't make things
worse than they are now, but still not nice.
Known issue: Doesn't work for qxl-vram (vesafb conflict?).
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_kms.c | 6 ++
1 file changed, 6 insertio
Explicitly set 1024x768 as default mode, so the display doesn't come up
with the largest supported mode.
While being at it drop first three drm_add_modes_noedid calls. As
drm_add_modes_noedid fills the mode list with modes from the database
*up to* the specified size it is pretty pointless to cal
qxl devices can have a 64bit surface bar, which is quite handy if
you need a bit more surface memory. So try to use it if it is
present. Note that this bar might be mapped above 4g.
QEMU command line to check that out:
qemu-system-x86_64 -m 4g \
-vga qxl -global qxl-vga.vram64_size_
New helper function to set the preferred video mode. Can be called
after drm_add_modes_noedid if you don't want the largest supported
video mode be used by default.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_edid.c | 13 +
include/drm/drm_crtc.h | 2 ++
2 files change
Hi,
Here comes a collection of drm patches for qemu emulated
virtual graphics cards. Small improvements for cirrus
and qxl. A new kms driver for the qemu standard vga.
Patches 1-4 can be queued up for merge, unless someone
finds bugs / problems in review of course.
Patches 5+6 have known iss
On 09/10/13 17:08, Andrzej Hajda wrote:
> As I have adopted existing internal driver for MIPI-DSI bus, I did not
> take too much
> care for DT. You are right, 'bta-timeout' is a configuration parameter
> (however its
> minimal value is determined by characteristic of the DSI-slave). On the
> other
On 10/09 09:18, Daniel Vetter wrote:
> Boots Just Fine (tm)!
>
> The only glitch seems to be that at least on Fedora the boot splash
> gets confused and doesn't display much at all.
>
> And since there's no ugly console flickering anymore in between, the
> flicker while switching between X server
On 10/10/2013 08:59 PM, Rafael J. Wysocki wrote:
> On Thursday, October 10, 2013 09:02:55 AM Aaron Lu wrote:
>> On 10/10/2013 08:29 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, October 08, 2013 02:40:00 PM Aaron Lu wrote:
According to Matthew Garrett, "Windows 8 leaves backlight control up
>>>
On Thu, Oct 10, 2013 at 06:23:26PM -0400, Rob Clark wrote:
> On Thu, Oct 10, 2013 at 5:59 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Oct 10, 2013 at 05:25:15PM -0400, Rob Clark wrote:
> >> probably this thread is applicable here too?
> >>
> >> https://lkml.org/lkml/2013/9/12/417
> >>
> >> (
On Thu, Oct 10, 2013 at 05:25:15PM -0400, Rob Clark wrote:
> On Sun, Oct 6, 2013 at 6:08 PM, Russell King
> wrote:
> > + /*
> > +* If we have an overlay plane associated with this CRTC, disable
> > +* it before the modeset to avoid its coordinates being outside
> > +*
HI,
I have found that I need to use i915.invert_brightness=1 for my HP
Envy 17 with a Haswell processor (i7-4702MQ). The lspci command shows
the following information about this device:
$ lspci -v -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core
Processor Integrated Gr
From: Meelis Roos
Date: Thu, 10 Oct 2013 18:26:39 +0300 (EEST)
>> On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos wrote:
>> > To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
>> > from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
>> > detection to move on
Today's linux-next merge of the drm-intel tree got additional conflicts
in drivers/gpu/drm/i915/intel_drv.h as a result of interactions between
6aba5b6cf098 (drm/i915/dp: get rid of intel_dp->link_configuration) and
various commits from Paulo Zanoni staticising functions. I've fixed up
by changing
On Thu, Oct 10, 2013 at 08:40:38PM +0900, Inki Dae wrote:
> That is what I mentioned. Some boards _could control_ the actual regulator
> for lvds-bridge, and that would be depended on how HW engineer designs the
> board.
For the driver this should be totally transparent - it should just
control
On Thu, Oct 10, 2013 at 01:18:05PM +0900, Inki Dae wrote:
> > > I still think the pin could be replaced with a regulator. But
> > > lvds-bridge node has "powerdown-gpio" property - it say this board
> > > will use gpio pin - specific to board. So it seems no problem.
> > No, don't model things t
There are no mutex protection for the dev->map_hash while calling
the drm_ht_find_item in the function drm_do_vm_fault. So try to
mutex firstly and then find the list for using to avoid this race
condition.
Signed-off-by: Chen Jun
---
drivers/gpu/drm/drm_vm.c | 11 +--
1 files changed
On 10/07/2013 12:47 PM, Bert Kenward wrote:
> On Tuesday September 24 2013 at 15:23, Andrzej Hajda wrote:
>> MIPI DSI is a high-speed serial interface to transmit
>> data from/to host to display module.
>>
>> Signed-off-by: Andrzej Hajda
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/video/di
On Wed, Oct 09, 2013 at 02:54:07PM +0300, Arto Merilainen wrote:
> The host1x driver uses currently syncpoints statically from host1x point of
> view. If we do a wait inside a job, it always has a constant value to wait.
> host1x supports also doing relative syncpoint waits with respect to syncpoin
On Wed, Oct 09, 2013 at 02:54:09PM +0300, Arto Merilainen wrote:
> This patch makes the necessary additions to deliver syncpoint base
> to the user space.
>
> This patch splits the index field in the drm_tegra_get_syncpt structure
> into three separate fields (index, support_base, base_id). This a
On Wed, Oct 09, 2013 at 02:54:08PM +0300, Arto Merilainen wrote:
> This patch adds support for hardware syncpoint bases. This creates
> a simple mechanism for waiting an operation to complete in the middle
> of the command buffer.
Perhaps "... simple mechanism to stall the command FIFO until an
op
https://bugzilla.kernel.org/show_bug.cgi?id=60639
--- Comment #15 from kerns...@schreib-doch-mal-wieder.de ---
Patch didn't work. :-(
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel
On Fri, Oct 11, 2013 at 11:05:00AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> So GNOME userspace has an issue with when it rescans for modes on hotplug
> events, if the monitor has no EDID it assumes that nothing has changed on
> EDID as with real hw we'd never have new modes without a new
Hi Philipp,
On 10/10/2013 10:18 PM, Philipp Zabel wrote:
> Connecting a 320x240 parallel display on i.MX6 resulted in an invalid DRDY
> signal because the DC would not receive NL/EOL events on every line.
> Reducing the allocated DMFC space from 4 slots (256 * 128-bit) to 2 slots
> (128 * 128-bit)
64 matches
Mail list logo
