ing 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/87481c1d/attachment-0001.html>
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. Th
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.
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/dcd09d0b/attachment.html>
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/3adb21cd/attachment.html>
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 different
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
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 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
> > > >
> > > > ent
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 file
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,
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
b/drivers/gpu/drm/gma500/psb_intel_display.
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 +
drivers/gpu/drm/gma500/psb
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 ma
sizes */
> +#define GEN2_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>
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 set
sizes */
> +#define GEN2_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 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, 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 stil
ed it on qemu with no 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 a
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 com
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, the
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.
>
> A
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 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 i
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
> > has
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 other
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 we'r
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 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 th
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
>
he display
controller needs 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>
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 ov
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 TDA199
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 DT
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
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. Th
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]
>
> 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 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 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?
>
>
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
---
arch/arm/boot/dts/e
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
modese
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. T
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 td
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 vger
44 drivers/gpu/drm/gma500/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 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 addr
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
modese
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. T
ri-devel/attachments/20140320/b621b303/attachment.html>
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 (HAS_
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 AP
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
>>> > wrot
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 n
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 n
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 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 selecte
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 n
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
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 mo
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 mo
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 memfd_sh
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 linux-ne
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 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 file-systems
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 10064
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 vger
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:
git://git.
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 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 discuss
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 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 documentatio
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 document
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 _alw
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 th
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
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 imple
|--- |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>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/52c58f37/attachment.html>
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 (tda19
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 refus
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 a/Documentation/devicetree
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 DRM
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 def
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 fre
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 p
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 comman
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 yet,
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 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
render-no
org/archives/dri-devel/attachments/20140320/f77dcb45/attachment-0001.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140320/fbd17939/attachment-0001.html>
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>
;
> ___
> 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>
95 matches
Mail list logo
