All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Inki Dae <inki.dae@samsung.com>
Cc: 'Daniel Vetter' <daniel@ffwll.ch>,
	'Rob Clark' <robdclark@gmail.com>,
	'linux-fbdev' <linux-fbdev@vger.kernel.org>,
	'YoungJun Cho' <yj44.cho@samsung.com>,
	'Kyungmin Park' <kyungmin.park@samsung.com>,
	"'myungjoo.ham'" <myungjoo.ham@samsung.com>,
	'DRI mailing list' <dri-devel@lists.freedesktop.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: Introduce a new helper framework for buffer synchronization
Date: Mon, 27 May 2013 15:23:00 +0000	[thread overview]
Message-ID: <51A37A54.1040700@canonical.com> (raw)
In-Reply-To: <014501ce5ac6$511a8500$f34f8f00$%dae@samsung.com>

Hey,

Op 27-05-13 12:38, Inki Dae schreef:
> Hi all,
>
> I have been removed previous branch and added new one with more cleanup.
> This time, the fence helper doesn't include user side interfaces and cache
> operation relevant codes anymore because not only we are not sure that
> coupling those two things, synchronizing caches and buffer access between
> CPU and CPU, CPU and DMA, and DMA and DMA with fences, in kernel side is a
> good idea yet but also existing codes for user side have problems with badly
> behaved or crashing userspace. So this could be more discussed later.
>
> The below is a new branch,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/?h=dma-f
> ence-helper
>
> And fence helper codes,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&id­cbc0fe7e285ce866e5816e5e21443dcce01005
>
> And example codes for device driver,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&idÒce7af23835789602a99d0ccef1f53cdd5caaae
>
> I think the time is not yet ripe for RFC posting: maybe existing dma fence
> and reservation need more review and addition work. So I'd glad for somebody
> giving other opinions and advices in advance before RFC posting.
>
NAK.

For examples for how to handle locking properly, see Documentation/ww-mutex-design.txt in my recent tree.
I could list what I believe is wrong with your implementation, but real problem is that the approach you're taking is wrong.

~Maarten

WARNING: multiple messages have this Message-ID (diff)
From: maarten.lankhorst@canonical.com (Maarten Lankhorst)
To: linux-arm-kernel@lists.infradead.org
Subject: Introduce a new helper framework for buffer synchronization
Date: Mon, 27 May 2013 17:23:00 +0200	[thread overview]
Message-ID: <51A37A54.1040700@canonical.com> (raw)
In-Reply-To: <014501ce5ac6$511a8500$f34f8f00$%dae@samsung.com>

Hey,

Op 27-05-13 12:38, Inki Dae schreef:
> Hi all,
>
> I have been removed previous branch and added new one with more cleanup.
> This time, the fence helper doesn't include user side interfaces and cache
> operation relevant codes anymore because not only we are not sure that
> coupling those two things, synchronizing caches and buffer access between
> CPU and CPU, CPU and DMA, and DMA and DMA with fences, in kernel side is a
> good idea yet but also existing codes for user side have problems with badly
> behaved or crashing userspace. So this could be more discussed later.
>
> The below is a new branch,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/?h=dma-f
> ence-helper
>
> And fence helper codes,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&id=adcbc0fe7e285ce866e5816e5e21443dcce01005
>
> And example codes for device driver,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&id=d2ce7af23835789602a99d0ccef1f53cdd5caaae
>
> I think the time is not yet ripe for RFC posting: maybe existing dma fence
> and reservation need more review and addition work. So I'd glad for somebody
> giving other opinions and advices in advance before RFC posting.
>
NAK.

For examples for how to handle locking properly, see Documentation/ww-mutex-design.txt in my recent tree.
I could list what I believe is wrong with your implementation, but real problem is that the approach you're taking is wrong.

~Maarten

WARNING: multiple messages have this Message-ID (diff)
From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Inki Dae <inki.dae@samsung.com>
Cc: 'Daniel Vetter' <daniel@ffwll.ch>,
	'Rob Clark' <robdclark@gmail.com>,
	'linux-fbdev' <linux-fbdev@vger.kernel.org>,
	'YoungJun Cho' <yj44.cho@samsung.com>,
	'Kyungmin Park' <kyungmin.park@samsung.com>,
	"'myungjoo.ham'" <myungjoo.ham@samsung.com>,
	'DRI mailing list' <dri-devel@lists.freedesktop.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: Introduce a new helper framework for buffer synchronization
Date: Mon, 27 May 2013 17:23:00 +0200	[thread overview]
Message-ID: <51A37A54.1040700@canonical.com> (raw)
In-Reply-To: <014501ce5ac6$511a8500$f34f8f00$%dae@samsung.com>

Hey,

