similar to: (no subject)

On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrj?l? > <ville.syrjala at linux.intel.com> wrote: > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > I have long suspected that a whole bunch of the "simple" displays > > > are not simple but contains a display

On Wed, Feb 26, 2020 at 3:34 PM Ville Syrj?l? <ville.syrjala at linux.intel.com> wrote: > On Wed, Feb 26, 2020 at 01:08:06PM +0100, Linus Walleij wrote: > > On Wed, Feb 26, 2020 at 12:57 PM Ville Syrj?l? > > <ville.syrjala at linux.intel.com> wrote: > > > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > > > > > I have long

On Wed, Feb 26, 2020 at 12:57 PM Ville Syrj?l? <ville.syrjala at linux.intel.com> wrote: > On Tue, Feb 25, 2020 at 10:52:25PM +0100, Linus Walleij wrote: > > I have long suspected that a whole bunch of the "simple" displays > > are not simple but contains a display controller and memory. > > That means that the speed over the link to the display and > >

Passing the wrong type feels icky, everywhere else we use the pipe as the first parameter. Spotted while discussing patches with Thomas Zimmermann. v2: Make xen compile correctly Acked-By: Thomas Zimmermann <tzimmermann at suse.de> (v1) Cc: Thomas Zimmermann <tzimmermann at suse.de> Cc: Noralf Tr?nnes <noralf at tronnes.org> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc:

Passing the wrong type feels icky, everywhere else we use the pipe as the first parameter. Spotted while discussing patches with Thomas Zimmermann. v2: Make xen compile correctly Acked-By: Thomas Zimmermann <tzimmermann at suse.de> (v1) Cc: Thomas Zimmermann <tzimmermann at suse.de> Cc: Noralf Tr?nnes <noralf at tronnes.org> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc:

On Thu, Nov 15, 2018 at 11:38:35PM +0100, Linus Walleij wrote: > On Thu, Nov 15, 2018 at 11:17 PM Fernando Ramos <greenfoo at gluegarage.com> wrote: > > > One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to > > "switch from reference/unreference to get/put". That's what this patch series is > > about. > > The

On Thu, Nov 15, 2018 at 11:38:35PM +0100, Linus Walleij wrote: > On Thu, Nov 15, 2018 at 11:17 PM Fernando Ramos <greenfoo at gluegarage.com> wrote: > > > One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to > > "switch from reference/unreference to get/put". That's what this patch series is > > about. > > The

Forward declare struct backlight_device and remove the include statement. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Reviewed-by: Jani Nikula <jani.nikula at intel.com> --- include/linux/fb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fb.h b/include/linux/fb.h index 2ce2f5c2fca9a..7380d959c5d53 100644 --- a/include/linux/fb.h +++

This is the first draft of the audio/vorbis media registration form to be handled to the IANA. PLEASE comment extensively, even minor spelling mistakes etc are to be stamped out of this I hope. A media type for application/ogg (or should it be application/oggsquish?) will be created separately. I would be very happy if someone could supply the 4-letter filetype code used by MacIntosh .ogg files.

After much bureucracy in the IETF hierarchies and sort of chaos-like organization, it seems I have got the matter so far that a four-week last call will be issued so that application/ogg finally becomes a standard. Don't jump of joy just yet, but I have feelings that it actually may happen now. :-) The "last call" is not yet issued! (They started discussing adding this MIME-type in

https://bugs.freedesktop.org/show_bug.cgi?id=40747 Summary: The new nouveau kernel module fails to use my monitor's native resolution Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component:

The transport type application/ogg may now be used in applications. The IANA has assigned it in their namespace, so start adding it at will. See mail below. Linus ---------- Forwarded message ---------- Date: Mon, 10 Feb 2003 12:23:47 -0800 From: IANA <iana@iana.org> To: triad@df.lth.se Cc: Allison Mankin <mankin@psg.com>, Scott Bradner <sob@harvard.edu> Subject: RFC-to-be:

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

Ville also pointed out that I got a lot of the logic here wrong as well, whoops. While I don't think anyone's likely using 3D output with nouveau, the next patch will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get rid of it and open-code it like before, while taking care to move the 3D frame packing calculations on the dot clock into the right place.

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add feature VIRTIO_CONSOLE_F_DMA_MEM. If the architecture has DMA support and this feature bit is set, the virtio data buffers will be allocated from DMA memory. This is needed for using virtio_console from the remoteproc framework. Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> cc: Rusty Russell <rusty

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add feature VIRTIO_CONSOLE_F_DMA_MEM. If the architecture has DMA support and this feature bit is set, the virtio data buffers will be allocated from DMA memory. This is needed for using virtio_console from the remoteproc framework. Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> cc: Rusty Russell <rusty

Overall I like this, just an inline question: On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > To do framebuffer updates, one needs memcpy from system memory and a > pointer-increment function. Add both interfaces with documentation. (...) > +/** > + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping > + * @dst: The dma-buf

Just a backport of the two patches for v5.9 that you'll want to apply. The first one was Cc'd to stable, but I forgot to Cc the second one as well. Lyude Paul (2): drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid() drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid() drivers/gpu/drm/nouveau/nouveau_connector.c | 36 ++++++---------------

Passing the wrong type feels icky, everywhere else we use the pipe as the first parameter. Spotted while discussing patches with Thomas Zimmermann. Cc: Thomas Zimmermann <tzimmermann at suse.de> Cc: Noralf Tr?nnes <noralf at tronnes.org> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: Eric Anholt <eric at anholt.net> Cc: Emil Velikov <emil.velikov at collabora.com> Cc: