From: Matt Roper <matthew.d.roper@intel.com> To: Boris BREZILLON <boris.brezillon@free-electrons.com> Cc: Rob Clark <robdclark@gmail.com>, Mark Rutland <mark.rutland@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Nicolas Ferre <nicolas.ferre@atmel.com>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, Alexandre Belloni <alexandre.belloni@free-electrons.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Bo Shen <voice.shen@atmel.com>, Lee Jones <lee.jones@linaro.org>, Jean-Jacques Hiblot <jjhiblot@traphandler.com>, Samuel Ortiz <sameo@linux.intel.com>, Tim Niemeyer <tim.niemeyer@corscience.de>, Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>, linux-pwm@vger.kernel.org, Pawel Moll <pawel.moll@arm.com>, Ian Campbell <ijc+devicetree@hellion.org.uk>, Rob Herring <robh+dt@kernel.org>, Andrew Victor <linux@maxim.org.za>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Thomas Subject: Re: [RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support Date: Tue, 8 Jul 2014 16:51:24 -0700 [thread overview] Message-ID: <20140708235124.GM31728@intel.com> (raw) In-Reply-To: <20140708190820.2a94723f@bbrezillon> On Tue, Jul 08, 2014 at 07:08:20PM +0200, Boris BREZILLON wrote: > On Tue, 8 Jul 2014 11:41:32 -0400 > Rob Clark <robdclark@gmail.com> wrote: > > > On Tue, Jul 8, 2014 at 10:37 AM, Boris BREZILLON > > <boris.brezillon@free-electrons.com> wrote: > > > On Tue, 8 Jul 2014 08:49:41 -0400 > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > >> On Tue, Jul 8, 2014 at 3:23 AM, Boris BREZILLON > > >> <boris.brezillon@free-electrons.com> wrote: > > >> > Hello Rob, > > >> > > > >> > On Mon, 7 Jul 2014 23:45:54 -0400 > > >> > Rob Clark <robdclark@gmail.com> wrote: > > >> > > > >> >> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON > > >> >> <boris.brezillon@free-electrons.com> wrote: ... > > >> >> > +/** > > >> >> > + * Atmel HLCDC Plane update request structure. > > >> >> > + * > > >> >> > + * @crtc_x: x position of the plane relative to the CRTC > > >> >> > + * @crtc_y: y position of the plane relative to the CRTC > > >> >> > + * @crtc_w: visible width of the plane > > >> >> > + * @crtc_h: visible height of the plane > > >> >> > + * @src_x: x buffer position > > >> >> > + * @src_y: y buffer position > > >> >> > + * @src_w: buffer width > > >> >> > + * @src_h: buffer height > > >> >> > + * @pixel_format: pixel format > > >> >> > + * @gems: GEM object object containing image buffers > > >> >> > + * @offsets: offsets to apply to the GEM buffers > > >> >> > + * @pitches: line size in bytes > > >> >> > + * @crtc: crtc to display on > > >> >> > + * @finished: finished callback > > >> >> > + * @finished_data: data passed to the finished callback > > >> >> > + * @bpp: bytes per pixel deduced from pixel_format > > >> >> > + * @xstride: value to add to the pixel pointer between each line > > >> >> > + * @pstride: value to add to the pixel pointer between each pixel > > >> >> > + * @nplanes: number of planes (deduced from pixel_format) > > >> >> > + */ > > >> >> > +struct atmel_hlcdc_plane_update_req { > > >> >> > + int crtc_x; > > >> >> > + int crtc_y; > > >> >> > + unsigned int crtc_w; > > >> >> > + unsigned int crtc_h; > > >> >> > + uint32_t src_x; > > >> >> > + uint32_t src_y; > > >> >> > + uint32_t src_w; > > >> >> > + uint32_t src_h; > > >> >> > + uint32_t pixel_format; > > >> >> > + struct drm_gem_cma_object *gems[ATMEL_HLCDC_MAX_PLANES]; > > >> >> > + unsigned int offsets[ATMEL_HLCDC_MAX_PLANES]; > > >> >> > + unsigned int pitches[ATMEL_HLCDC_MAX_PLANES]; > > >> >> > > >> >> tbh, I've only looked closely, but I don't completely follow all the > > >> >> layering here.. I wonder if we'd be better off just moving 'struct > > >> >> drm_fb_cma' to header file so you could get the gem objects / pixel > > >> >> fmt / width / height directly from the fb object (and then you can > > >> >> reference count things at the fb level, rather than at the individual > > >> >> gem obj level, too) > > >> >> > > >> > > > >> > Actually, the HW cursor is a drm_plane too, and in this case I cannot > > >> > retrieve a drm_fb_cma object, but just a single GEM object (see > > >> > atmel_hlcdc_crtc_cursor_set function in atmel_hlcdc_crtc.c). > > >> > > >> oh, right.. well maybe for the cursor case it would be possible to > > >> wrap up the gem bo with an internally created fb? Not sure if that > > >> ends up simplifying things or not, so it is definitely your call. But > > >> at least my experience with other drivers (that did not use a plane as > > >> a cursor internally) was that I could simplify things after fb gained > > >> refcnt'ing. > > > > > > Unless I'm missing something, I'd say moving to fb objects instead of > > > GEM objects won't simplify the code much (I'm already refcnt'ing GEM > > > objects when launching a DMA transfer for a plane update). > > > > yeah, mostly just saves you a bit of bookkeeping. Ie. ref/unref one > > thing instead of loop over N objects, etc. Nothing earth-shattering. > > > > Okay, my bad, this is definitely simpler with fb objects (I made use of > drm_fb_cma_create to create an fb object when cursor_set is called) > than it was when using GEM objects. > > I might even be able to simplify the layer update mechanism with this > approach. > > Thanks for the advice. > > Best Regards, > > Boris Hi Boris. I haven't really looked at any of your driver in depth, but from a quick glance it looks like you're registering a cursor drm_plane (i.e., making use of the new universal plane infrastructure), but you're also providing an implementation of the legacy cursor ioctls (cursor_set and cursor_move). There's some patches working their way through the pipeline that should make this unnecessary and hopefully simplify your life a bit: http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=c394c2b08e247c32ef292b75fd8b34312465f8ae http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=b36552b32aa9c69e83a3a20bda56379fb9e52435 http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=161d0dc1dccb17ff7a38f462c7c0d4ef8bcc5662 http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=fc1d3e44ef7c1db93384150fdbf8948dcf949f15 The third patch there is the one that's really important for your work. When a driver provides a cursor plane via the universal plane interface, cursor_set and cursor_move are automatically implemented for you by drm_mode_cursor_universal() in drivers/gpu/drm/drm_crtc.c and your legacy handlers will never get called. drm_mode_cursor_universal() will take care of wrapping the bo's into a drm_framebuffer for you. When I added the universal cursor stuff, I wanted to make sure that as soon as a driver starts supporting universal planes it can stop supporting the legacy ioctls directly; otherwise handling refcounting when userspace switches back and forth between calling legacy ioctl's and calling setplane() on a cursor plane would be a nightmare. I think those patches are only available in drm-intel-nightly at the moment and haven't moved on to drm-next and such yet, since i915 is the only driver that currently has patches to make use of cursors via the univeral plane interface (probably landing for kernel 3.17). Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795
WARNING: multiple messages have this Message-ID (diff)
From: matthew.d.roper@intel.com (Matt Roper) To: linux-arm-kernel@lists.infradead.org Subject: [RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support Date: Tue, 8 Jul 2014 16:51:24 -0700 [thread overview] Message-ID: <20140708235124.GM31728@intel.com> (raw) In-Reply-To: <20140708190820.2a94723f@bbrezillon> On Tue, Jul 08, 2014 at 07:08:20PM +0200, Boris BREZILLON wrote: > On Tue, 8 Jul 2014 11:41:32 -0400 > Rob Clark <robdclark@gmail.com> wrote: > > > On Tue, Jul 8, 2014 at 10:37 AM, Boris BREZILLON > > <boris.brezillon@free-electrons.com> wrote: > > > On Tue, 8 Jul 2014 08:49:41 -0400 > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > >> On Tue, Jul 8, 2014 at 3:23 AM, Boris BREZILLON > > >> <boris.brezillon@free-electrons.com> wrote: > > >> > Hello Rob, > > >> > > > >> > On Mon, 7 Jul 2014 23:45:54 -0400 > > >> > Rob Clark <robdclark@gmail.com> wrote: > > >> > > > >> >> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON > > >> >> <boris.brezillon@free-electrons.com> wrote: ... > > >> >> > +/** > > >> >> > + * Atmel HLCDC Plane update request structure. > > >> >> > + * > > >> >> > + * @crtc_x: x position of the plane relative to the CRTC > > >> >> > + * @crtc_y: y position of the plane relative to the CRTC > > >> >> > + * @crtc_w: visible width of the plane > > >> >> > + * @crtc_h: visible height of the plane > > >> >> > + * @src_x: x buffer position > > >> >> > + * @src_y: y buffer position > > >> >> > + * @src_w: buffer width > > >> >> > + * @src_h: buffer height > > >> >> > + * @pixel_format: pixel format > > >> >> > + * @gems: GEM object object containing image buffers > > >> >> > + * @offsets: offsets to apply to the GEM buffers > > >> >> > + * @pitches: line size in bytes > > >> >> > + * @crtc: crtc to display on > > >> >> > + * @finished: finished callback > > >> >> > + * @finished_data: data passed to the finished callback > > >> >> > + * @bpp: bytes per pixel deduced from pixel_format > > >> >> > + * @xstride: value to add to the pixel pointer between each line > > >> >> > + * @pstride: value to add to the pixel pointer between each pixel > > >> >> > + * @nplanes: number of planes (deduced from pixel_format) > > >> >> > + */ > > >> >> > +struct atmel_hlcdc_plane_update_req { > > >> >> > + int crtc_x; > > >> >> > + int crtc_y; > > >> >> > + unsigned int crtc_w; > > >> >> > + unsigned int crtc_h; > > >> >> > + uint32_t src_x; > > >> >> > + uint32_t src_y; > > >> >> > + uint32_t src_w; > > >> >> > + uint32_t src_h; > > >> >> > + uint32_t pixel_format; > > >> >> > + struct drm_gem_cma_object *gems[ATMEL_HLCDC_MAX_PLANES]; > > >> >> > + unsigned int offsets[ATMEL_HLCDC_MAX_PLANES]; > > >> >> > + unsigned int pitches[ATMEL_HLCDC_MAX_PLANES]; > > >> >> > > >> >> tbh, I've only looked closely, but I don't completely follow all the > > >> >> layering here.. I wonder if we'd be better off just moving 'struct > > >> >> drm_fb_cma' to header file so you could get the gem objects / pixel > > >> >> fmt / width / height directly from the fb object (and then you can > > >> >> reference count things at the fb level, rather than at the individual > > >> >> gem obj level, too) > > >> >> > > >> > > > >> > Actually, the HW cursor is a drm_plane too, and in this case I cannot > > >> > retrieve a drm_fb_cma object, but just a single GEM object (see > > >> > atmel_hlcdc_crtc_cursor_set function in atmel_hlcdc_crtc.c). > > >> > > >> oh, right.. well maybe for the cursor case it would be possible to > > >> wrap up the gem bo with an internally created fb? Not sure if that > > >> ends up simplifying things or not, so it is definitely your call. But > > >> at least my experience with other drivers (that did not use a plane as > > >> a cursor internally) was that I could simplify things after fb gained > > >> refcnt'ing. > > > > > > Unless I'm missing something, I'd say moving to fb objects instead of > > > GEM objects won't simplify the code much (I'm already refcnt'ing GEM > > > objects when launching a DMA transfer for a plane update). > > > > yeah, mostly just saves you a bit of bookkeeping. Ie. ref/unref one > > thing instead of loop over N objects, etc. Nothing earth-shattering. > > > > Okay, my bad, this is definitely simpler with fb objects (I made use of > drm_fb_cma_create to create an fb object when cursor_set is called) > than it was when using GEM objects. > > I might even be able to simplify the layer update mechanism with this > approach. > > Thanks for the advice. > > Best Regards, > > Boris Hi Boris. I haven't really looked at any of your driver in depth, but from a quick glance it looks like you're registering a cursor drm_plane (i.e., making use of the new universal plane infrastructure), but you're also providing an implementation of the legacy cursor ioctls (cursor_set and cursor_move). There's some patches working their way through the pipeline that should make this unnecessary and hopefully simplify your life a bit: http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=c394c2b08e247c32ef292b75fd8b34312465f8ae http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=b36552b32aa9c69e83a3a20bda56379fb9e52435 http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=161d0dc1dccb17ff7a38f462c7c0d4ef8bcc5662 http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=fc1d3e44ef7c1db93384150fdbf8948dcf949f15 The third patch there is the one that's really important for your work. When a driver provides a cursor plane via the universal plane interface, cursor_set and cursor_move are automatically implemented for you by drm_mode_cursor_universal() in drivers/gpu/drm/drm_crtc.c and your legacy handlers will never get called. drm_mode_cursor_universal() will take care of wrapping the bo's into a drm_framebuffer for you. When I added the universal cursor stuff, I wanted to make sure that as soon as a driver starts supporting universal planes it can stop supporting the legacy ioctls directly; otherwise handling refcounting when userspace switches back and forth between calling legacy ioctl's and calling setplane() on a cursor plane would be a nightmare. I think those patches are only available in drm-intel-nightly at the moment and haven't moved on to drm-next and such yet, since i915 is the only driver that currently has patches to make use of cursors via the univeral plane interface (probably landing for kernel 3.17). Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795
next prev parent reply other threads:[~2014-07-08 23:51 UTC|newest] Thread overview: 149+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-07 16:42 [RESEND PATCH v3 00/11] drm: add support for Atmel HLCDC Display Controller Boris BREZILLON 2014-07-07 16:42 ` Boris BREZILLON 2014-07-07 16:42 ` [RESEND PATCH v3 01/11] mfd: add atmel-hlcdc driver Boris BREZILLON 2014-07-07 16:42 ` Boris BREZILLON 2014-07-07 16:42 ` [RESEND PATCH v3 02/11] mfd: add documentation for atmel-hlcdc DT bindings Boris BREZILLON 2014-07-07 16:42 ` Boris BREZILLON 2014-07-07 16:42 ` [RESEND PATCH v3 03/11] pwm: add support for atmel-hlcdc-pwm device Boris BREZILLON 2014-07-07 16:42 ` Boris BREZILLON 2014-07-07 16:42 ` [RESEND PATCH v3 04/11] pwm: add DT bindings documentation for atmel-hlcdc-pwm driver Boris BREZILLON 2014-07-07 16:42 ` Boris BREZILLON 2014-07-07 16:42 ` [RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support Boris BREZILLON 2014-07-07 16:42 ` Boris BREZILLON 2014-07-08 3:45 ` Rob Clark 2014-07-08 7:23 ` Boris BREZILLON 2014-07-08 7:23 ` Boris BREZILLON 2014-07-08 12:49 ` Rob Clark 2014-07-08 12:49 ` Rob Clark 2014-07-08 14:37 ` Boris BREZILLON 2014-07-08 14:37 ` Boris BREZILLON 2014-07-08 15:41 ` Rob Clark 2014-07-08 15:41 ` Rob Clark 2014-07-08 17:08 ` Boris BREZILLON 2014-07-08 17:08 ` Boris BREZILLON 2014-07-08 23:51 ` Matt Roper [this message] 2014-07-08 23:51 ` Matt Roper 2014-07-09 7:14 ` Boris BREZILLON 2014-07-09 7:14 ` Boris BREZILLON 2014-07-09 14:02 ` Daniel Vetter 2014-07-09 14:02 ` Daniel Vetter 2014-07-09 8:18 ` Boris BREZILLON 2014-07-09 8:18 ` Boris BREZILLON 2014-07-09 11:53 ` Rob Clark 2014-07-09 11:53 ` Rob Clark 2014-07-11 15:17 ` [RFC PATCH] drm: rework flip-work helpers to avoid calling func when the FIFO is full Boris BREZILLON 2014-07-11 15:41 ` Rob Clark 2014-07-11 15:47 ` Boris BREZILLON 2014-07-11 15:57 ` Boris BREZILLON 2014-07-11 16:05 ` Rob Clark 2014-07-12 18:16 ` [RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support Boris BREZILLON 2014-07-12 18:16 ` Boris BREZILLON 2014-07-12 18:37 ` Rob Clark 2014-07-12 18:37 ` Rob Clark 2014-07-15 11:26 ` Boris BREZILLON 2014-07-15 11:26 ` Boris BREZILLON 2014-07-07 16:42 ` [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver Boris BREZILLON 2014-07-07 16:42 ` Boris BREZILLON 2014-07-10 11:16 ` Laurent Pinchart 2014-07-10 11:16 ` Laurent Pinchart 2014-07-10 12:56 ` Boris BREZILLON 2014-07-10 12:56 ` Boris BREZILLON 2014-07-11 10:37 ` Laurent Pinchart 2014-07-11 10:37 ` Laurent Pinchart 2014-07-11 12:00 ` Boris BREZILLON 2014-07-11 12:00 ` Boris BREZILLON 2014-07-11 12:19 ` Boris BREZILLON 2014-07-11 12:19 ` Boris BREZILLON 2014-07-14 10:18 ` Thierry Reding 2014-07-14 10:18 ` Thierry Reding 2014-07-15 11:45 ` Boris BREZILLON 2014-07-15 11:45 ` Boris BREZILLON 2014-07-14 10:05 ` Thierry Reding 2014-07-14 10:05 ` Thierry Reding 2014-07-15 10:06 ` Boris BREZILLON 2014-07-15 10:06 ` Boris BREZILLON 2014-07-15 10:20 ` Laurent Pinchart 2014-07-15 10:20 ` Laurent Pinchart 2014-07-15 10:37 ` Thierry Reding 2014-07-15 10:37 ` Thierry Reding 2014-07-15 10:43 ` Laurent Pinchart 2014-07-15 10:43 ` Laurent Pinchart 2014-07-15 10:52 ` Thierry Reding 2014-07-15 10:52 ` Thierry Reding 2014-07-15 11:07 ` Laurent Pinchart 2014-07-15 11:07 ` Laurent Pinchart 2014-07-16 13:05 ` Boris BREZILLON 2014-07-16 13:05 ` Boris BREZILLON 2014-07-16 13:20 ` Laurent Pinchart 2014-07-16 13:20 ` Laurent Pinchart 2014-07-16 13:20 ` Laurent Pinchart 2014-07-16 13:44 ` Boris BREZILLON 2014-07-16 13:44 ` Boris BREZILLON 2014-07-15 12:14 ` Boris BREZILLON 2014-07-15 12:14 ` Boris BREZILLON 2014-07-15 10:31 ` Thierry Reding 2014-07-15 10:31 ` Thierry Reding 2014-07-18 14:51 ` Boris BREZILLON 2014-07-18 14:51 ` Boris BREZILLON 2014-07-18 15:43 ` Boris BREZILLON 2014-07-18 15:43 ` Boris BREZILLON 2014-07-21 8:59 ` Thierry Reding 2014-07-21 8:59 ` Thierry Reding 2014-07-21 9:24 ` Boris BREZILLON 2014-07-21 9:24 ` Boris BREZILLON 2014-07-21 9:32 ` Laurent Pinchart 2014-07-21 9:32 ` Laurent Pinchart 2014-07-21 9:57 ` Boris BREZILLON 2014-07-21 9:57 ` Boris BREZILLON 2014-07-21 12:12 ` Thierry Reding 2014-07-21 12:12 ` Thierry Reding 2014-07-21 12:16 ` Laurent Pinchart 2014-07-21 12:16 ` Laurent Pinchart 2014-07-21 12:34 ` Boris BREZILLON 2014-07-21 12:34 ` Boris BREZILLON 2014-07-21 12:55 ` Thierry Reding 2014-07-21 12:55 ` Thierry Reding 2014-07-21 13:22 ` Laurent Pinchart 2014-07-21 13:22 ` Laurent Pinchart 2014-07-21 13:30 ` Thierry Reding 2014-07-21 13:30 ` Thierry Reding 2014-07-21 13:43 ` Boris BREZILLON 2014-07-21 13:43 ` Boris BREZILLON 2014-07-21 13:47 ` Laurent Pinchart 2014-07-21 13:47 ` Laurent Pinchart 2014-07-21 13:54 ` Thierry Reding 2014-07-21 13:54 ` Thierry Reding 2014-07-21 14:21 ` Boris BREZILLON 2014-07-21 14:21 ` Boris BREZILLON 2014-07-21 18:30 ` Laurent Pinchart 2014-07-21 18:30 ` Laurent Pinchart 2014-07-21 22:04 ` Thierry Reding 2014-07-21 22:04 ` Thierry Reding 2014-07-21 14:18 ` Boris BREZILLON 2014-07-21 14:18 ` Boris BREZILLON 2014-07-21 18:32 ` Laurent Pinchart 2014-07-21 18:32 ` Laurent Pinchart 2014-07-21 17:06 ` Russell King - ARM Linux 2014-07-21 17:06 ` Russell King - ARM Linux 2014-07-21 22:17 ` Thierry Reding 2014-07-21 22:17 ` Thierry Reding 2014-07-21 12:15 ` Thierry Reding 2014-07-21 12:15 ` Thierry Reding 2014-07-21 12:33 ` Boris BREZILLON 2014-07-21 12:33 ` Boris BREZILLON 2014-07-21 12:56 ` Thierry Reding 2014-07-21 12:56 ` Thierry Reding 2014-07-21 13:26 ` Laurent Pinchart 2014-07-21 13:26 ` Laurent Pinchart 2014-07-21 13:33 ` Thierry Reding 2014-07-21 13:33 ` Thierry Reding 2014-07-07 16:43 ` [RESEND PATCH v3 07/11] ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode configs Boris BREZILLON 2014-07-07 16:43 ` Boris BREZILLON 2014-07-07 16:43 ` [RESEND PATCH v3 08/11] ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins Boris BREZILLON 2014-07-07 16:43 ` Boris BREZILLON 2014-07-07 16:43 ` [RESEND PATCH v3 09/11] ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs Boris BREZILLON 2014-07-07 16:43 ` Boris BREZILLON 2014-07-07 16:43 ` [RESEND PATCH v3 10/11] ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi Boris BREZILLON 2014-07-07 16:43 ` Boris BREZILLON 2014-07-07 16:43 ` [RESEND PATCH v3 11/11] ARM: at91/dt: enable the LCD panel on sama5d3xek boards Boris BREZILLON 2014-07-07 16:43 ` Boris BREZILLON
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20140708235124.GM31728@intel.com \ --to=matthew.d.roper@intel.com \ --cc=alexandre.belloni@free-electrons.com \ --cc=boris.brezillon@free-electrons.com \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=ijc+devicetree@hellion.org.uk \ --cc=jjhiblot@traphandler.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=lee.jones@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pwm@vger.kernel.org \ --cc=linux@maxim.org.za \ --cc=mark.rutland@arm.com \ --cc=nicolas.ferre@atmel.com \ --cc=pawel.moll@arm.com \ --cc=plagnioj@jcrosoft.com \ --cc=robdclark@gmail.com \ --cc=robh+dt@kernel.org \ --cc=sameo@linux.intel.com \ --cc=tim.niemeyer@corscience.de \ --cc=voice.shen@atmel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.