Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for DMA_MEMORY_MAP

On Fri, Dec 04, 2015 at 05:15:54PM +, Catalin Marinas wrote: On Fri, Dec 04, 2015 at 08:59:10AM -0800, Dan Williams wrote: On Fri, Dec 4, 2015 at 2:50 AM, Catalin Marinas <catalin.mari...@arm.com> wrote: > On Fri, Nov 20, 2015 at 02:20:26PM +0000, Brian Starkey wrote

Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for DMA_MEMORY_MAP

, Brian Starkey wrote: When the DMA_MEMORY_MAP flag is used, memory which can be accessed directly should be returned, so use ioremap_wc() instead of ioremap(). Also, ensure that the correct memset operation is used in dma_alloc_from_coherent() with respect to the region's flags. This fixes

[PATCH 0/3] Add MEMREMAP_WC to fix dma_init_coherent_memory

when zeroing coherent allocations, which fixes an alignment fault on arm64. Best Regards, Brian [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390857.html Brian Starkey (3): memremap: add MEMREMAP_WC flag drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP

[PATCH 3/3] drivers: dma-coherent: use memset_io for DMA_MEMORY_IO mappings

-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> --- drivers/base/dma-coherent.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c index f98359a..4e

[PATCH 1/3] memremap: add MEMREMAP_WC flag

Add a flag to memremap() for writecombine mappings. Mappings satisfied by this flag will not be cached, however writes may be delayed or combined into more efficient bursts. This is most suitable for buffers written sequentially by the CPU for use by other DMA devices. Signed-off-by: Brian

[PATCH 2/3] drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP

When the DMA_MEMORY_MAP flag is used, memory which can be accessed directly should be returned, so use memremap(..., MEMREMAP_WC) to provide a writecombine mapping. Signed-off-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> --- driv

[RESEND PATCH 0/3] Add MEMREMAP_WC to fix dma_init_coherent_memory

/pipermail/linux-arm-kernel/2015-December/390857.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/397163.html Brian Starkey (3): memremap: add MEMREMAP_WC flag drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP drivers: dma-coherent: use memset_io

[RESEND PATCH 2/3] drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP

When the DMA_MEMORY_MAP flag is used, memory which can be accessed directly should be returned, so use memremap(..., MEMREMAP_WC) to provide a writecombine mapping. Signed-off-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> --- driv

[RESEND PATCH 1/3] memremap: add MEMREMAP_WC flag

Add a flag to memremap() for writecombine mappings. Mappings satisfied by this flag will not be cached, however writes may be delayed or combined into more efficient bursts. This is most suitable for buffers written sequentially by the CPU for use by other DMA devices. Signed-off-by: Brian

[RESEND PATCH 3/3] drivers: dma-coherent: use memset_io for DMA_MEMORY_IO mappings

-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> --- drivers/base/dma-coherent.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c index f98359a..4e

[PATCH] drivers: dma-coherent: use ioremap_wc() for DMA_MEMORY_MAP

: ffc0 x1 : x0 : ff800038 Signed-off-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> --- drivers/base/dma-coherent.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --g

Re: [RFC][PATCH 0/6] ion: improved ABI

Hi Laura, On Mon, Jun 06, 2016 at 11:23:27AM -0700, Laura Abbott wrote: The ABI for Ion's ioctl interface are a pain to work with. The heap IDs are a 32-bit non-discoverable namespace that form part of the ABI. There's no way to determine what ABI version is in use which leads to problems if

Re: [RFC][PATCH 6/6] staging: android: ion: Introduce new ioctls for dynamic heaps

Hi, I'm finding "usage_id" a bit confusing - there's not a very clear distinction between usage_id and heap ID. For instance, ION_IOC_USAGE_CNT claims to return the number of usage IDs, but seems to return the number of heaps (i.e. number heap IDs, some of which might be usage_ids). Similarly,

Re: [RFC][PATCH 6/6] staging: android: ion: Introduce new ioctls for dynamic heaps

Hi Laura, On Wed, Jun 08, 2016 at 12:14:12PM -0700, Laura Abbott wrote: For now I'm just going to focus on comments not about the heap ID mapping because I'm leaning towards dropping the heap ID mapping. Fair enough. Like you said, giving userspace enough information to just figure out the

Re: dma_declare_coherent_memory fails for RAM allocated memory

Hi Ivo, On Sun, May 29, 2016 at 05:56:02PM +0300, Ivaylo Dimitrov wrote: Hi, When trying to declare and use DT reserved memory region on ARM (OMAP3), dma_declare_coherent_memory() fails in memremap(). This is from today's master: [ cut here ] WARNING: CPU: 0 PID: 1

Re: [PATCH] genirq: fix trigger flags check for shared irqs

Hi Thomas, Any further thoughts on this? (some comments below) On Thu, Jan 28, 2016 at 02:37:24PM +0100, Thomas Gleixner wrote: In principle I agree. The issue is that it really depends on the particular hardware situation. If there is an explicit requirement for one driver - expressed by a

Re: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

Hi Greg, On Mon, Feb 08, 2016 at 10:30:06AM -0800, Greg KH wrote: On Mon, Feb 08, 2016 at 05:30:50PM +, Brian Starkey wrote: diff --git a/include/linux/io.h b/include/linux/io.h index 32403b5..e2c8419 100644 --- a/include/linux/io.h +++ b/include/linux/io.h @@ -135,6 +135,7 @@ enum

Re: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

Hi Andrew, Thanks for taking a look, On Mon, Feb 08, 2016 at 12:03:17PM -0800, Andrew Morton wrote: On Mon, 8 Feb 2016 17:30:50 + Brian Starkey <brian.star...@arm.com> wrote: The patch generally looks OK to me. It generates rejects against linux-next because of some janitorial c

[RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

Add a flag to memremap() for writecombine mappings. Mappings satisfied by this flag will not be cached, however writes may be delayed or combined into more efficient bursts. This is most suitable for buffers written sequentially by the CPU for use by other DMA devices. Signed-off-by: Brian

[RESEND2 PATCH 3/3] drivers: dma-coherent: use memset_io for DMA_MEMORY_IO mappings

-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> --- drivers/base/dma-coherent.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c index f98359a..4e

[RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent

, which fixes an alignment fault on arm64. Best Regards, Brian [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390857.html Brian Starkey (3): memremap: add MEMREMAP_WC flag drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP drivers: dma-coherent: use memset_io

[RESEND2 PATCH 2/3] drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP

When the DMA_MEMORY_MAP flag is used, memory which can be accessed directly should be returned, so use memremap(..., MEMREMAP_WC) to provide a writecombine mapping. Signed-off-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> Acke

Re: [RESEND PATCH 0/3] Add MEMREMAP_WC to fix dma_init_coherent_memory

Hi, Are there any comments on these? Without them dma-coherent can't be used on arm64 so it would be good to get them merged if there are no objections. I can resend with Michal's ack for patch 2 if needed. Thanks, Brian On Tue, Jan 05, 2016 at 04:41:25PM +, Brian Starkey wrote: Hi

[PATCH] genirq: fix trigger flags check for shared irqs

Signed-off-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Marc Zyngier <marc.zyng...@arm.com> --- kernel/irq/manage.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index a79d267..032c8fa 100644 ---

Re: [PATCH] genirq: fix trigger flags check for shared irqs

On Thu, Jan 28, 2016 at 12:49:37PM +0100, Thomas Gleixner wrote: On Thu, 28 Jan 2016, Brian Starkey wrote: I've got a few devices on the same interrupt line. One driver does Just for the record: When will hardware folks finally understand that shared interrupt lines are a nightmare

Re: [PATCH] genirq: fix trigger flags check for shared irqs

Hi Thomas, Thanks for taking a look at this. On Tue, Jan 26, 2016 at 09:45:32PM +0100, Thomas Gleixner wrote: On Tue, 26 Jan 2016, Brian Starkey wrote: For shared interrupts, if one requester passes in any IRQF_TRIGGER_* flags whilst another doesn't, __setup_irq() can erroneously fail

Re: [PATCH] genirq: fix trigger flags check for shared irqs

On Thu, Jan 28, 2016 at 11:29:21AM +0100, Thomas Gleixner wrote: Brian, On Thu, 28 Jan 2016, Brian Starkey wrote: On Tue, Jan 26, 2016 at 09:45:32PM +0100, Thomas Gleixner wrote: > On Tue, 26 Jan 2016, Brian Starkey wrote: > > > For shared interrupts, if one requester p

[PATCH v2 2/4] memremap: add MEMREMAP_WC flag.

Add a flag to memremap() for writecombine mappings. Mappings satisfied by this flag will not be cached, however writes may be delayed or combined into more efficient bursts. This is most suitable for buffers written sequentially by the CPU for use by other DMA devices. Signed-off-by: Brian

[PATCH v2 3/4] drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP

When the DMA_MEMORY_MAP flag is used, memory which can be accessed directly should be returned, so use memremap(..., MEMREMAP_WC) to provide a writecombine mapping. Signed-off-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> --- driv

[PATCH v2 0/4] Fix kernel panic in dma-coherent allocations

Changes since v1: * Added preparatory patch removing flag modifications in memremap() (Suggested by Andrew Morton) * Rebase onto linux-next Brian Starkey (4): memremap: don't modify flags memremap: add MEMREMAP_WC flag. drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP drivers

[PATCH v2 4/4] drivers: dma-coherent: use memset_io for DMA_MEMORY_IO mappings

-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> --- drivers/base/dma-coherent.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c index 25bb398..bd

[PATCH v2 1/4] memremap: don't modify flags

Don't modify the flags input argument to memremap(). MEMREMAP_WB is already a special case so we can check for it directly instead of clearing flag bits in each mapper. Signed-off-by: Brian Starkey <brian.star...@arm.com> --- kernel/memremap.c | 14 +++--- 1 file changed, 7 inse

Re: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

On Tue, Feb 16, 2016 at 04:43:51PM -0800, Greg Kroah-Hartman wrote: On Tue, Feb 16, 2016 at 11:14:26AM +, Brian Starkey wrote: Hi Greg, Is the documentation OK? Is there any chance of you picking up this series? I can rebase onto -next if that's the right place, but they still apply

Re: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

Hi Andrew, Would you pick these up if I rebase onto linux-next? How strongly do you feel about the input argument modification vs. staying in-line with the rest of the function? Thanks, Brian On Tue, Feb 09, 2016 at 10:23:00AM +, Brian Starkey wrote: Hi Andrew, Thanks for taking a look

Re: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

Starkey wrote: Hi Greg, On Mon, Feb 08, 2016 at 10:30:06AM -0800, Greg KH wrote: On Mon, Feb 08, 2016 at 05:30:50PM +, Brian Starkey wrote: diff --git a/include/linux/io.h b/include/linux/io.h index 32403b5..e2c8419 100644 --- a/include/linux/io.h +++ b/include/linux/io.h @@ -135,6 +135,7

Re: [PATCH v2 4/4] drivers: dma-coherent: use memset_io for DMA_MEMORY_IO mappings

Hi Andrew, On Mon, Feb 29, 2016 at 03:17:49PM -0800, Andrew Morton wrote: On Mon, 29 Feb 2016 16:09:24 + Brian Starkey <brian.star...@arm.com> wrote: Use memset_io() for DMA_MEMORY_IO mappings which are mapped as I/O memory, and regular memset() for DMA_MEMORY_MAP mappings. This

[PATCH v2] ARM: arm64: dts: Add expansion bus to VExpress and Juno

-by: Brian Starkey <brian.star...@arm.com> Acked-by: Liviu Dudau <liviu.du...@arm.com> --- Only change from v1 is rewording of the commit message as suggested by Liviu. arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 13 + arch/arm/boot/dts/vexpress-v2p-ca15_a7

[PATCH v3 1/2] ARM: dts: Add expansion bus to VExpress

The VExpress development platform has an external expansion bus which can be used for additional hardware (e.g. LogicTile Express daughterboards). Add this bus to the VExpress CoreTile device-trees. The bus is described for a CoreTile occupying site 1. Signed-off-by: Brian Starkey <brian.s

[PATCH v3 2/2] arm64: dts: Add expansion bus to Juno

The Juno development platform has an external expansion bus which can be used for additional hardware (e.g. LogicTile Express daughterboards). Add this bus to the Juno base device-tree. Signed-off-by: Brian Starkey <brian.star...@arm.com> Acked-by: Liviu Dudau <liviu.du...@arm.com&g

Re: [PATCH v3 1/2] ARM: dts: Add expansion bus to VExpress

On Fri, Apr 15, 2016 at 09:55:50AM +0100, Sudeep Holla wrote: On 14/04/16 16:39, Brian Starkey wrote: The VExpress development platform has an external expansion bus which can be used for additional hardware (e.g. LogicTile Express daughterboards). Add this bus to the VExpress CoreTile device

[PATCH] drm/i2c: tda998x: don't register the connector

to drm_connector_register()/drm_connector_unregister(). This allows componentised drivers to use tda998x without having racy initialisation. Signed-off-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Liviu Dudau <liviu.du...@arm.com> Cc: Russell King <rmk+ker...@arm.linux.org.uk> --- d

Re: [PATCH] drm/i2c: tda998x: don't register the connector

Hi Russell, On Mon, Jul 25, 2016 at 01:25:04PM +0100, Russell King - ARM Linux wrote: On Mon, Jul 25, 2016 at 11:55:48AM +0100, Brian Starkey wrote: The connector shouldn't be registered until the rest of the whole device is set up, so that consistent state is presented to userspace

Re: [PATCH -next] drm/arm: mali-dp: Fix error return code in malidp_bind()

Yongjun <weiyj...@gmail.com> --- Thanks for cleaning up after me! :-) Acked-by: Brian Starkey <brian.star...@arm.com> @Sean, can you pick this up on top of 3c31760e760c? Cheers, Brian drivers/gpu/drm/arm/malidp_drv.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --g

Re: [PATCH] debugfs: Add proxy function for the mmap file operation

Hi Nicolai, On Tue, Aug 02, 2016 at 07:31:36PM +0200, Nicolai Stange wrote: Nicolai Stange writes: Liviu Dudau writes: Add proxy function for the mmap file_operations hook under the full_proxy_fops structure. This is useful for providing a custom

Re: [PATCH] drm/i2c: tda998x: don't register the connector

Hi, On Mon, Jul 25, 2016 at 05:08:21PM +0200, Daniel Vetter wrote: On Mon, Jul 25, 2016 at 01:54:06PM +0100, Brian Starkey wrote: Hi Russell, On Mon, Jul 25, 2016 at 01:25:04PM +0100, Russell King - ARM Linux wrote: > On Mon, Jul 25, 2016 at 11:55:48AM +0100, Brian Starkey wr

[PATCH v2] drm/color: Document CTM eqations

.ch> Signed-off-by: Brian Starkey <brian.star...@arm.com> --- drivers/gpu/drm/drm_color_mgmt.c | 13 + include/uapi/drm/drm_mode.h |8 +++- 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_m

[PATCH v3] drm/color: Document CTM eqations

.ch> Signed-off-by: Brian Starkey <brian.star...@arm.com> --- drivers/gpu/drm/drm_color_mgmt.c | 13 + include/uapi/drm/drm_mode.h |8 +++- 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_m

Re: DRM Atomic property for color-space conversion

Hi, On Mon, Jan 30, 2017 at 03:35:13PM +0200, Ville Syrjälä wrote: On Fri, Jan 27, 2017 at 05:23:24PM +, Brian Starkey wrote: Hi, We're looking to enable the per-plane color management hardware in Mali-DP with atomic properties, which has sparked some conversation around how to handle

Re: [PATCH v2] drm/color: Document CTM eqations

Hi Jani, On Tue, Jan 31, 2017 at 01:30:41PM +0200, Jani Nikula wrote: On Tue, 31 Jan 2017, Brian Starkey <brian.star...@arm.com> wrote: Explicitly state the expected CTM equations in the kerneldoc for the CTM property, and the form of the matrix on struct drm_color_ctm. Cc: Ville S

Re: [PATCH v2] drm/color: Document CTM eqations

Hi Ville, On Tue, Jan 31, 2017 at 05:18:28PM +0200, Ville Syrjälä wrote: On Tue, Jan 31, 2017 at 10:48:34AM +, Brian Starkey wrote: Explicitly state the expected CTM equations in the kerneldoc for the CTM property, and the form of the matrix on struct drm_color_ctm. Cc: Ville Syrjälä

Re: [PATCH v3 1/3] drm: Add live source object

Hi Sergei, I wasn't around to see v1/v2 but I've taken a quick look in the archives. As context for my comments below, I'm keen to push for something which can be reused for live-sinks, so that we can hook a writeback connector (when I land that) into a v4l2 device for video capture. In that

Re: [PATCH v3 3/3] drm: rcar-du: Add VSP1 live source support

On Thu, Jan 26, 2017 at 12:38:26AM +0300, Sergei Shtylyov wrote: From: Laurent Pinchart Register live sources for VSPD0 and VSPD1 and configure the plane source at plane setup time to source frames from memory or from the VSP1. [Sergei: ported to the

Re: [PATCH v3 2/3] drm: Connect live source to framebuffers

On Thu, Jan 26, 2017 at 12:36:55AM +0300, Sergei Shtylyov wrote: From: Laurent Pinchart Introduce a new live source flag for framebuffers. When a framebuffer is created with that flag set, a live source is associated with the framebuffer instead of

Re: DRM Atomic property for color-space conversion

On Tue, Jan 31, 2017 at 05:15:46PM +0200, Ville Syrjälä wrote: On Tue, Jan 31, 2017 at 12:33:29PM +, Brian Starkey wrote: Hi, On Mon, Jan 30, 2017 at 03:35:13PM +0200, Ville Syrjälä wrote: >On Fri, Jan 27, 2017 at 05:23:24PM +0000, Brian Starkey wrote: >> Hi, >> >> We

Re: [PATCH] drm: mali-dp: Add CTM support

+Daniel to weigh in on the coefficient conversion. On Wed, Feb 01, 2017 at 12:05:03PM +, Mihail Atanassov wrote: All DPs have a COLORADJ matrix which is applied prior to output gamma. Attach that to the CTM property. Also, ensure the input CTM's coefficients can fit in the DP registers'

[PATCH v4] drm/color: Document CTM eqations

.ch> Signed-off-by: Brian Starkey <brian.star...@arm.com> --- drivers/gpu/drm/drm_color_mgmt.c | 13 + include/uapi/drm/drm_mode.h | 14 +- 2 files changed, 26 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/dr

Re: [PATCH 1/2] drm: mali-dp: add malidp_crtc_state struct

I'd be fine with you squashing these two together, but either way both are: Reviewed-by: Brian Starkey <brian.star...@arm.com> (two nitpicks below, but take them or leave them.) On Wed, Feb 01, 2017 at 10:16:57AM +, Mihail Atanassov wrote: Add a custom CRTC state struct to enable s

DRM Atomic property for color-space conversion

Hi, We're looking to enable the per-plane color management hardware in Mali-DP with atomic properties, which has sparked some conversation around how to handle YCbCr formats. As it stands today, it's assumed that a driver will implicitly "do the right thing" to display a YCbCr buffer. YCbCr

Re: [PATCH v2] drm/color: Document CTM eqations

What's the verdict? We've got [1] which is about to become another (driver) implementation - better to change before that merges than after I guess. -Brian [1] https://lkml.org/lkml/2017/2/13/304 On Wed, Feb 15, 2017 at 11:56:55AM +, Daniel Stone wrote: Hi, On 15 February 2017 at 11:39,

Re: [PATCHv2 1/4] staging: android: ion: Drop heap type masks

Hi Laura, On Thu, Sep 01, 2016 at 03:40:41PM -0700, Laura Abbott wrote: There is no advantage to having heap types be a mask. The ion client has long since dropped the mask. Drop the notion of heap type masks as well. I know this is the same patch you sent last time, so sorry for not

Re: [PATCHv2 1/4] staging: android: ion: Drop heap type masks

Hi, On Fri, Sep 02, 2016 at 12:36:25PM -0700, Laura Abbott wrote: On 09/02/2016 06:41 AM, Brian Starkey wrote: Hi Laura, On Thu, Sep 01, 2016 at 03:40:41PM -0700, Laura Abbott wrote: There is no advantage to having heap types be a mask. The ion client has long since dropped the mask. Drop

[PATCH] drm/atomic: mode_set encoders when routing changes

and encoder have not changed before skipping its encoder's mode_set. Signed-off-by: Brian Starkey <brian.star...@arm.com> --- drivers/gpu/drm/drm_atomic_helper.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/g

Re: [PATCHv2 1/4] staging: android: ion: Drop heap type masks

On Tue, Sep 06, 2016 at 03:16:52PM -0700, Laura Abbott wrote: On 09/05/2016 04:20 AM, Brian Starkey wrote: Hi, On Fri, Sep 02, 2016 at 12:36:25PM -0700, Laura Abbott wrote: On 09/02/2016 06:41 AM, Brian Starkey wrote: Hi Laura, On Thu, Sep 01, 2016 at 03:40:41PM -0700, Laura Abbott wrote

Re: [PATCH 2/3] drm: add ARM vendor format afbc

Hi Mark, On Sat, Sep 10, 2016 at 10:29:03AM +0800, Mark Yao wrote: AFBC is arm vendor format, it's a compressed format. The AFBC format is supported by rk3399 vop big. We know little about AFBC layout, hope to some guys can fixme about the afbc comment. Signed-off-by: Mark Yao

Re: [PATCH] drm/i2c: tda998x: don't register the connector

at 08:07:24AM +0200, Daniel Vetter wrote: On Mon, Aug 08, 2016 at 05:04:03PM +0100, Brian Starkey wrote: > Hi, > > On Mon, Jul 25, 2016 at 05:08:21PM +0200, Daniel Vetter wrote: > > On Mon, Jul 25, 2016 at 01:54:06PM +0100, Brian Starkey wrote: > > > Hi Russell, > >

Re: [PATCH] drm/i2c: tda998x: don't register the connector

On Fri, Sep 23, 2016 at 12:58:46PM +0200, Daniel Vetter wrote: On Fri, Sep 23, 2016 at 11:34 AM, Liviu Dudau wrote: rmmod-ing the hdlcd module generates a WARN() splat as the vsync is still enabled, but we never got the call to turn off the CRTC. Brian is still tracking

Re: [PATCH] drm/i2c: tda998x: don't register the connector

On Fri, Sep 23, 2016 at 03:13:15PM +0200, Daniel Vetter wrote: On Fri, Sep 23, 2016 at 01:52:49PM +0100, Brian Starkey wrote: On Fri, Sep 23, 2016 at 12:58:46PM +0200, Daniel Vetter wrote: > On Fri, Sep 23, 2016 at 11:34 AM, Liviu Dudau <liviu.du...@arm.com> wrote: > > rmmo

Re: [PATCH] drm/i2c: tda998x: don't register the connector

Thanks Russell, it's most appreciated. On Wed, Sep 21, 2016 at 05:28:03PM +0100, Russell King - ARM Linux wrote: On Wed, Sep 21, 2016 at 09:57:38AM +0100, Brian Starkey wrote: Hi Russell, Are you in a position to be able to test this now? Normally, I'd say no, because I'd normally wait

Re: [PATCH] drm/i2c: tda998x: don't register the connector

Hi Sean, On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote: On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux <li...@armlinux.org.uk> wrote: On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote: Actually, could you please hold off picking this up? We need t

Re: [PATCH] drm/i2c: tda998x: don't register the connector

On Thu, Sep 22, 2016 at 01:28:37PM +0200, Daniel Vetter wrote: On Thu, Sep 22, 2016 at 1:22 PM, Sean Paul <seanp...@chromium.org> wrote: On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux <li...@armlinux.org.uk> wrote: On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian S

Re: [RFC PATCH v2 8/9] drm: writeback: Add out-fences for writeback connectors

Hi Gustavo, On Wed, Oct 26, 2016 at 07:40:29PM -0200, Gustavo Padovan wrote: 2016-10-26 Brian Starkey <brian.star...@arm.com>: Add the OUT_FENCE_PTR property to writeback connectors, to enable userspace to get a fence which will signal once the writeback is complete. A timeline is

Re: [RFC PATCH v2 7/9] drm: atomic: factor out common out-fence operations

On Wed, Oct 26, 2016 at 07:45:14PM -0200, Gustavo Padovan wrote: %p should be kept for your internal debug only. Make sure to remove anything that exposes kernel address when sending patches. Gustavo Noted, thanks! -Brian

Re: [PATCH v7 1/3] drm/fence: add in-fences support

Hi Gustavo, On Tue, Nov 08, 2016 at 03:54:48PM +0900, Gustavo Padovan wrote: From: Gustavo Padovan There is now a new property called IN_FENCE_FD attached to every plane state that receives sync_file fds from userspace via the atomic commit IOCTL. The fd is

Re: [PATCH v7 3/3] drm/fence: add out-fences support

On Tue, Nov 08, 2016 at 03:54:50PM +0900, Gustavo Padovan wrote: From: Gustavo Padovan +static struct dma_fence *get_crtc_fence(struct drm_crtc *crtc, + struct drm_crtc_state *crtc_state) +{ + struct dma_fence *fence;

Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

Hi, On Wed, Nov 09, 2016 at 06:47:26PM +0900, Jaewon Kim wrote: On 2016년 11월 09일 18:27, Brian Starkey wrote: Hi Jaewon, On Wed, Nov 09, 2016 at 06:10:09PM +0900, Jaewon Kim wrote: Commit 6b03ae0d42bf (drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MA) added MEMREMAP_WC

Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

Hi Jaewon, On Wed, Nov 09, 2016 at 06:10:09PM +0900, Jaewon Kim wrote: Commit 6b03ae0d42bf (drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MA) added MEMREMAP_WC for DMA_MEMORY_MAP. If, however, CPU cache can be used on DMA_MEMORY_MAP, I think MEMREMAP_WC can be changed to MEMREMAP_WB. On

Re: [PATCH v8 1/3] drm/fence: add in-fences support

- rebase after fence -> dma_fence rename v7: Comments by Brian Starkey - set state->fence to NULL when duplicating the state - fail if IN_FENCE_FD was already set Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk> lgtm, Reviewed-by: Brian Starkey <bria

Re: [PATCH v8 3/3] drm/fence: add out-fences support

ve old approach. v5: Comments by Brian Starkey: - Remove extra fence_get() in atomic_ioctl() - Check ret before iterating on the crtc_state - check ret before fd_install - set fence_state to NULL at the beginning - check fence_state->out_fence_ptr before

Re: [PATCH] [RFC] drivers: dma-coherent: use MEMREMAP_WB instead of MEMREMAP_WC

Hi Jaewon, On Thu, Nov 10, 2016 at 10:41:43AM +0900, Jaewon Kim wrote: Hi On 2016년 11월 09일 19:23, Brian Starkey wrote: Hi, On Wed, Nov 09, 2016 at 06:47:26PM +0900, Jaewon Kim wrote: On 2016년 11월 09일 18:27, Brian Starkey wrote: Hi Jaewon, On Wed, Nov 09, 2016 at 06:10:09PM +0900, Jaewon

Re: [RFC PATCH 00/11] Introduce writeback connectors

Hi Archit, On Fri, Oct 14, 2016 at 04:20:14PM +0530, Archit Taneja wrote: Hi Brian, On 10/11/2016 08:23 PM, Brian Starkey wrote: Hi, This RFC series introduces a new connector type: DRM_MODE_CONNECTOR_WRITEBACK It is a follow-on from a previous discussion: [1] Writeback connectors are used

Re: [PATCH v5 3/4] drm/fence: add fence timeline to drm_crtc

Hi Gustavo, On Thu, Oct 20, 2016 at 12:50:04PM -0200, Gustavo Padovan wrote: From: Gustavo Padovan Create one timeline context for each CRTC to be able to handle out-fences and signal them. It adds a few members to struct drm_crtc: fence_context, where we

Re: [PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

Hi Daniel, On Mon, Oct 24, 2016 at 10:24:42PM +0200, Daniel Vetter wrote: On Mon, Oct 24, 2016 at 4:52 PM, Brian Starkey <brian.star...@arm.com> wrote: diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index f4315bc..6e6fca2 100644 --- a/drivers/gpu/d

Re: [PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

On Tue, Oct 25, 2016 at 12:19:19PM +0200, Daniel Vetter wrote: On Tue, Oct 25, 2016 at 10:52:33AM +0100, Brian Starkey wrote: Ah, makes sense. Should I apply this to drm-misc so it's in a shared tree? Honestly, I don't know. I didn't entirely follow what it was Russell wanted in terms

Re: [PATCH v5 4/4] drm/fence: add out-fences support

Hi Gustavo, I notice your branch has the sync_file refcount change in, but this doesn't seem to take account for that. Will you be dropping that change to match the semantics of fence_array? Couple more comments below. On Thu, Oct 20, 2016 at 12:50:05PM -0200, Gustavo Padovan wrote: From:

Re: [PATCH v5 4/4] drm/fence: add out-fences support

Hi, Sorry, I hit another couple of bugs that originated from my hastebin patch - see below. On Thu, Oct 20, 2016 at 12:50:05PM -0200, Gustavo Padovan wrote: From: Gustavo Padovan Support DRM out-fences by creating a sync_file with a fence for each CRTC that

Re: [PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

Hi Daniel, On Mon, Oct 24, 2016 at 04:36:27PM +0200, Daniel Vetter wrote: On Mon, Oct 24, 2016 at 03:27:59PM +0100, Brian Starkey wrote: Connectors shouldn't be registered until the rest of the whole device is set up, so that consistent state is presented to userspace. As such, remove

[PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

ker...@arm.linux.org.uk> Signed-off-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Liviu Dudau <liviu.du...@arm.com> --- drivers/gpu/drm/arm/hdlcd_drv.c | 19 +++ drivers/gpu/drm/arm/malidp_drv.c | 18 +++--- drivers/gpu/drm/i2c/tda998x_drv.c |8 ---

[PATCH] drm: mali-dp: Don't set DRM_PLANE_COMMIT_ACTIVE_ONLY

We need to explicitly disable our planes, so don't set the flag which would otherwise skip the plane disable when the CRTC is disabled. Signed-off-by: Brian Starkey <brian.star...@arm.com> --- drivers/gpu/drm/arm/malidp_drv.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff

Re: [PATCH v10 3/3] drm/fence: add out-fences support

T_MASK - userspace should fill out_fences_ptr with the crtc_ids for which it wants fences back. v4: Create OUT_FENCE_PTR properties and remove old approach. v5: Comments by Brian Starkey: - Remove extra fence_get() in atomic_ioctl() - Check ret before iterating on the crtc

Re: [PATCH v10 3/3] drm/fence: add out-fences support

proach. v5: Comments by Brian Starkey: - Remove extra fence_get() in atomic_ioctl() - Check ret before iterating on the crtc_state - check ret before fd_install - set fence_state to NULL at the beginning - check fence_state->out_fence_ptr before

[PATCH 5/6] drm: mali-dp: Add RGB writeback formats for DP550/DP650

Add a layer bit for the SE memory-write, and add it to the pixel format matrix for DP550/DP650. Signed-off-by: Brian Starkey <brian.star...@arm.com> --- drivers/gpu/drm/arm/malidp_hw.c | 28 ++-- drivers/gpu/drm/arm/malidp_hw.h |1 + 2 files changed, 15 inse

[RFC PATCH v3 0/6] Introduce writeback connectors

_writeback_job) is probably up for debate. v4 will be accompanied by igt tests. As always, I look forward to any comments. Thanks, Brian [1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1247574.html [2] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1258017.html --- Br

[PATCH 2/6] drm: writeback: Add out-fences for writeback connectors

fence in drm_writeback_job Gustavo Padovan: - Move out_fence_ptr out of connector_state - Signal fence from drm_writeback_signal_completion instead of in driver directly Signed-off-by: Brian Starkey <brian.star...@arm.com> --- drivers/gpu/drm/drm_atomic.c

[PATCH 1/6] drm: Add writeback connector type

check to allow CRTC to be set without an FB - Add some writeback_ prefixes - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary Gustavo Padovan: - Add drm_writeback_job to handle writeback signalling centrally Signed-off-by: Brian Starkey <brian.star...@arm.com> --- Documentation/g

[PATCH 6/6] drm: mali-dp: Add writeback connector

-by: Brian Starkey <brian.star...@arm.com> --- drivers/gpu/drm/arm/Makefile |1 + drivers/gpu/drm/arm/malidp_crtc.c | 21 +++ drivers/gpu/drm/arm/malidp_drv.c | 25 +++- drivers/gpu/drm/arm/malidp_drv.h |3 + drivers/gpu/drm/arm/malidp_hw.c |7 +- drivers/gpu/d

[PATCH 4/6] drm: mali-dp: Add support for writeback on DP550/DP650

mitted from this change. Signed-off-by: Liviu Dudau <liviu.du...@arm.com> Signed-off-by: Brian Starkey <brian.star...@arm.com> --- drivers/gpu/drm/arm/malidp_hw.c | 52 +++-- drivers/gpu/drm/arm/malidp_hw.h | 18 + drivers/gpu/drm/arm/ma

[PATCH 3/6] drm: mali-dp: Rename malidp_input_format

We're going to use the same format list for output formats, so rename everything related to input formats to avoid confusion. Signed-off-by: Brian Starkey <brian.star...@arm.com> Reviewed-by: Liviu Dudau <liviu.du...@arm.com> --- drivers/gpu/drm/arm/malidp_hw.

Re: Regression: Failed boots bisected to 4cd13c21b207 "softirq: Let ksoftirqd do its job"

Hi Eric, On Tue, Nov 22, 2016 at 08:09:58AM -0800, Eric Dumazet wrote: Looks like there's a few similarly named devices and drivers. Mine is an SMSC LAN91C111 using the smc91x driver in drivers/net/ethernet/smsc/smc91x.c, rather than smc911x.c. So the interrupt handler is smc_interrupt()

Re: Regression: Failed boots bisected to 4cd13c21b207 "softirq: Let ksoftirqd do its job"

Hi, On Fri, Nov 18, 2016 at 01:40:43AM +0100, Thomas Gleixner wrote: Brian, On Thu, 17 Nov 2016, Brian Starkey wrote: No joy with this patch :-( I had to add an ioaddr argument because apparently that macro depends on local context (yuck...), but it doesn't help my issue. FWIW I don't see

Re: Regression: Failed boots bisected to 4cd13c21b207 "softirq: Let ksoftirqd do its job"

Hi Eric, On Tue, Nov 22, 2016 at 06:29:33AM -0800, Eric Dumazet wrote: On Tue, Nov 22, 2016 at 2:33 AM, Brian Starkey <brian.star...@arm.com> wrote: Hi, On Fri, Nov 18, 2016 at 01:40:43AM +0100, Thomas Gleixner wrote: Brian, On Thu, 17 Nov 2016, Brian Starkey wrote:

  1   2   3   4   5   >