2012/1/10 Semwal, Sumit :
> On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark wrote:
>> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote:
>>> 2012/1/10 Rob Clark :
>>> at least with no IOMMU, the memory information(containing physical
>>> memory address) would be copied to vb2_xx_buf object if drm gem
>>>
On Tue, Jan 10, 2012 at 12:28:13AM +0100, Martin Peres wrote:
> Le 04/01/2012 08:20, Dan Carpenter a écrit :
> >calc_mclk() returns zero on success and negative on failure but clk is
> >a u32.
> >
> >Signed-off-by: Dan Carpenter
> >
> >diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c
> >b/drivers/gp
Le 04/01/2012 08:20, Dan Carpenter a écrit :
calc_mclk() returns zero on success and negative on failure but clk is
a u32.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nv50_pm.c
b/drivers/gpu/drm/nouveau/nv50_pm.c
index 0393721..3508de9 100644
--- a/drivers/gpu/drm/nouveau
On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark wrote:
> On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote:
>> 2012/1/10 Rob Clark :
>> at least with no IOMMU, the memory information(containing physical
>> memory address) would be copied to vb2_xx_buf object if drm gem
>> exported its own buffer and vb2
2012/1/9 Daniel Vetter :
> On Mon, Jan 09, 2012 at 07:10:25PM +0900, InKi Dae wrote:
>> 2012/1/9 Daniel Vetter :
>> > On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
>> >> I has test dmabuf based drm gem module for exynos and I found one problem.
>> >> you can refer to this test repositor
On Mon, Jan 09, 2012 at 11:56:20AM -0500, Alex Deucher wrote:
> On Mon, Jan 9, 2012 at 11:49 AM, Daniel Vetter wrote:
> > On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
> >> We would have liked to as well, but with the holidays and internal
> >> review process and people being on va
On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote:
> 2012/1/10 Rob Clark :
>> On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae wrote:
>>> note : in case of sharing a buffer between v4l2 and drm driver, the
>>> memory info would be copied vb2_xx_buf to xx_gem or xx_gem to
>>> vb2_xx_buf through sg table. in
On Fri, 2012-01-06 at 16:00 -0500, Jerome Glisse wrote:
> On Fri, Jan 06, 2012 at 02:52:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > Still having difficulty to reproduce can you reproduce with the attached
> > > printk debuging patch and provide the log (only few printk preceding the
> > > oops o
2012/1/9 Daniel Vetter :
> On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
>> I has test dmabuf based drm gem module for exynos and I found one problem.
>> you can refer to this test repository:
>> http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm-dmabuf
>
On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae wrote:
> 2012/1/10 Rob Clark :
>> On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae wrote:
>>> note : in case of sharing a buffer between v4l2 and drm driver, the
>>> memory info would be copied vb2_xx_buf to xx_gem or xx_gem to
>>> vb2_xx_buf through sg table. in
On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
> We would have liked to as well, but with the holidays and internal
> review process and people being on vacation, and the kernel merge
> window timing it didn't work out this time. Still as Jerome said, our
> VM setup is tightly coupl
On Mon, Jan 09, 2012 at 10:44:15AM -0500, Jerome Glisse wrote:
> On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
> > On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> > > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > > > Hi all,
> > > >
> > > > Meh, I've wa
2012/1/10 Rob Clark :
> On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae wrote:
>> note : in case of sharing a buffer between v4l2 and drm driver, the
>> memory info would be copied vb2_xx_buf to xx_gem or xx_gem to
>> vb2_xx_buf through sg table. in this case, only memory info is used to
>> share, not so
https://bugs.freedesktop.org/show_bug.cgi?id=27314
--- Comment #63 from Rafael Ávila de Espíndola
2012-01-09 17:11:34 PST ---
Created attachment 55359
--> https://bugs.freedesktop.org/attachment.cgi?id=55359
dmesg from kernel 3.2
I just tried KMS with kernel 3.2 and I still get a black screen
On Mon, Jan 09, 2012 at 09:06:56PM +0900, InKi Dae wrote:
> 2012/1/9 Daniel Vetter :
> > On Mon, Jan 09, 2012 at 07:10:25PM +0900, InKi Dae wrote:
> >> 2012/1/9 Daniel Vetter :
> >> > On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
> >> >> I has test dmabuf based drm gem module for exynos
You're both right. I wanted to put this patch out so that somebody
else could try this stuff out. I'll finish it when time allows.
Marek
On Mon, Jan 9, 2012 at 4:26 PM, Jerome Glisse wrote:
> On Thu, Jan 05, 2012 at 10:21:31PM -0500, Alex Deucher wrote:
>> On Thu, Jan 5, 2012 at 9:30 PM, Marek O
The second lock should be an unlock or it causes a deadlock.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 2944c78..4a9f797 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
"bo_va" is dereferenced in the error message.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 3ef58ca..2944c78 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -486,10 +486
2011/12/2 Sumit Semwal :
> This is the first step in defining a dma buffer sharing mechanism.
>
> A new buffer object dma_buf is added, with operations and API to allow easy
> sharing of this buffer object across devices.
>
> The framework allows:
> - different devices to 'attach' themselves to thi
On 9 January 2012 03:38, Linus Torvalds
wrote:
> On Fri, Jan 6, 2012 at 7:06 AM, Dave Airlie wrote:
>>
>> Now we've all agreed that the initial implementation is a good baseline
>> for us to move forward on, but its messy working with others when the core
>> code is out of tree. So we'd like to
On Mon, Jan 09, 2012 at 11:56:20AM -0500, Alex Deucher wrote:
> On Mon, Jan 9, 2012 at 11:49 AM, Daniel Vetter wrote:
> > On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
> >> We would have liked to as well, but with the holidays and internal
> >> review process and people being on va
On 01/09/2012 11:11 AM, Daniel Vetter wrote:
> On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
>
>> Hi!
>>
>> When TTM was originally written, it was assumed that GPU apertures
>> could address pages directly, and that the CPU could access those
>> pages without explicit synch
On Mon, Jan 9, 2012 at 11:49 AM, Daniel Vetter wrote:
> On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
>> We would have liked to as well, but with the holidays and internal
>> review process and people being on vacation, and the kernel merge
>> window timing it didn't work out this
On Mon, Jan 09, 2012 at 10:07:02AM +0100, Thomas Hellstrom wrote:
> On 01/06/2012 04:51 PM, James Simmons wrote:
> You can achieve what you want by either adding a new domain so you would
> have
> system, vram, agp, pcidma and object can be bound to one and only one. Or
> you
> >>
On Mon, Jan 09, 2012 at 07:10:25PM +0900, InKi Dae wrote:
> 2012/1/9 Daniel Vetter :
> > On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
> >> I has test dmabuf based drm gem module for exynos and I found one problem.
> >> you can refer to this test repository:
> >> http://git.infradead.or
On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
> Hi!
>
> When TTM was originally written, it was assumed that GPU apertures
> could address pages directly, and that the CPU could access those
> pages without explicit synchronization. The process of binding a
> page to a GPU tran
On Mon, Jan 9, 2012 at 10:44 AM, Jerome Glisse wrote:
> On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
>> On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
>> > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
>> > > Hi all,
>> > >
>> > > Meh, I've wanted to port
https://bugs.freedesktop.org/show_bug.cgi?id=44549
Michel D?nzer changed:
What|Removed |Added
Attachment #55247|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=44549
Michel D?nzer changed:
What|Removed |Added
Attachment #55245|0 |1
is obsolete|
On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
> On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > > Hi all,
> > >
> > > Meh, I've wanted to port the small set of helpers nouveau already has to
> > > handle p
Hi!
When TTM was originally written, it was assumed that GPU apertures could
address pages directly, and that the CPU could access those pages
without explicit synchronization. The process of binding a page to a GPU
translation table was a simple one-step operation, and we needed to
worry abou
On Thu, Jan 05, 2012 at 10:21:31PM -0500, Alex Deucher wrote:
> On Thu, Jan 5, 2012 at 9:30 PM, Marek Ol??k wrote:
> > People can start using transform feedback on r6xx with this.
> >
> > Strict CS checking will be implemented later.
We really need to have checking in the same patch, otherwise so
On Mon, Jan 09, 2012 at 10:07:02AM +0100, Thomas Hellstrom wrote:
> On 01/06/2012 04:51 PM, James Simmons wrote:
> You can achieve what you want by either adding a new domain so you would
> have
> system, vram, agp, pcidma and object can be bound to one and only one. Or
> you
> >>
On 01/06/2012 04:51 PM, James Simmons wrote:
>
You can achieve what you want by either adding a new domain so you would
have
system, vram, agp, pcidma and object can be bound to one and only one. Or
you
can hack your own agp ttm backend that could bind bo to agp or pc
On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > Hi all,
> >
> > Meh, I've wanted to port the small set of helpers nouveau already has to
> > handle per open fd gpu virtual address spaces to core drm, so that I could
> > reus
On Mon, Jan 9, 2012 at 7:45 AM, Dan Carpenter
wrote:
> The second lock should be an unlock or it causes a deadlock.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Alex Deucher
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 2944c78..4a9f7
On Mon, Jan 9, 2012 at 7:44 AM, Dan Carpenter
wrote:
> "bo_va" is dereferenced in the error message.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Alex Deucher
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 3ef58ca..2944c78 100644
> ---
On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae wrote:
> note : in case of sharing a buffer between v4l2 and drm driver, the
> memory info would be copied vb2_xx_buf to xx_gem or xx_gem to
> vb2_xx_buf through sg table. in this case, only memory info is used to
> share, not some objects.
which v4l2/vb2
On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
> I has test dmabuf based drm gem module for exynos and I found one problem.
> you can refer to this test repository:
> http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm-dmabuf
>
> at this repository, I adde
On Mon, Jan 9, 2012 at 11:49 AM, Daniel Vetter wrote:
> On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
>> We would have liked to as well, but with the holidays and internal
>> review process and people being on vacation, and the kernel merge
>> window timing it didn't work out this
On Mon, Jan 09, 2012 at 10:07:02AM +0100, Thomas Hellstrom wrote:
> On 01/06/2012 04:51 PM, James Simmons wrote:
> You can achieve what you want by either adding a new domain so you would
> have
> system, vram, agp, pcidma and object can be bound to one and only one. Or
> you
> >>
On Mon, Jan 09, 2012 at 11:07:44AM -0500, Alex Deucher wrote:
> We would have liked to as well, but with the holidays and internal
> review process and people being on vacation, and the kernel merge
> window timing it didn't work out this time. Still as Jerome said, our
> VM setup is tightly coupl
On Mon, Jan 09, 2012 at 10:44:15AM -0500, Jerome Glisse wrote:
> On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
> > On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> > > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > > > Hi all,
> > > >
> > > > Meh, I've wa
On Sun, 08 Jan 2012 00:48:56 -0800, Jeremy Huddleston
wrote:
> Well that's a ppc box, so maybe endianness issues... ?
Oh, that's probably it. But I'd say it's more a bug that Intel libdrm
is being built on ppc.
pgpUm6kwWVbPV.pgp
Description: PGP signature
_
nt was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120109/9d5b6d44/attachment.pgp>
On Mon, Jan 9, 2012 at 8:10 AM, Daniel Vetter wrote:
> On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
>> I has test dmabuf based drm gem module for exynos and I found one problem.
>> you can refer to this test repository:
>> http://git.infradead.org/users/kmpark/linux-samsung/shortlog/r
On Mon, Jan 9, 2012 at 10:44 AM, Jerome Glisse wrote:
> On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
>> On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
>> > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
>> > > Hi all,
>> > >
>> > > Meh, I've wanted to port
On Mon, Jan 09, 2012 at 09:06:56PM +0900, InKi Dae wrote:
> 2012/1/9 Daniel Vetter :
> > On Mon, Jan 09, 2012 at 07:10:25PM +0900, InKi Dae wrote:
> >> 2012/1/9 Daniel Vetter :
> >> > On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
> >> >> I has test dmabuf based drm gem module for exynos
You're both right. I wanted to put this patch out so that somebody
else could try this stuff out. I'll finish it when time allows.
Marek
On Mon, Jan 9, 2012 at 4:26 PM, Jerome Glisse wrote:
> On Thu, Jan 05, 2012 at 10:21:31PM -0500, Alex Deucher wrote:
>> On Thu, Jan 5, 2012 at 9:30 PM, Marek O
On Mon, Jan 09, 2012 at 09:31:16AM +0100, Daniel Vetter wrote:
> On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> > On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > > Hi all,
> > >
> > > Meh, I've wanted to port the small set of helpers nouveau already has to
> > > handle p
On Thu, Jan 05, 2012 at 10:21:31PM -0500, Alex Deucher wrote:
> On Thu, Jan 5, 2012 at 9:30 PM, Marek Olšák wrote:
> > People can start using transform feedback on r6xx with this.
> >
> > Strict CS checking will be implemented later.
We really need to have checking in the same patch, otherwise so
On Mon, Jan 09, 2012 at 10:07:02AM +0100, Thomas Hellstrom wrote:
> On 01/06/2012 04:51 PM, James Simmons wrote:
> You can achieve what you want by either adding a new domain so you would
> have
> system, vram, agp, pcidma and object can be bound to one and only one. Or
> you
> >>
On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae wrote:
> note : in case of sharing a buffer between v4l2 and drm driver, the
> memory info would be copied vb2_xx_buf to xx_gem or xx_gem to
> vb2_xx_buf through sg table. in this case, only memory info is used to
> share, not some objects.
which v4l2/vb2
On Mon, Jan 9, 2012 at 7:45 AM, Dan Carpenter wrote:
> The second lock should be an unlock or it causes a deadlock.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Alex Deucher
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 2944c78..4a9f79
On Mon, Jan 9, 2012 at 7:44 AM, Dan Carpenter wrote:
> "bo_va" is dereferenced in the error message.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Alex Deucher
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 3ef58ca..2944c78 100644
> ---
The second lock should be an unlock or it causes a deadlock.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 2944c78..4a9f797 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
"bo_va" is dereferenced in the error message.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 3ef58ca..2944c78 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -486,10 +486
2012/1/9 Daniel Vetter :
> On Mon, Jan 09, 2012 at 07:10:25PM +0900, InKi Dae wrote:
>> 2012/1/9 Daniel Vetter :
>> > On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
>> >> I has test dmabuf based drm gem module for exynos and I found one problem.
>> >> you can refer to this test repositor
On 01/09/2012 11:11 AM, Daniel Vetter wrote:
On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
Hi!
When TTM was originally written, it was assumed that GPU apertures
could address pages directly, and that the CPU could access those
pages without explicit synchronization. The
https://bugs.freedesktop.org/show_bug.cgi?id=44549
Michel Dänzer changed:
What|Removed |Added
Attachment #55247|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=44549
Michel Dänzer changed:
What|Removed |Added
Attachment #55245|0 |1
is obsolete|
On Mon, Jan 09, 2012 at 07:10:25PM +0900, InKi Dae wrote:
> 2012/1/9 Daniel Vetter :
> > On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
> >> I has test dmabuf based drm gem module for exynos and I found one problem.
> >> you can refer to this test repository:
> >> http://git.infradead.or
2012/1/9 Daniel Vetter :
> On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
>> I has test dmabuf based drm gem module for exynos and I found one problem.
>> you can refer to this test repository:
>> http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm-dmabuf
>
On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote:
> Hi!
>
> When TTM was originally written, it was assumed that GPU apertures
> could address pages directly, and that the CPU could access those
> pages without explicit synchronization. The process of binding a
> page to a GPU tran
Hi!
When TTM was originally written, it was assumed that GPU apertures could
address pages directly, and that the CPU could access those pages
without explicit synchronization. The process of binding a page to a GPU
translation table was a simple one-step operation, and we needed to
worry abo
On 01/06/2012 04:51 PM, James Simmons wrote:
You can achieve what you want by either adding a new domain so you would have
system, vram, agp, pcidma and object can be bound to one and only one. Or you
can hack your own agp ttm backend that could bind bo to agp or pci or
both at the same time
On Sun, Jan 08, 2012 at 05:56:31PM -0500, Jerome Glisse wrote:
> On Sun, Jan 8, 2012 at 9:05 AM, Daniel Vetter wrote:
> > Hi all,
> >
> > Meh, I've wanted to port the small set of helpers nouveau already has to
> > handle per open fd gpu virtual address spaces to core drm, so that I could
> > reus
On Mon, Jan 9, 2012 at 8:10 AM, Daniel Vetter wrote:
> On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
>> I has test dmabuf based drm gem module for exynos and I found one problem.
>> you can refer to this test repository:
>> http://git.infradead.org/users/kmpark/linux-samsung/shortlog/r
On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
> I has test dmabuf based drm gem module for exynos and I found one problem.
> you can refer to this test repository:
> http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm-dmabuf
>
> at this repository, I adde
69 matches
Mail list logo
