If we hit an error here, then we should unlock and unreference obj
before returning.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 852642d..6de6130 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -2
On 20 March 2012 03:12, Rob Clark wrote:
> From: Rob Clark
>
> Otherwise subsystems will get this wrong and end up with a second
> export ioctl with the flag and O_CLOEXEC support added.
>
> Signed-off-by: Rob Clark
> Reviewed-by: Daniel Vetter
> ---
> Updated version of Daniel's original docum
On 19 March 2012 07:24, Rob Clark wrote:
> On Sun, Mar 18, 2012 at 6:34 PM, Daniel Vetter wrote:
>> v2: Fix spelling issues noticed by Rob Clark.
>>
>> Signed-off-by: Daniel Vetter
>
> Signed-off-by: Rob Clark
Thanks; applied to for-next.
>
BR,
~me.
On 20 March 2012 04:32, Daniel Vetter wrote:
> Big differences to other contenders in the field (like ion) is
> that this also supports highmem, so we have to split up the cpu
> access from the kernel side into a prepare and a kmap step.
>
> Prepare is allowed to fail and should do everything requ
On 19 March 2012 05:04, Daniel Vetter wrote:
> The mutex protects the attachment list and hence needs to be held
> around the callbakc to the exporters (optional) attach/detach
> functions.
>
> Holding the mutex around the map/unmap calls doesn't protect any
> dma_buf state. Exporters need to prop
On Wed, Mar 21, 2012 at 10:46:14AM -0700, Rebecca Schultz Zavin wrote:
> I want to make sure I understand how this would work. I've been planning
> on making cache maintenance implicit, and most of the corresponding
> userspace components I've seen for android expect to do implicit cache
> mainten
https://bugzilla.kernel.org/show_bug.cgi?id=42972
--- Comment #4 from Petr Pisar 2012-03-21 21:43:03 ---
Created an attachment (id=72671)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72671)
Xorg log 3.3.0
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
https://bugzilla.kernel.org/show_bug.cgi?id=42972
--- Comment #3 from Petr Pisar 2012-03-21 21:42:35 ---
Created an attachment (id=72670)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72670)
Xorg log 3.2.11
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
https://bugzilla.kernel.org/show_bug.cgi?id=42972
--- Comment #2 from Petr Pisar 2012-03-21 21:41:52 ---
Created an attachment (id=72669)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72669)
dmesg 3.3.0
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
https://bugzilla.kernel.org/show_bug.cgi?id=42972
--- Comment #1 from Petr Pisar 2012-03-21 21:41:24 ---
Created an attachment (id=72668)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72668)
dmesg 3.2.11
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--
https://bugzilla.kernel.org/show_bug.cgi?id=42972
Summary: Missing EDID through NV11 (nouveau) driver causes
suboptimal modeline
Product: Drivers
Version: 2.5
Kernel Version: 3.3.0
Platform: All
OS/Version: Linux
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #43 from Alexandre Demers 2012-03-21
21:11:41 PDT ---
Created attachment 58846
--> https://bugs.freedesktop.org/attachment.cgi?id=58846
Different error message
Running RenderFeatTest.bin64 with yesterday's gits still crash at the
https://bugzilla.kernel.org/show_bug.cgi?id=42876
--- Comment #4 from Sergio 2012-03-21 20:07:05 ---
(In reply to comment #3)
> No problem with parameter acpi=off noapic
It worked for me in Fedora 16 with 3.2.10-2 kernel but, don't support for dual
screen configuration and GNOME 3 only work
From: Jerome Glisse
For 6xx+. Required for mesa to use htile support for HiZ/HiS.
Userspace will check radeon version 2.14 with is bumped either
by tiling patch or stream out patch. This patch only add support
for htile relocation which should be enough for any userspace
to implement the hyperz
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #19 from Jonathan Nieder 2012-03-21
10:49:34 PDT ---
(In reply to comment #18)
> Today I am using kernel 3.2.0-2-amd64 .
> The problem still exists in exactly the same way - the first hibernate
> always works perfectly fine - the s
On Wed, Mar 21, 2012 at 5:31 PM, InKi Dae wrote:
> Hi Linus,
>
> now mainline has a duplicated patch set for exynos drm driver so
> please revert the patch below from mainline before merging with
> drm-next to avoid conflict.
> subject: drm exynos: use drm_fb_helper_set_par directly
> commit id: 3
From: Rob Clark
Minor error path clean-up.
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_dmm_tiler.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 852d944..33c1d
On Wed, Mar 21, 2012 at 3:25 PM, Daniel Vetter wrote:
> On Wed, Mar 21, 2012 at 10:46:14AM -0700, Rebecca Schultz Zavin wrote:
>> I want to make sure I understand how this would work. I've been planning
>> on making cache maintenance implicit, and most of the corresponding
>> userspace components
On Wed, Mar 21, 2012 at 8:45 AM, Rob Clark wrote:
> On Tue, Mar 20, 2012 at 3:53 PM, Daniel Vetter wrote:
>> Let's have some competition here for dma_buf mmap support ;-)
>>
>> Compared to Rob Clarke's RFC I've ditched the prepare/finish hooks
>> and corresponding ioctls on the dma_buf file. The
On Wed, Mar 21, 2012 at 8:45 AM, Rob Clark wrote:
> On Tue, Mar 20, 2012 at 3:53 PM, Daniel Vetter
> wrote:
> > Let's have some competition here for dma_buf mmap support ;-)
> >
> > Compared to Rob Clarke's RFC I've ditched the prepare/finish hooks
> > and corresponding ioctls on the dma_buf fil
On Mon, Mar 19, 2012 at 10:21:28AM -0700, Keith Packard wrote:
> <#part sign=pgpmime>
> On Mon, 19 Mar 2012 15:53:54 +0100, Stanislaw Gruszka
> wrote:
>
> > Keith, is there a chance that this bug can be fixed by i915 team?
>
> Yes, I'm working on figuring out how to actually reproduce this and
On Wed, Mar 21, 2012 at 03:44:38PM -0700, Rebecca Schultz Zavin wrote:
> Couldn't this just as easily be handled by not having those mappings
> be mapped cached or write combine to userspace? They'd be coherent,
> just slow. I'm not sure we can actually say that all these cpu access
> are necessa
From: Jerome Glisse
For 6xx+. Required for mesa to use htile support for HiZ/HiS.
Userspace will check radeon version 2.14 with is bumped either
by tiling patch or stream out patch. This patch only add support
for htile relocation which should be enough for any userspace
to implement the hyperz
On Mon, Mar 19, 2012 at 10:21:28AM -0700, Keith Packard wrote:
> <#part sign=pgpmime>
> On Mon, 19 Mar 2012 15:53:54 +0100, Stanislaw Gruszka redhat.com> wrote:
>
> > Keith, is there a chance that this bug can be fixed by i915 team?
>
> Yes, I'm working on figuring out how to actually reproduce
On Wed, Mar 21, 2012 at 3:25 PM, Daniel Vetter wrote:
> On Wed, Mar 21, 2012 at 10:46:14AM -0700, Rebecca Schultz Zavin wrote:
>> I want to make sure I understand how this would work. ?I've been planning
>> on making cache maintenance implicit, and most of the corresponding
>> userspace components
On Wed, Mar 21, 2012 at 3:14 PM, Stanislaw Gruszka
wrote:
> On Mon, Mar 19, 2012 at 10:21:28AM -0700, Keith Packard wrote:
>> <#part sign=pgpmime>
>> On Mon, 19 Mar 2012 15:53:54 +0100, Stanislaw Gruszka > redhat.com> wrote:
>>
>> > Keith, is there a chance that this bug can be fixed by i915 team
On Wed, Mar 21, 2012 at 10:46:14AM -0700, Rebecca Schultz Zavin wrote:
> I want to make sure I understand how this would work. I've been planning
> on making cache maintenance implicit, and most of the corresponding
> userspace components I've seen for android expect to do implicit cache
> mainten
https://bugzilla.kernel.org/show_bug.cgi?id=42972
--- Comment #4 from Petr Pisar 2012-03-21 21:43:03 ---
Created an attachment (id=72671)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72671)
Xorg log 3.3.0
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
https://bugzilla.kernel.org/show_bug.cgi?id=42972
--- Comment #3 from Petr Pisar 2012-03-21 21:42:35 ---
Created an attachment (id=72670)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72670)
Xorg log 3.2.11
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
https://bugzilla.kernel.org/show_bug.cgi?id=42972
--- Comment #2 from Petr Pisar 2012-03-21 21:41:52 ---
Created an attachment (id=72669)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72669)
dmesg 3.3.0
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
https://bugzilla.kernel.org/show_bug.cgi?id=42972
--- Comment #1 from Petr Pisar 2012-03-21 21:41:24 ---
Created an attachment (id=72668)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72668)
dmesg 3.2.11
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--
https://bugzilla.kernel.org/show_bug.cgi?id=42972
Summary: Missing EDID through NV11 (nouveau) driver causes
suboptimal modeline
Product: Drivers
Version: 2.5
Kernel Version: 3.3.0
Platform: All
OS/Version: Linux
From: Rob Clark
Minor error path clean-up.
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_dmm_tiler.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 852d944..33c1d
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #42 from Alexandre Demers
2012-03-21 07:35:36 PDT ---
(In reply to comment #41)
> Are you still getting any messages like the following in your dmesg with the
> latest mesa from git?
>
> radeon :01:00.0: offset 0x20 is in re
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So s
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So s
Hi Keith,
On Sunday 29 January 2012 02:34:05 am Keith Packard wrote:
> On Sat, 28 Jan 2012 11:08:58 +0100, Jean Delvare
> wrote:
> > The VESA specification suggests a 2.2 ms timeout on DDC channels.
> > Use exactly that (as the i915 driver does) instead of hard-coding a
> > jiffy count.
>
> The
https://bugzilla.kernel.org/show_bug.cgi?id=42876
--- Comment #4 from Sergio 2012-03-21 20:07:05 ---
(In reply to comment #3)
> No problem with parameter acpi=off noapic
It worked for me in Fedora 16 with 3.2.10-2 kernel but, don't support for dual
screen configuration and GNOME 3 only work
From: Rob Clark
Signed-off-by: Rob Clark
---
tests/modetest/modetest.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 36bdfff..819724a 100644
--- a/tests/modetest/modetest.c
From: Rob Clark
Signed-off-by: Rob Clark
---
tests/modetest/modetest.c | 151 ++---
1 files changed, 142 insertions(+), 9 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 2936de0..36bdfff 100644
--- a/tests/modetest/
From: Rob Clark
Signed-off-by: Rob Clark
---
tests/modetest/modetest.c | 166 ++---
1 files changed, 157 insertions(+), 9 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1e4ec91..2936de0 100644
--- a/tests/modetest/
From: Rob Clark
This adds libdrm_omap helper layer (as used by xf86-video-omap,
omapdrmtest, etc).
Signed-off-by: Rob Clark
---
Makefile.am |6 +-
configure.ac | 12 ++
omap/Makefile.am | 22
omap/libdrm_omap.pc.in| 11 ++
omap/omap_drm.c
On 20.03.2012 22:17, alexdeucher at gmail.com wrote:
> From: Alex Deucher
>
> This patch set adds support for SI (Southern Islands discrete
> GPUs) and TN (Trinity APU). The patches are available here
> as well:
> http://people.freedesktop.org/~agd5f/si_tn/
> New ucode for SI (TAHITI, PITCAIRN, VE
? ??2012-03-20 ? 23:03 +0100?Pali Roh?r ???
> >
> > Another doubt is the latest statement in _BCM, it emit a BEVT event:
> >
> > Signal (\_SB.BEVT)
> >
> > Only HKFR(HotkeyFunctionResponse) method is waiting this event, it
> > should related to how the HP implement brightness function key on
> >
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #18 from Rolf 2012-03-21 05:01:34 PDT ---
On 20.03.2012 19:47, bugzilla-daemon at freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=43278
>
> --- Comment #17 from Jonathan Nieder 2012-03-20
> 11:47:35 PDT ---
> (
Hi Keith,
Sorry for the late reply.
On Sunday 29 January 2012 02:26:25 am Keith Packard wrote:
> On Sat, 28 Jan 2012 11:07:09 +0100, Jean Delvare
> wrote:
> > A udelay value of 20 leads to an I2C bus running at only 25 kbps.
> > I2C devices can typically operate faster than this, 50 kbps should
Hi, Dave.
as you pointed out, we have removed g2d driver from this patch set and
rebased virtual display driver. for g2d driver, we will consolidate the
security issue you pointed out for next time.
Please pull from
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-next
this
From: Rob Clark
Signed-off-by: Rob Clark
---
tests/modetest/modetest.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 36bdfff..819724a 100644
--- a/tests/modetest/modetest.c
From: Rob Clark
Signed-off-by: Rob Clark
---
tests/modetest/modetest.c | 151 ++---
1 files changed, 142 insertions(+), 9 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 2936de0..36bdfff 100644
--- a/tests/modetest/
From: Rob Clark
Signed-off-by: Rob Clark
---
tests/modetest/modetest.c | 166 ++---
1 files changed, 157 insertions(+), 9 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1e4ec91..2936de0 100644
--- a/tests/modetest/
From: Rob Clark
This adds libdrm_omap helper layer (as used by xf86-video-omap,
omapdrmtest, etc).
Signed-off-by: Rob Clark
---
Makefile.am |6 +-
configure.ac | 12 ++
omap/Makefile.am | 22
omap/libdrm_omap.pc.in| 11 ++
omap/omap_drm.c
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #19 from Jonathan Nieder 2012-03-21 10:49:34
PDT ---
(In reply to comment #18)
> Today I am using kernel 3.2.0-2-amd64 .
> The problem still exists in exactly the same way - the first hibernate
> always works perfectly fine - the s
On Wed, Mar 21, 2012 at 8:45 AM, Rob Clark wrote:
> On Tue, Mar 20, 2012 at 3:53 PM, Daniel Vetter
> wrote:
>> Let's have some competition here for dma_buf mmap support ;-)
>>
>> Compared to Rob Clarke's RFC I've ditched the prepare/finish hooks
>> and corresponding ioctls on the dma_buf file. T
On Wed, Mar 21, 2012 at 5:31 PM, InKi Dae wrote:
> Hi Linus,
>
> now mainline has a duplicated patch set for exynos drm driver so
> please revert the patch below from mainline before merging with
> drm-next to avoid conflict.
> subject: drm exynos: use drm_fb_helper_set_par directly
> commit id: 3
Hi Dave,
> -Original Message-
> From: Dave Airlie [mailto:airlied at gmail.com]
> Sent: Tuesday, March 20, 2012 6:49 PM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com; sw0312.kim at samsung.com
> Subject: Re: [PATCH v2 00/14] up
Hi Linus,
This is the main drm pull request, I'm probably going to send two more
smaller ones, will explain below.
This contains a patch that is also in the fbdev tree, but it should be the
same patch, it added an API for hot unplugging framebuffer devices, and I
need that API for a new drive
om the buffer into kernel address space.
> > * @kunmap: [optional] unmaps a page from the buffer.
> > + * @mmap: used to expose the backing storage to userspace. Note that the
> > + * mapping needs to be coherent - if the exporter doesn't directly
> > + * support this, it needs to fake coherency by shooting down any
> ptes
> > + * when transitioning away from the cpu domain.
> > */
> > struct dma_buf_ops {
> >int (*attach)(struct dma_buf *, struct device *,
> > @@ -92,6 +96,8 @@ struct dma_buf_ops {
> >void (*kunmap_atomic)(struct dma_buf *, unsigned long, void *);
> >void *(*kmap)(struct dma_buf *, unsigned long);
> >void (*kunmap)(struct dma_buf *, unsigned long, void *);
> > +
> > + int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
> > };
> >
> > /**
> > @@ -167,6 +173,9 @@ void *dma_buf_kmap_atomic(struct dma_buf *, unsigned
> long);
> > void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *);
> > void *dma_buf_kmap(struct dma_buf *, unsigned long);
> > void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
> > +
> > +int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
> > +unsigned long);
> > #else
> >
> > static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf
> *dmabuf,
> > @@ -247,6 +256,13 @@ static inline void dma_buf_kunmap(struct dma_buf *,
> unsigned long,
> > void *)
> > {
> > }
> > +
> > +static inline int dma_buf_mmap(struct dma_buf *,
> > + struct vm_area_struct *vma,
> > + unsigned long pgoff)
> > +{
> > + return -ENODEV;
> > +}
> > #endif /* CONFIG_DMA_SHARED_BUFFER */
> >
> > #endif /* __DMA_BUF_H__ */
> > --
> > 1.7.7.5
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120321/a6ad5451/attachment-0001.htm>
On Tue, Mar 20, 2012 at 3:53 PM, Daniel Vetter
wrote:
> Let's have some competition here for dma_buf mmap support ;-)
>
> Compared to Rob Clarke's RFC I've ditched the prepare/finish hooks
> and corresponding ioctls on the dma_buf file. The major reason for
> that is that many people seem to be u
https://bugs.freedesktop.org/show_bug.cgi?id=47606
--- Comment #1 from Michel D?nzer 2012-03-21 03:08:21
PDT ---
Please attach dmesg output.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=47606
Michel D?nzer changed:
What|Removed |Added
AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at
lists.freedesktop
rr;
> > > > }
> > > > }
> > >
> out:
> > > > ttm->caching_state = c_state;
> > > >
> > > > return 0;
>
> Is the problem with calling page change twice making the machine slow?
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120321/9f991ca4/attachment.htm>
On Wed, Mar 21, 2012 at 9:30 AM, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, the va
On Tue, Mar 20, 2012 at 3:53 PM, Daniel Vetter wrote:
> Let's have some competition here for dma_buf mmap support ;-)
>
> Compared to Rob Clarke's RFC I've ditched the prepare/finish hooks
> and corresponding ioctls on the dma_buf file. The major reason for
> that is that many people seem to be un
On Wed, Mar 21, 2012 at 3:14 PM, Stanislaw Gruszka wrote:
> On Mon, Mar 19, 2012 at 10:21:28AM -0700, Keith Packard wrote:
>> <#part sign=pgpmime>
>> On Mon, 19 Mar 2012 15:53:54 +0100, Stanislaw Gruszka
>> wrote:
>>
>> > Keith, is there a chance that this bug can be fixed by i915 team?
>>
>> Ye
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #42 from Alexandre Demers 2012-03-21
07:35:36 PDT ---
(In reply to comment #41)
> Are you still getting any messages like the following in your dmesg with the
> latest mesa from git?
>
> radeon :01:00.0: offset 0x20 is in re
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So s
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So s
Hi Keith,
On Sunday 29 January 2012 02:34:05 am Keith Packard wrote:
> On Sat, 28 Jan 2012 11:08:58 +0100, Jean Delvare
> wrote:
> > The VESA specification suggests a 2.2 ms timeout on DDC channels.
> > Use exactly that (as the i915 driver does) instead of hard-coding a
> > jiffy count.
>
> The
On Wed, Mar 21, 2012 at 9:30 AM, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, the va
https://bugs.freedesktop.org/show_bug.cgi?id=43278
--- Comment #18 from Rolf 2012-03-21 05:01:34 PDT ---
On 20.03.2012 19:47, bugzilla-dae...@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=43278
>
> --- Comment #17 from Jonathan Nieder 2012-03-20 11:47:35
> PDT ---
> (In
Hi Keith,
Sorry for the late reply.
On Sunday 29 January 2012 02:26:25 am Keith Packard wrote:
> On Sat, 28 Jan 2012 11:07:09 +0100, Jean Delvare
> wrote:
> > A udelay value of 20 leads to an I2C bus running at only 25 kbps.
> > I2C devices can typically operate faster than this, 50 kbps should
On 20.03.2012 22:17, alexdeuc...@gmail.com wrote:
From: Alex Deucher
This patch set adds support for SI (Southern Islands discrete
GPUs) and TN (Trinity APU). The patches are available here
as well:
http://people.freedesktop.org/~agd5f/si_tn/
New ucode for SI (TAHITI, PITCAIRN, VERDE) and TN (A
Hi Linus,
This is the main drm pull request, I'm probably going to send two more
smaller ones, will explain below.
This contains a patch that is also in the fbdev tree, but it should be the
same patch, it added an API for hot unplugging framebuffer devices, and I
need that API for a new drive
https://bugs.freedesktop.org/show_bug.cgi?id=47606
--- Comment #1 from Michel Dänzer 2012-03-21 03:08:21 PDT
---
Please attach dmesg output.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=47606
Michel Dänzer changed:
What|Removed |Added
AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
75 matches
Mail list logo
