On Wed, Mar 26, 2014 at 09:40:18PM +0100, Thomas Hellstrom wrote:
> On 03/26/2014 08:08 PM, David Herrmann wrote:
> > "struct_mutex" is used to serialize all entry-points into
> > the drm-device (and thus the driver) and also, often implicitly, as
> > spin-lock for "struct drm_device" data protecti
On Wed, Mar 26, 2014 at 10:33 PM, Greg Hackmann wrote:
> On Wed, Mar 26, 2014 at 3:08 AM, Daniel Vetter wrote:
>>
>> - You have an explicit callback for vblank events (well, just the
>> interrupt, afaics no support to get a vblank event for a specific frame
>> in the future). Any reason not t
gt; impossible for someone to interfere with it then,
>
> Dave.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/9b98a32b/attachment-0001.html>
On 03/26/2014 08:08 PM, David Herrmann wrote:
> Hi
>
> On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom
> wrote:
>> The master management was previously protected by the
>> drm_device::struct_mutex.
>> In order to avoid locking order violations in a reworked dropped master
>> security check in
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/27fe2547/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/c3482feb/attachment.html>
ferent
> crtc/connectors attached to them, with an X server running on that node,
> that is independent of X server running on other nodes maybe,
>
> Dave.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/abf230bc/attachment.html>
, right? Using it isn't actually relying on xorg to function.
--
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/20140326/
Hi
On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom
wrote:
> The master management was previously protected by the
> drm_device::struct_mutex.
> In order to avoid locking order violations in a reworked dropped master
> security check in the vmwgfx driver, break it out into a separate
> master
Hi
On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom
wrote:
> Like for render-nodes, there is no point in maintaining the master concept
> for control nodes, so set the struct drm_file::master pointer to NULL.
>
> At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always
> all
Hi
On Tue, Mar 25, 2014 at 2:18 PM, Thomas Hellstrom
wrote:
> Add a drm_is_legacy() helper, constify argument to drm_is_render_client(),
> and use / change helpers where appropriate.
>
> v2: s/drm_is_legacy/drm_is_legacy_client/ and adapt to new code context.
Could we avoid using "legacy" for t
There appear to be a crop of new hardware where the vbios is not
available from PROM/PRAMIN, but there is a valid _ROM method in ACPI.
The data read from PCIROM almost invariably contains invalid
instructions (still has the x86 opcodes), which makes this a low-risk
way to try to obtain a valid vbio
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/23339f08/attachment.html>
Hi Jean-Fran?ois,
On Tuesday 25 March 2014 16:55:48 Jean-Francois Moine wrote:
> On Mon, 24 Mar 2014 23:39:01 +0100 Laurent Pinchart wrote:
> > On Friday 21 March 2014 09:17:32 Jean-Francois Moine wrote:
> > > The 'slave encoder' structure of the tda998x driver asks for glue
> > > between the DRM
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/8c54d5ea/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140326/b9bee745/attachment.html>
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/20140326/5c51ba9d/attachment.html>
Hi Lucas,
On Mon, Mar 24, 2014 at 10:19 PM, Lucas Stach wrote:
> Hi Alexandre,
>
> Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot:
>> Hi everyone,
> [...]
>>
>> A few lines of hacks (not included here) are still needed to deal with cached
>> mappings triggering external aborts a
Am 26.03.2014 14:03, schrieb Alex Deucher:
> On Wed, Mar 26, 2014 at 7:04 AM, Christian K?nig
> wrote:
>> From: Christian K?nig
>>
>> If the IB test fails we don't want to reset the card over
>> and over again, just accept that it isn't working.
>>
>> Signed-off-by: Christian K?nig
>> Cc: stable
On Thu, Mar 13, 2014 at 12:05 PM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
Already said on IRC, but for posterity:
Reviewed-by: Ben Skeggs
> ---
> nouveau/nouveau.c | 29 -
> nouveau/private.h | 3 ++-
> 2 files changed, 30 insertions(+), 2 deletions(-)
>
>
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/57872928/attachment.html>
On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot
wrote:
> Set the correct subdev/engine classes when GK20A (0xea) is probed.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --
On Tue, Mar 25, 2014 at 9:10 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:33PM +0900, Alexandre Courbot wrote:
>> GK20A does not embed a dedicated COPY engine and thus cannot allocate
>> the copy channel that nouveau_accel_init() attempts to create. It also
>> lacks any display hardwa
On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot
wrote:
> Add a GR device for GK20A based on NVE4, with the correct classes
> definitions (GK20A's 3D class is 0xa297).
>
> Most of the NVE4 code can be used on GK20A, so make relevant bits of
> NVE4 available to other chips as well.
This will nee
On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot
wrote:
> Pad the microcode to a multiple of 0x40, otherwise firmware will fail to
> run from non-prepadded firmware files.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4
> 1 file changed,
On Tue, Mar 25, 2014 at 8:58 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:30PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> index 6ef8bf181b2d..f997a18f5760 100644
>>
hardware constraints are
too different from SoC to SoC for that to scale.
That said, I'd be happy to be proven wrong -- if the hypothetical atomic2
ioctl has a kernel counterpart that I'm comfortable recommending to
vendors, being able to write a single generic HWC HAL would be good for
A
On Tue, Mar 25, 2014 at 8:13 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:25PM +0900, Alexandre Courbot wrote:
>> Some chips that use system memory exclusively (e.g. GK20A) do not
>> expose 2 BAR regions. For them only BAR1 exists, and it should be used
>> for USERD mapping. Do not ma
On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>> GK20A's timer is directly attached to the system timer and cannot be
>> calibrated. Skip the calibration phase on that chip since the
>> corresponding registers do not exi
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140326/a35c534f/attachment.html>
went away.
--
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/20140326/028c7fa6/attachment-0001.html>
From: Dave Airlie
This should ensure we don't hit a locking problem when someone
wakes us up via a connector, we should never go into suspend
while the display is on anyways.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 12 +---
1 file changed, 5 insertions(+)
From: Dave Airlie
If we were on a non-optimus device, we'd return -EINVAL, this would
lead to the over engineered runtime pm system to go into an error
state, subsequent get_sync's would fail, so we'd never be able
to open the device again.
(like really get_sync shouldn't fail if the device isn'
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/6b086c01/attachment.html>
Hi
On Tue, Mar 25, 2014 at 1:25 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Commit 62ff94a54921 "drm/crtc-helper: remove LOCKING from kerneldoc"
> causes drm_helper_crtc_in_use() and drm_helper_encoder_in_use() to
> complain loudly during a kernel panic or sysrq processing. This is
> ca
Hi
On Tue, Mar 25, 2014 at 3:32 PM, wrote:
> From: Sagar Kamble
>
> v2: Added description for "src-color" and "constant-alpha" property.
>
> Cc: Rob Landley
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: David Herrmann
> Cc: Alex Deucher
> Cc: "Ville Syrj?l?"
> Cc: Sa
From: Christian K?nig
If the IB test fails we don't want to reset the card over
and over again, just accept that it isn't working.
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_ring.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/g
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140326/ca9bc6bb/attachment.html>
Hi Alexandre,
Am Mittwoch, den 26.03.2014, 15:33 +0900 schrieb Alexandre Courbot:
> Hi Lucas,
>
> On Mon, Mar 24, 2014 at 10:19 PM, Lucas Stach
> wrote:
> > Hi Alexandre,
> >
> > Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot:
> >> Hi everyone,
> > [...]
> >>
> >> A few lines
On Thu, Mar 20, 2014 at 03:34:19PM -0700, Greg Hackmann wrote:
> On Wed, Mar 19, 2014 at 5:23 AM, Rob Clark wrote:
>
> > > Hm, do you have some pointers to read up on this? I still think a more
> > > elaborate fail scheme is overkill, but maybe reading a bit of android
> > code
> > > convinces me
On Wed, Mar 26, 2014 at 9:50 AM, Christian K?nig
wrote:
> Am 26.03.2014 14:03, schrieb Alex Deucher:
>
>> On Wed, Mar 26, 2014 at 7:04 AM, Christian K?nig
>> wrote:
>>>
>>> From: Christian K?nig
>>>
>>> If the IB test fails we don't want to reset the card over
>>> and over again, just accept tha
I'd want for this. If you need any help,
please let me know.
Thanks,
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/20140326/8b9d4745/attachment.sig>
The patch adds LD9040 parallel RGB panel driver with SPI control interface.
The driver uses drm_panel framework.
Signed-off-by: Andrzej Hajda
---
v2: removed useless include
v3: added SPI dependency to Kconfig
---
drivers/gpu/drm/panel/Kconfig| 7 +
drivers/gpu/drm/panel/Makefile
On Wed, Mar 26, 2014 at 12:09 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> If we were on a non-optimus device, we'd return -EINVAL, this would
> lead to the over engineered runtime pm system to go into an error
> state, subsequent get_sync's would fail, so we'd never be able
> to open the devic
On Wed, Mar 26, 2014 at 7:04 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> If the IB test fails we don't want to reset the card over
> and over again, just accept that it isn't working.
>
> Signed-off-by: Christian K?nig
> Cc: stable at vger.kernel.org
You might want to add the link to
On Tue, Mar 25, 2014 at 06:42:13PM -0400, Mikulas Patocka wrote:
>
>
> On Mon, 24 Mar 2014, Daniel Vetter wrote:
>
> > >> Like I've said the entire teardown sequence for legacy drm drivers is
> > >> terminally busted, so the only hope we have is to reapply this missing
> > >> duct-tape which mad
On Tue, Mar 25, 2014 at 2:52 PM, Daniel Drake wrote:
> Hi Sean,
>
> In your commit "drm/exynos: hdmi: support extra resolutions using
> drm_display_mode timings" you added several more HDMI PHY configs to
> exynos-drm. Thanks for that.
>
> Can you explain where these magic numbers came from?
>
H
https://bugzilla.kernel.org/show_bug.cgi?id=22312
--- Comment #10 from Alex Deucher ---
If you are running a 3.13 or newer kernel, try appending radeon.runpm=0 to the
kernel command line in grub.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=22312
--- Comment #9 from Alex Deucher ---
(In reply to Chris Nystrom from comment #8)
> Yes. I am having this exact error message with a live Fedora 20 DVD on a
> Dell OptiPlex 780 with a PCIe ASUS Radeon R7 240 video card. The desktop
> never comes up
49 matches
Mail list logo