On Tue, Mar 11, 2014 at 8:30 PM, Daniel Vetter
wrote:
> There's not really any value in stating that no locking is needed. And
> even if the comment is useful, a check for the right mutex at the
> beginning of the function is better since that can't be ingored as
> easily as a bit of
On Thu, Mar 20, 2014 at 3:31 AM, Daniel Vetter wrote:
> On Wed, Mar 19, 2014 at 10:26:13PM +0800, Daniel Kurtz wrote:
>> On Wed, Mar 19, 2014 at 7:51 PM, Daniel Vetter wrote:
>> > On Tue, Mar 18, 2014 at 05:22:49PM -0700, Matt Roper wrote:
>> >> Before we add additional types of planes to the
Hi Dave,
Just fixed resource release issue at open fail.
Thanks,
Inki Dae
The following changes since commit 27410e8248c64f5c6d28891389083b1022c15a10:
drm: Fix use-after-free in the shadow-attache exit code (2014-03-18 13:09:03
+1000)
are available in the git repository at:
e it helps.
--
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/20140320/275aed5c/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/fbd17939/attachment-0001.html>
Hi,
2014-03-19 9:22 GMT+09:00 Matt Roper :
> Add primary plane as a parameter to drm_crtc_init() and update all
> existing DRM drivers to use a helper-provided primary plane.
>
> v2: Update msm & omap drivers to use existing "private" planes as primary
> planes instead of helper [Rob Clark]
org/archives/dri-devel/attachments/20140320/f77dcb45/attachment-0001.html>
Thanks for your contributions,
2014-03-17 19:27 GMT+09:00 Andrzej Hajda :
> The patch replaces fimd private bindings for signal polarization by
> polarization flags provided by drm_display_mode.
>
This patch needs below patch not merged yet,
drm: drm_display_mode: add signal polarity flags
Hi!
On 03/17/2014 05:43 PM, David Herrmann wrote:
> We introduced render-nodes about 1/2 year ago and no problems showed up.
> Remove the drm_rnodes argument and enable them by default now.
So what about the malicious execbuf command stream problem? Do we
require all drivers that enable
On 03/20/2014 07:03 AM, Inki Dae wrote:
> Thanks for your contributions,
>
>
> 2014-03-17 19:27 GMT+09:00 Andrzej Hajda :
>> The patch replaces fimd private bindings for signal polarization by
>> polarization flags provided by drm_display_mode.
>>
>
> This patch needs below patch not merged
___
> 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/20140320/e78b48d3/attachment.html>
Hi
On Thu, Mar 20, 2014 at 7:43 AM, Thomas Hellstrom
wrote:
> On 03/17/2014 05:43 PM, David Herrmann wrote:
>> We introduced render-nodes about 1/2 year ago and no problems showed up.
>> Remove the drm_rnodes argument and enable them by default now.
>
> So what about the malicious execbuf
On Wed, Mar 19, 2014 at 08:15:05PM -0400, Nikolay Martynov wrote:
> Hi
>
> >
> > Perhaps you failed to install the modules that go with the kernel?
> I've built today's git version. The system boots but short after I
> log into X session system freezes.
>
> I can login via ssh and see dmesg:
Hi
On Thu, Mar 20, 2014 at 4:49 AM, Linus Torvalds
wrote:
> Is there really any use-case where the sealer isn't also the same
> thing that *created* the file in the first place? Because I would be a
> ton happier with the notion that you can only seal things that you
> yourself created. At that
On 03/20/2014 08:36 AM, David Herrmann wrote:
> Hi
>
> On Thu, Mar 20, 2014 at 7:43 AM, Thomas Hellstrom
> wrote:
>> On 03/17/2014 05:43 PM, David Herrmann wrote:
>>> We introduced render-nodes about 1/2 year ago and no problems showed up.
>>> Remove the drm_rnodes argument and enable them by
Hi Thomas
On Thu, Mar 20, 2014 at 9:48 AM, Thomas Hellstrom
wrote:
> I'm merely trying to envision the situation where a distro wants to
> create, for example an udev rule for the render nodes.
>
> How should the distro know that the implementation is not insecure?
>
> Historically drm has
The I2C address (reg) is required for the TDA998x driver to be loaded
and initialized.
Signed-off-by: Jean-Francois Moine
---
This patch applies to linux-next.
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
On 03/20/2014 10:05 AM, David Herrmann wrote:
> Hi Thomas
>
> On Thu, Mar 20, 2014 at 9:48 AM, Thomas Hellstrom
> wrote:
>> I'm merely trying to envision the situation where a distro wants to
>> create, for example an udev rule for the render nodes.
>>
>> How should the distro know that the
Hi
On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
wrote:
> A user logs in to a system where DRI clients use render nodes. The
> system grants rw permission on the render nodes for the console user.
> User starts editing a secret document, starts some GPGPU structural FEM
> computations of
On Mit, 2014-03-19 at 11:38 +0100, Daniel Vetter wrote:
> On Wed, Mar 19, 2014 at 05:42:27PM +0900, Michel D?nzer wrote:
> > On Die, 2014-03-18 at 11:01 +0100, Daniel Vetter wrote:
> > > On Tue, Mar 18, 2014 at 09:58:14AM +0900, Michel D?nzer wrote:
> > > > From: Michel D?nzer
> > > >
> > > >
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/52c58f37/attachment.html>
|--- |FIXED
--
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/20140320/d9b0fb98/attachment.html>
On 03/20/2014 10:43 AM, David Herrmann wrote:
> Hi
>
> On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
> wrote:
>> A user logs in to a system where DRI clients use render nodes. The
>> system grants rw permission on the render nodes for the console user.
>> User starts editing a secret
The same assignment has already been taken place before in the
drm_driver struct
Signed-off-by: Arthur Borsboom
---
drivers/gpu/drm/gma500/psb_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index b686e56..edb903b
Hi
On Thu, Mar 20, 2014 at 10:01 AM, Pavel Emelyanov
wrote:
> On 03/20/2014 12:47 PM, Cyrill Gorcunov wrote:
>> If I'm not mistaken in something obvious, this looks similar to
>> /proc/pid/map_files
>> feature, Pavel?
>
> It is, but the map_files will work "in the opposite direction" :) In the
On Sat, Mar 08, 2014 at 01:51:16PM +0530, sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> This patch creates a generic blending enum property.
> Drivers may support subset of these values.
>
> Cc: airlied at linux.ie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at
On Thu, Mar 20, 2014 at 01:32:24PM +0100, Sebastian Hesselbarth wrote:
> On 03/20/2014 09:58 AM, Jean-Francois Moine wrote:
>> The I2C address (reg) is required for the TDA998x driver to be loaded
>> and initialized.
>>
>> Signed-off-by: Jean-Francois Moine
>> ---
>> This patch applies to
On Thu, Mar 20, 2014 at 12:01 AM, Matt Roper
wrote:
> On Wed, Mar 19, 2014 at 01:24:23PM +0100, Daniel Vetter wrote:
>> On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
>> > When we expose non-overlay planes to userspace, they will become
>> > accessible via standard userspace plane
We have two calling contexts for thise function:
- In the crtc helper code itself as part of the ->set_config
implementation. In this calling context all modeset locks are
already held, as they should.
- In drivers not implementing fastboot before the fbdev/fbcon setup
and initialization.
The locking in drm_fb_helper_initial_config is a bit troublesome for a
few reasons:
- We can't just wrap the entire function up into modeset locks since
the fbdev registration might call down into fbcon code, which then
through our ->set_par implementation needs to be able to grab all
On Thu, 20 Mar 2014 13:32:24 +0100
Sebastian Hesselbarth wrote:
> > + - reg: I2C address - must be <0x70>
>
> TDA9983b datasheet says:
>
> "Bits A0 and A1 of the I2C-bus device address are externally selected
> by pins A0 and A1."
>
> Therefore, 0x70, 0x71, 0x72, and 0x73 are valid i2c
On Thu, Mar 20, 2014 at 02:01:21PM +0100, Daniel Vetter wrote:
> We have two calling contexts for thise function:
>
> - In the crtc helper code itself as part of the ->set_config
> implementation. In this calling context all modeset locks are
> already held, as they should.
>
> - In drivers
/gma_device.h
create mode 100644 drivers/gpu/drm/gma500/mmu.h
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/b8b7d5e3/attachment.html>
On Thu, 20 Mar 2014 14:01:56 +0100
Jean-Francois Moine wrote:
> For other boards using the TDA998x family, if the I2C address is
> different from 0x70, have you an idea about what can be the CEC I2C
> address? (this value is actually hard-coded in the TDA998x driver)
I had a look again on the
We have two calling contexts for thise function:
- In the crtc helper code itself as part of the ->set_config
implementation. In this calling context all modeset locks are
already held, as they should.
- In drivers not implementing fastboot before the fbdev/fbcon setup
and initialization.
On Thu, Mar 20, 2014 at 02:01:56PM +0100, Jean-Francois Moine wrote:
> On Thu, 20 Mar 2014 13:32:24 +0100
> Sebastian Hesselbarth wrote:
>
> > > + - reg: I2C address - must be <0x70>
> >
> > TDA9983b datasheet says:
> >
> > "Bits A0 and A1 of the I2C-bus device address are externally
The locking in drm_fb_helper_initial_config is a bit troublesome for a
few reasons:
- We can't just wrap the entire function up into modeset locks since
the fbdev registration might call down into fbcon code, which then
through our ->set_par implementation needs to be able to grab all
The patch adds polarization flags to fimd node.
It fixes parallel display support.
Signed-off-by: Andrzej Hajda
---
Hi Inki,
Since polarization patches were not merged, polarization
settings should be provided to fimd via properties.
This patch fixes it.
Regards
Andrzej
---
On Thu, Mar 20, 2014 at 02:26:34PM +0100, Daniel Vetter wrote:
> We have two calling contexts for thise function:
>
> - In the crtc helper code itself as part of the ->set_config
> implementation. In this calling context all modeset locks are
> already held, as they should.
>
> - In drivers
2014-03-20 3:46 GMT-04:00 Chris Wilson :
> On Wed, Mar 19, 2014 at 08:15:05PM -0400, Nikolay Martynov wrote:
>> Hi
>>
>> >
>> > Perhaps you failed to install the modules that go with the kernel?
>> I've built today's git version. The system boots but short after I
>> log into X session system
On Thu, Mar 20, 2014 at 09:38:17AM -0400, Nikolay Martynov wrote:
> (gdb) list *i915_gem_object_set_cache_level+0x8a
> 0x24e3a is in i915_gem_object_set_cache_level
> (drivers/gpu/drm/i915/i915_gem.c:3147).
> 3142 * crossing memory domains and dying.
> 3143 */
> 3144if
On Thu, 20 Mar 2014 14:32:18 +0100
Sebastian Hesselbarth wrote:
> Ok, I had another round of google'ing and found this:
> http://hipstercircuits.com/wp-content/uploads/2013/05/TDA19988.pdf
>
> There, the datasheet specifically for TDA19988 only states 0x70 and
> 0x34 as the two i2c addresses.
vel/attachments/20140320/b621b303/attachment.html>
On Sat, Mar 08, 2014 at 01:51:16PM +0530, sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> This patch creates a generic blending enum property.
> Drivers may support subset of these values.
>
> Cc: airlied at linux.ie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at
On Thu, Mar 20, 2014 at 02:52:21PM +0100, Jean-Francois Moine wrote:
> Thanks for the link.
>
> OK, then, as the linux tda998x driver handles only the tda 19988 and
> 19989 chips, the HDMI I2C address is always 0x70.
>
> So, question: Russell and Sebastian, do you still want an other patch?
>
>
On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote:
> On 03/20/2014 10:43 AM, David Herrmann wrote:
> > Hi
> >
> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
> > wrote:
> >> A user logs in to a system where DRI clients use render nodes. The
> >> system grants rw permission
On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse wrote:
> On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote:
>> On 03/20/2014 10:43 AM, David Herrmann wrote:
>> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
>> > wrote:
>> > Given that the legacy node is always around and
On 03/20/2014 03:36 PM, Jerome Glisse wrote:
>
> In any case this is not a render node issue and there is no reasons to force
> full VRAM eviction or anything like that.
This comment suggests you haven't read the discussion fully.
VRAM eviction was discussed in the context of legacy nodes.
This
On Thu, 20 Mar 2014 14:31:10 +
Russell King - ARM Linux wrote:
> 1. change the DT compatible strings the driver has to accept both
>nxp,tda19988 and nxp,tda19989, and set the appropriate device
>in the DT file (tda19988). I'm a bit nervous about using
>"nxp,tda1998x" in case
Hi
On Thu, Mar 20, 2014 at 3:41 PM, One Thousand Gnomes
wrote:
> I think you want two things at minimum
>
> owner to seal
> root can always override
Why should root be allowed to override?
> I would query the name too. Right now your assumption is 'shmem only' but
> that might change with
On Thu, Mar 20, 2014 at 9:59 AM, Jean-Francois Moine wrote:
> On Thu, 20 Mar 2014 14:31:10 +
> Russell King - ARM Linux wrote:
>
>> 1. change the DT compatible strings the driver has to accept both
>>nxp,tda19988 and nxp,tda19989, and set the appropriate device
>>in the DT file
On Thu, Mar 20, 2014 at 03:59:35PM +0100, Jean-Francois Moine wrote:
> On Thu, 20 Mar 2014 14:31:10 +
> Russell King - ARM Linux wrote:
>
> > 1. change the DT compatible strings the driver has to accept both
> >nxp,tda19988 and nxp,tda19989, and set the appropriate device
> >in the
On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Hi,
>
> This series adds libdrm-tegra with a very lightweight API on top of the
> kernel interfaces. Most of the functions provided here have been in use
> in various driver efforts in different incarnations. This
On Thu, Mar 20, 2014 at 03:59:17PM +0100, Thomas Hellstrom wrote:
> On 03/20/2014 03:36 PM, Jerome Glisse wrote:
> >
> > In any case this is not a render node issue and there is no reasons to force
> > full VRAM eviction or anything like that.
>
> This comment suggests you haven't read the
_CURSOR_WIDTH 64
> +#define GEN2_CURSOR_HEIGHT 64
> +#define CURSOR_WIDTH 256
> +#define CURSOR_HEIGHT 256
> +
> #define INTEL_I2C_BUS_DVO 1
> #define INTEL_I2C_BUS_SDVO 2
>
> @@ -364,6 +370,7 @@ struct intel_crtc {
> uint32_t cursor_addr;
> int16_t cursor_x, cursor_y;
> int16_t cursor_width, cursor_height;
> + int16_t max_cursor_width, max_cursor_height;
> bool cursor_visible;
>
> struct intel_crtc_config config;
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/e3620f4f/attachment.sig>
On Thu, Mar 20, 2014 at 09:56:24AM +0800, Daniel Kurtz wrote:
> On Thu, Mar 20, 2014 at 3:31 AM, Daniel Vetter wrote:
> > On Wed, Mar 19, 2014 at 10:26:13PM +0800, Daniel Kurtz wrote:
> >> On Wed, Mar 19, 2014 at 7:51 PM, Daniel Vetter wrote:
> >> > On Tue, Mar 18, 2014 at 05:22:49PM -0700, Matt
On Thu, Mar 20, 2014 at 10:44:10AM -0400, Ilia Mirkin wrote:
> On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse wrote:
> > On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote:
> >> On 03/20/2014 10:43 AM, David Herrmann wrote:
> >> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
On Thu, Mar 20, 2014 at 02:43:11PM +0900, Inki Dae wrote:
> Your patch would make kms requests to be broken. Exynos drm uses a
> wrapper structure, exynos_plane, including original drm_plane, and
> also a overlay object specific to exynos should be sent to crtc driver
> through exynos_plane.
>
>
_CURSOR_WIDTH 64
> +#define GEN2_CURSOR_HEIGHT 64
> +#define CURSOR_WIDTH 256
> +#define CURSOR_HEIGHT 256
> +
> #define INTEL_I2C_BUS_DVO 1
> #define INTEL_I2C_BUS_SDVO 2
>
> @@ -364,6 +370,7 @@ struct intel_crtc {
> uint32_t cursor_addr;
> int16_t cursor_x, cursor_y;
> int16_t cursor_width, cursor_height;
> + int16_t max_cursor_width, max_cursor_height;
> bool cursor_visible;
>
> struct intel_crtc_config config;
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/7c05d963/attachment.sig>
Hi
On Thu, Mar 20, 2014 at 4:32 PM, wrote:
> Why not make sealing an attribute of the "struct file", and enforce it
> at the VFS layer? That way all file system objects would have access
> to sealing interface, and for memfd_shmem, you can't get another
> struct file pointing at the object,
On 03/20/2014 04:34 PM, Jerome Glisse wrote:
> On Thu, Mar 20, 2014 at 03:59:17PM +0100, Thomas Hellstrom wrote:
>> On 03/20/2014 03:36 PM, Jerome Glisse wrote:
>>> In any case this is not a render node issue and there is no reasons to force
>>> full VRAM eviction or anything like that.
>> This
On Thu, 20 Mar 2014 15:19:34 +
Russell King - ARM Linux wrote:
> I'm not saying that it has to match the physical device fitted - I'm
> merely suggesting not using nxp,tda1998x which could (and as Sebastian
> has found, does) conflict with other devices with different properties.
>
> We
On Wed, Mar 19, 2014 at 08:06:45PM +0100, David Herrmann wrote:
>
> This series introduces the concept of "file sealing". Sealing a file restricts
> the set of allowed operations on the file in question. Multiple seals are
> defined and each seal will cause a different set of operations to return
On Thu, Mar 20, 2014 at 04:54:40PM +0100, Jean-Francois Moine wrote:
> On Thu, 20 Mar 2014 15:19:34 +
> Russell King - ARM Linux wrote:
>
> > I'm not saying that it has to match the physical device fitted - I'm
> > merely suggesting not using nxp,tda1998x which could (and as Sebastian
> >
On Thu, Mar 20, 2014 at 05:30:43PM +0200, Imre Deak wrote:
> On Mon, 2014-03-10 at 17:06 +0530, sagar.a.kamble at intel.com wrote:
> > From: Sagar Kamble
> >
> > With this patch we allow larger cursor planes of sizes 128x128
> > and 256x256.
> >
> > v2: Added more precise check on size while
On Thu, Mar 20, 2014 at 04:48:30PM +0100, David Herrmann wrote:
> On Thu, Mar 20, 2014 at 4:32 PM, wrote:
> > Why not make sealing an attribute of the "struct file", and enforce it
> > at the VFS layer? That way all file system objects would have access
> > to sealing interface, and for
On Thu, Mar 20, 2014 at 04:49:42PM +0100, Thomas Hellstrom wrote:
> On 03/20/2014 04:34 PM, Jerome Glisse wrote:
> > On Thu, Mar 20, 2014 at 03:59:17PM +0100, Thomas Hellstrom wrote:
> >> On 03/20/2014 03:36 PM, Jerome Glisse wrote:
> >>> In any case this is not a render node issue and there is no
The I2C address (reg) is required for the TDA998x driver to be loaded
and initialized.
Signed-off-by: Jean-Francois Moine
---
- v2
- don't force the I2C address to be 0x70
This patch applies to linux-next.
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 2 ++
1 file changed,
Mainly styling fixes of inline documentation
Signed-off-by: Arthur Borsboom
---
drivers/gpu/drm/gma500/framebuffer.c | 36 ++--
drivers/gpu/drm/gma500/psb_intel_display.c | 35 ++--
drivers/gpu/drm/gma500/psb_intel_reg.h | 259 +
Removed line return in the middle of function argument list.
Signed-off-by: Arthur Borsboom
---
drivers/gpu/drm/gma500/psb_intel_display.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
The tda998x driver accepts 3 chips only from the TDA998x family.
This patch changes the driver to accept only these chips.
Signed-off-by: Jean-Francois Moine
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 4 ++--
drivers/gpu/drm/i2c/tda998x_drv.c | 4 +++-
2
On Thu, Mar 20, 2014 at 6:28 AM, Thomas Hellstrom
wrote:
> On 03/20/2014 10:43 AM, David Herrmann wrote:
>> Hi
>>
>> On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
>> wrote:
>>> A user logs in to a system where DRI clients use render nodes. The
>>> system grants rw permission on the render
On Thu, Mar 20, 2014 at 10:44 AM, Ilia Mirkin wrote:
> On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse wrote:
>> On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote:
>>> On 03/20/2014 10:43 AM, David Herrmann wrote:
>>> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
>>> >
On 03/19/2014 12:06 PM, David Herrmann wrote:
> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
> that you can pass to mmap(). It explicitly allows sealing and
> avoids any connection to user-visible mount-points. Thus, it's not
> subject to quotas on mounted
On 03/20/2014 06:34 PM, Rob Clark wrote:
> On Thu, Mar 20, 2014 at 6:28 AM, Thomas Hellstrom
> wrote:
>> On 03/20/2014 10:43 AM, David Herrmann wrote:
>>> Hi
>>>
>>> On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
>>> wrote:
A user logs in to a system where DRI clients use render nodes.
On Thu, Mar 20, 2014 at 4:54 PM, Thomas Hellstrom
wrote:
> On 03/20/2014 06:34 PM, Rob Clark wrote:
>> On Thu, Mar 20, 2014 at 6:28 AM, Thomas Hellstrom
>> wrote:
>>> On 03/20/2014 10:43 AM, David Herrmann wrote:
Hi
On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
wrote:
On Thu, Mar 20, 2014 at 05:56:20PM +0100, Peter Senna Tschudin wrote:
> When Fedora updated the Kernel package from 3.12 to 3.13 my notebook
> stopped booting (Kernel freezes) when a 2560 x 1440 high res monitor
> is attached. I have tried using 3.13.6 from kernel.org and the problem
> persists.
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/20140320/3adb21cd/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/dcd09d0b/attachment.html>
to gang together two planes for a given configuration, the
HWC HAL's prepare() op will already know to set aside that extra plane and
plan accordingly.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/43734f08/attachment.html>
o real issues (it didn't boot all the way
because the config doesn't include a driver for my root disk, but
that's to be expected).
The dmesg you supplied is for some other commit 2d18516 that I don't
have, so I'm confused about why it's not from aa11fc58dc.
I did reproduce what appears to be
2014-03-20 9:43 GMT-04:00 Chris Wilson :
> On Thu, Mar 20, 2014 at 09:38:17AM -0400, Nikolay Martynov wrote:
>> (gdb) list *i915_gem_object_set_cache_level+0x8a
>> 0x24e3a is in i915_gem_object_set_cache_level
>> (drivers/gpu/drm/i915/i915_gem.c:3147).
>> 3142 * crossing memory domains and
On Wed, Mar 19, 2014 at 08:06:48PM +0100, David Herrmann wrote:
> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
> that you can pass to mmap(). It explicitly allows sealing and
> avoids any connection to user-visible mount-points. Thus, it's not
> subject to quotas on
On 03/20/2014 03:29 PM, David Herrmann wrote:
> Hi
>
> On Thu, Mar 20, 2014 at 10:01 AM, Pavel Emelyanov
> wrote:
>> On 03/20/2014 12:47 PM, Cyrill Gorcunov wrote:
>>> If I'm not mistaken in something obvious, this looks similar to
>>> /proc/pid/map_files
>>> feature, Pavel?
>>
>> It is, but
On 03/20/2014 09:58 AM, Jean-Francois Moine wrote:
> The I2C address (reg) is required for the TDA998x driver to be loaded
> and initialized.
>
> Signed-off-by: Jean-Francois Moine
> ---
> This patch applies to linux-next.
> ---
> Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 2 ++
>
On 03/20/2014 02:01 PM, Jean-Francois Moine wrote:
> On Thu, 20 Mar 2014 13:32:24 +0100
> Sebastian Hesselbarth wrote:
>
>>> + - reg: I2C address - must be <0x70>
>>
>> TDA9983b datasheet says:
>>
>> "Bits A0 and A1 of the I2C-bus device address are externally selected
>> by pins A0 and A1."
>>
On 03/20/2014 02:52 PM, Jean-Francois Moine wrote:
> On Thu, 20 Mar 2014 14:32:18 +0100
> Sebastian Hesselbarth wrote:
>
>> Ok, I had another round of google'ing and found this:
>> http://hipstercircuits.com/wp-content/uploads/2013/05/TDA19988.pdf
>>
>> There, the datasheet specifically for
> My first idea was to add MFD_ALLOW_SEALING as memfd_create() flag,
> which enables the sealing-API for that file. Then I looked at POSIX
This actually seems the most sensible to me. The reason being that if I
have some existing used object there is no way on earth I can be sure who
has existing
On Thu, 20 Mar 2014 16:12:54 +0100
David Herrmann wrote:
> Hi
>
> On Thu, Mar 20, 2014 at 3:41 PM, One Thousand Gnomes
> wrote:
> > I think you want two things at minimum
> >
> > owner to seal
> > root can always override
>
> Why should root be allowed to override?
Because root can already
On 03/20/2014 12:47 PM, Cyrill Gorcunov wrote:
> On Wed, Mar 19, 2014 at 08:06:48PM +0100, David Herrmann wrote:
>> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
>> that you can pass to mmap(). It explicitly allows sealing and
>> avoids any connection to user-visible
On Thu, 20 Mar 2014 11:32:51 -0400
tytso at mit.edu wrote:
> On Wed, Mar 19, 2014 at 08:06:45PM +0100, David Herrmann wrote:
> >
> > This series introduces the concept of "file sealing". Sealing a file
> > restricts
> > the set of allowed operations on the file in question. Multiple seals are
>
When Fedora updated the Kernel package from 3.12 to 3.13 my notebook
stopped booting (Kernel freezes) when a 2560 x 1440 high res monitor
is attached. I have tried using 3.13.6 from kernel.org and the problem
persists. The problem can be partially solved by passing nomodeset to
Kernel which will
On Thu, Mar 20, 2014 at 6:34 PM, 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
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/6a575a62/attachment-0002.bin>
-- next part --
00:00.0 Host
94 matches
Mail list logo