Op 27-05-13 12:38, Inki Dae schreef:
> Hi all,
>
> I have been removed previous branch and added new one with more cleanup.
> This time, the fence helper doesn't include user side interfaces and cache
> operation relevant codes anymore because not only we are not sure that
> coupling those two things, synchronizing caches and buffer access between
> CPU and CPU, CPU and DMA, and DMA and DMA with fences, in kernel side is a
> good idea yet but also existing codes for user side have problems with badly
> behaved or crashing userspace. So this could be more discussed later.
>
> The below is a new branch,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/?h=dma-f
> ence-helper
>
> And fence helper codes,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&id=adcbc0fe7e285ce866e5816e5e21443dcce01005
>
> And example codes for device driver,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&id=d2ce7af23835789602a99d0ccef1f53cdd5caaae
>
> I think the time is not yet ripe for RFC posting: maybe existing dma fence
> and reservation need more review and addition work. So I'd glad for somebody
> giving other opinions and advices in advance before RFC posting.
>
NAK.

For examples for how to handle locking properly, see Documentation/ww-mutex-design.txt in my recent tree.
I could list what I believe is wrong with your implementation, but real problem is that the approach you're taking is wrong.

~Maarten

WARNING: multiple messages have this Message-ID (diff)
From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Inki Dae <inki.dae@samsung.com>
Cc: 'Daniel Vetter' <daniel@ffwll.ch>,
	'Rob Clark' <robdclark@gmail.com>,
	'linux-fbdev' <linux-fbdev@vger.kernel.org>,
	'YoungJun Cho' <yj44.cho@samsung.com>,
	'Kyungmin Park' <kyungmin.park@samsung.com>,
	"'myungjoo.ham'" <myungjoo.ham@samsung.com>,
	'DRI mailing list' <dri-devel@lists.freedesktop.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: Introduce a new helper framework for buffer synchronization
Date: Mon, 27 May 2013 17:23:00 +0200	[thread overview]
Message-ID: <51A37A54.1040700@canonical.com> (raw)
In-Reply-To: <014501ce5ac6$511a8500$f34f8f00$%dae@samsung.com>

Hey,

Op 27-05-13 12:38, Inki Dae schreef:
> Hi all,
>
> I have been removed previous branch and added new one with more cleanup.
> This time, the fence helper doesn't include user side interfaces and cache
> operation relevant codes anymore because not only we are not sure that
> coupling those two things, synchronizing caches and buffer access between
> CPU and CPU, CPU and DMA, and DMA and DMA with fences, in kernel side is a
> good idea yet but also existing codes for user side have problems with badly
> behaved or crashing userspace. So this could be more discussed later.
>
> The below is a new branch,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/?h=dma-f
> ence-helper
>
> And fence helper codes,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&id=adcbc0fe7e285ce866e5816e5e21443dcce01005
>
> And example codes for device driver,
> 	
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&id=d2ce7af23835789602a99d0ccef1f53cdd5caaae
>
> I think the time is not yet ripe for RFC posting: maybe existing dma fence
> and reservation need more review and addition work. So I'd glad for somebody
> giving other opinions and advices in advance before RFC posting.
>
NAK.

For examples for how to handle locking properly, see Documentation/ww-mutex-design.txt in my recent tree.
I could list what I believe is wrong with your implementation, but real problem is that the approach you're taking is wrong.

