On Mon, 22 Aug 2016 09:29:17 +0200
Daniel Vetter wrote:
> On Sun, Aug 21, 2016 at 08:39:38PM +0200, Heinrich Schuchardt wrote:
> > Components m1, m2, p2, dot, vco of variable clock should be
> > initialized to avoid bytes from the kernel stack to be
> > exposed.
> >
> > Signed-off-by: Heinrich
> firmware framebuffer in early boot until a real driver takes over. It's a
> replacement really for all the various uefi/vesa/whatever fbdev drivers.
> Full reliance on the firmware very much intended.
Most of those have firmware interfaces for things like colour setting and
hardware scrolling.
On Tue, 12 Jul 2016 16:41:58 -0300
Ezequiel Garcia wrote:
> Hi Alan,
>
> (Adding interested people to this thread)
>
> On 09 Apr 08:14 PM, One Thousand Gnomes wrote:
> > > > I do feel that the importance of the mentioned bug is currently
> > > > underesti
On Tue, 22 Mar 2016 16:40:18 -0700
Joe Perches wrote:
> On Tue, 2016-03-22 at 22:49 +, Colin King wrote:
> > From: Colin Ian King
> >
> > There is a missing comma between two strings in the dsi_errors[]
> > array initializer, causing two strings to be concatenated and the
> > array being
qxl_execbuffer_ioctl copies a qxl_command from user space into a kernel
buffer and then runs qxl_process_single_command. This then does
reloc_info = kmalloc(sizeof(struct qxl_reloc_info) * cmd->relocs_num,
which since cmd->relocs_num is 32bit can overflow on a 32bit machine. This
then
> > > But a better look has me wondering how all these gpus are syncing
> > > the framebuffer for direct access via cfb_imageblit and friends. I only
> > > see
> > > nouveau and intel gma even trying.
> >
> > Probably no other DRM driver uses hardware acceleration for fbcon.
>
> Yup. We've
On Thu, 28 Jan 2016 19:05:16 -0500
Insu Yun wrote:
> Since drm_property_create_range can be failed in memory pressure,
> it needs to be handled.
>
> Signed-off-by: Insu Yun
> ---
> drivers/gpu/drm/gma500/framebuffer.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
> dma-buf user handles are fds, which means anything allocated can be passed
> around nicely already. The question really is whether we'll have one ioctl
> on top of a special dev node or a syscall. I thought that in these cases
> where the dev node is only ever used to allocate the real thing, a
On Thu, 7 May 2015 15:52:12 +0200
Daniel Vetter wrote:
> On Thu, May 07, 2015 at 03:22:20PM +0200, Thierry Reding wrote:
> > On Wed, May 06, 2015 at 03:15:32PM +0200, Daniel Vetter wrote:
> > > Yes the idea would be a special-purpose allocater thing like ion. Might
> > > even want that to be a
> First what is Secure Data Path ? SDP is a set of hardware features to garanty
> that some memories regions could only be read and/or write by specific
> hardware
> IPs. You can imagine it as a kind of memory firewall which grant/revoke
> accesses to memory per devices. Firewall configuration
> It's not about virtio at all. It's about vga compatibility, so we have
> a simple framebuffer as boot display. Only used when virtio is *not*
> enabled.
VGA can be a separate device altogether.
In fact there were *real* PCI graphics cards that did this and had a
register than flipped the
> Yes, with video=LVDS-1:d boot parameter, kernel boots fine and there is
> graphics/video output on the screen, with the following message from kernel
> when loading gma500_gfx:
>
> [6.472859] [drm] forcing LVDS-1 connector OFF
>
> (and a few others).
>
> There's one funky thing still --
On Thu, 19 Mar 2015 14:09:29 +0300
Michael Tokarev wrote:
> Half a year passed since my first email in this thread, and current kernels
> (4.0-tobe) still does not work properly. Meanwhile, I found this thread:
>
On Sat, 28 Feb 2015 18:02:33 +0300
Alexey Khoroshilov wrote:
> gma_power_begin() starts with locking power_ctrl_lock spinlock and then,
> if gma_resume_pci(dev->pdev) succeed, it calls
> psb_irq_preinstall(dev);
> psb_irq_postinstall(dev);
>
> psb_irq_postinstall() does some pipestat
On Mon, 9 Feb 2015 11:00:55 +
Daniel Stone wrote:
> On 9 February 2015 at 10:49, Geert Uytterhoeven
> wrote:
> > On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone
> > wrote:
> >> On 5 February 2015 at 11:35, One Thousand Gnomes
>
> If I'm not mistaken, that would be as simple as adding
>
> #define VT_BUF_HAVE_RW.
> #define scr_writew(val, addr) (*(addr) = (val))
> #define scr_readw(addr) (*(addr))
>
> to arch/x86/include/asm/vga.h.
and stick an
#if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
#endif
around
On Thu, 29 Jan 2015 15:40:33 -0800
Linus Torvalds wrote:
> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie wrote:
> >
> > Linus, this came up a while back I finally got some confirmation
> > that it fixes those servers.
>
> I'm certainly ok with this. which way should it go in? The users are:
>
On Wed, 22 Oct 2014 18:48:21 +0200
SF Markus Elfring wrote:
> >> If you are convinced that dropping the null tests is a good idea, then you
> >> can submit the patch that makes the change to the relevant maintainers and
> >> mailing lists.
>
> Would you like to integrate the following
> What if someone doesn't know about that intention one day and inserts
> some field in the structure at the "wrong place" ?
Then we have code review. Also they are much more likely to simply change
the code elsewhere and break it. Nobody afaik ever got this wrong, while
the litany of other
On Sun, 14 Sep 2014 18:40:13 +0200
Fabian Frederick wrote:
> Small patchset using container_of instead of casting on first structure
> member address.
Why. Container_of is useful for random offsets but its just convoluting
and confusing code which is designed with the fields intentionally at
On Tue, 5 Aug 2014 08:27:16 +0200
Thierry Reding wrote:
> From: Thierry Reding
>
> The GMA500 driver redefines many constants already found in the generic
> header. Replace uses of the custom defines by the standard ones and get
> rid of the duplicate defininitions.
>
> Signed-off-by:
> Imo trying to fix the current mess and making ->set_config work in
> atomic contexts is pointless. drm_can_sleep is trying to make that
> possible in some ways, and it's horrible since using it means
> busy-loops in atomic contexts outside of panic handlers won't get
> reported any more. Also
> throw out all GPU memory on master drop and block ioctls requiring
> authentication until master becomes active again.
If you have a per driver method then the driver can implement whatever is
optimal (possibly including throwing it all out).
> -1: The driver allows an authenticated client to
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
>
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 allo
> 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
> - The renderer supports *any* RGB target, from 8bit to 32bit with
>big-endian and little-endian support. The related pixel-renderer will
>probably never win a beauty-contest, but it works.. Again, who cares
>for debug-log rendering speed?
Debug log writing performance is extremely
> > Does this mean it should also handle horizontal mirroring in
> > hardware (180? rotate, and scan lines backwards combined) ?
>
> Our hardware doesn't support mirroring (h or v). Well, unless you
> count h+v mirroring since that's 180 degree rotation :)
>
> Anyways IIRC the old video overlay
> fbcon is loaded so it isn't an issue.
>
> I tried 3.10 kernel initially (the above messages are from it), next
> I tried 3.13 kernel too, and that one behaves exactly the same.
>
> As far as I remember, this system never worked with graphics well.
> Previous kernel (from which I updated) was
On Fri, 7 Feb 2014 19:15:05 +0530
sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> These patches will enable 180 degree rotation for CRTC and Sprite planes.
> Changelog:
> 1. drm/i915: Add 180 degree primary plane rotation support
> Addressed review comments for CRTC rotation from
30 matches
Mail list logo