~Maarten

  reply	other threads:[~2013-05-27 15:23 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-09  7:33 Introduce a new helper framework for buffer synchronization Inki Dae
2013-05-13  8:00 ` Maarten Lankhorst
2013-05-13  8:00   ` Maarten Lankhorst
2013-05-13  8:00   ` Maarten Lankhorst
2013-05-13  9:21   ` Inki Dae
2013-05-13  9:21     ` Inki Dae
2013-05-13  9:21     ` Inki Dae
2013-05-13  9:52     ` Maarten Lankhorst
2013-05-13  9:52       ` Maarten Lankhorst
2013-05-13  9:52       ` Maarten Lankhorst
2013-05-13 11:24   ` Inki Dae
2013-05-13 11:24     ` Inki Dae
2013-05-13 11:24     ` Inki Dae
2013-05-13 11:40     ` Maarten Lankhorst
2013-05-13 11:40       ` Maarten Lankhorst
2013-05-13 11:40       ` Maarten Lankhorst
2013-05-13 19:29     ` Tomasz Figa
2013-05-13 19:29       ` Tomasz Figa
2013-05-13 19:29       ` Tomasz Figa
2013-05-13 12:21   ` Inki Dae
2013-05-13 12:21     ` Inki Dae
2013-05-13 12:21     ` Inki Dae
2013-05-13 13:48     ` Rob Clark
2013-05-13 13:48       ` Rob Clark
2013-05-13 13:48       ` Rob Clark
2013-05-13 17:18       ` Inki Dae
2013-05-13 17:58         ` Rob Clark
2013-05-13 17:58           ` Rob Clark
2013-05-13 17:58           ` Rob Clark
2013-05-14  2:52   ` Inki Dae
2013-05-14  2:52     ` Inki Dae
2013-05-14  2:52     ` Inki Dae
2013-05-14 13:38     ` Rob Clark
2013-05-14 13:38       ` Rob Clark
2013-05-14 13:38       ` Rob Clark
2013-05-15  5:19   ` Inki Dae
2013-05-15  5:19     ` Inki Dae
2013-05-15  5:19     ` Inki Dae
2013-05-15 14:06     ` Rob Clark
2013-05-15 14:06       ` Rob Clark
2013-05-15 14:06       ` Rob Clark
2013-05-17  4:19       ` Daniel Vetter
2013-05-17  4:19         ` Daniel Vetter
2013-05-17  4:19         ` Daniel Vetter
2013-05-18  7:43         ` Inki Dae
2013-05-18  6:47       ` Inki Dae
2013-05-20 21:13         ` Daniel Vetter
2013-05-20 21:13           ` Daniel Vetter
2013-05-20 21:13           ` Daniel Vetter
2013-05-20 21:30           ` Daniel Vetter
2013-05-20 21:30             ` Daniel Vetter
2013-05-20 21:30             ` Daniel Vetter
2013-05-21  7:03   ` Inki Dae
2013-05-21  7:03     ` Inki Dae
2013-05-21  7:03     ` Inki Dae
2013-05-21  7:44     ` Daniel Vetter
2013-05-21  7:44       ` Daniel Vetter
2013-05-21  7:44       ` Daniel Vetter
2013-05-21  9:22   ` Inki Dae
2013-05-21  9:22     ` Inki Dae
2013-05-21  9:22     ` Inki Dae
2013-05-23 11:55     ` Daniel Vetter
2013-05-23 11:55       ` Daniel Vetter
2013-05-23 11:55       ` Daniel Vetter
2013-05-23 13:37   ` Inki Dae
2013-05-23 13:37     ` Inki Dae
2013-05-23 13:37     ` Inki Dae
2013-05-27 10:38   ` Inki Dae
2013-05-27 10:38     ` Inki Dae
2013-05-27 10:38     ` Inki Dae
2013-05-27 15:23     ` Maarten Lankhorst [this message]
2013-05-27 15:23       ` Maarten Lankhorst
2013-05-27 15:23       ` Maarten Lankhorst
2013-05-27 15:23       ` Maarten Lankhorst
2013-05-27 15:47     ` Rob Clark
2013-05-27 15:47       ` Rob Clark
2013-05-27 15:47       ` Rob Clark
2013-05-27 16:02       ` Daniel Vetter
2013-05-27 16:02         ` Daniel Vetter
2013-05-27 16:02         ` Daniel Vetter
2013-05-28  2:49   ` Inki Dae
2013-05-28  2:49     ` Inki Dae
2013-05-28  2:49     ` Inki Dae
2013-05-28  7:23     ` Maarten Lankhorst
2013-05-28  7:23       ` Maarten Lankhorst
2013-05-28  7:23       ` Maarten Lankhorst
2013-05-28  7:23       ` Maarten Lankhorst
2013-05-28  3:56   ` Inki Dae
2013-05-28  3:56     ` Inki Dae
2013-05-28  3:56     ` Inki Dae
2013-05-28  3:56     ` Inki Dae
2013-05-28 10:32     ` Daniel Vetter
2013-05-28 10:32       ` Daniel Vetter
2013-05-28 10:32       ` Daniel Vetter
2013-05-28 13:48     ` Rob Clark
2013-05-28 13:48       ` Rob Clark
2013-05-28 13:48       ` Rob Clark
2013-05-28  4:04   ` Inki Dae
2013-05-28  4:04     ` Inki Dae
2013-05-28  4:04     ` Inki Dae
2013-05-28 14:43   ` Inki Dae
2013-05-28 14:43     ` Inki Dae
2013-05-28 14:43     ` Inki Dae
2013-05-28 14:50   ` Inki Dae
2013-05-28 14:50     ` Inki Dae
2013-05-28 14:50     ` Inki Dae
2013-05-28 16:49     ` Daniel Vetter
2013-05-28 16:49       ` Daniel Vetter
2013-05-28 16:49       ` Daniel Vetter
2013-05-29  2:21   ` Inki Dae
2013-05-29  2:21     ` Inki Dae
2013-05-29  2:21     ` Inki Dae
  -- strict thread matches above, loose matches on Subject: below --
2013-06-07  9:02 Introduce a dmabuf sync " Inki Dae
2013-06-07  9:02 ` Inki Dae

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=51A37A54.1040700@canonical.com \
    --to=maarten.lankhorst@canonical.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=inki.dae@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=robdclark@gmail.com \
    --cc=yj44.cho@samsung.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: link
Be 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.