way to run "module-init-tools" without getting
> "stop/waiting"?
This is a completely unrelated question and I don't even understand it.
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
m-sensors.org/pipermail/lm-sensors/2012-April/035847.html
> http://lists.freedesktop.org/archives/xorg/2011-January/052239.html
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
> Cc: Jean Delvare
> ---
> drivers/gpu/drm/radeon/radeon_i2c.c |4
> 1 files
rnel: [13464.936336]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317]
> >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> >> remainder is 208 Apr 26 13:06:57 dtor-d630 kern
s well.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=36221
>
> Cc: Jean Delvare
> Signed-off-by: Alex Deucher
Good catch, applied, thanks. I'll also push this to the stable kernel
trees (from .38 down to .34.)
> ---
> drivers/i2c/algos/i2c-algo-bit.c | 21
On Tue, 3 May 2011 13:32:36 -0400, Alex Deucher wrote:
> The most common use of the radeon i2c buses is for ddc.
>
> Signed-off-by: Alex Deucher
> Cc: Jean Delvare
Acked-by: Jean Delvare
> ---
> drivers/gpu/drm/radeon/radeon_i2c.c |2 ++
> 1 files changed, 2 inser
liar with git, a git bisection would help
too.
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
shouldn't be too difficult. Just clone Linus' kernel tree
and follow the git bisect manual page:
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Revert commit 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f. This fixes a
hang when loading the eeprom driver (see bug #35572.) GMBUS will be
re-enabled later, differently.
Signed-off-by: Jean Delvare
Reported-by: Marek Otahal
Tested-by: Yermandu Patapitafious
Tested-by: Andrew Lutomirski
Acked-by
Hi Florian,
On Sat, 11 Jun 2011 13:28:15 +0200, Florian Mickler wrote:
> On Sat, 04 Jun 2011 19:34:56 -
> Jean Delvare wrote:
>
> > Revert commit 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f. This fixes a
> > hang when loading the eeprom driver (see bug #35572.) GMBUS w
Hi Dave,
On Tue, 14 Jun 2011 13:39:35 +1000, Dave Airlie wrote:
> On Sat, Jun 11, 2011 at 10:58 PM, Jean Delvare wrote:
> > Hi Florian,
> >
> > On Sat, 11 Jun 2011 13:28:15 +0200, Florian Mickler wrote:
> >> On Sat, 04 Jun 2011 19:34:56 -
> >> Jean De
radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 6df4e3c..14710fc 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -515,6 +515,7 @@ extern void radeon_i2c_put_byte(struct radeon_i2c_chan
> *i2c,
> extern void radeon_router_select_ddc_port(struct radeon_connector
> *radeon_connector);
> extern void radeon_router_select_cd_port(struct radeon_connector
> *radeon_connector);
> extern bool radeon_ddc_probe(struct radeon_connector *radeon_connector);
> +extern bool radeon_ddc_edid_probe(struct radeon_connector *radeon_connector);
> extern int radeon_ddc_get_modes(struct radeon_connector *radeon_connector);
>
> extern struct drm_encoder *radeon_best_encoder(struct drm_connector
> *connector);
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm_connector *connector,
int hdisplay, int vdisplay);
+extern int drm_edid_header_valid(const u8 *raw_edid);
extern bool drm_edid_is_valid(struct edid *edid);
struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
int hsize, int vsize, int fresh);
But if Alex believes that the case is rare enough that a board-specific
workaround is better, that's totally fine with me too. He is the master!
> Point 4:
> I've checked your comments and updated the patch. Hopefully, it fits now
> better to the linux kernel coding style. Thank you for the hints.
>
>
> A subsequent mail will contain the updated patch proposal.
[1] I wonder why radeon_router_select_ddc_port() isn't part of
pre_xfer().
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
t the ineffective usage
> > of the i2c bus. But I can also restore the old code. What's your
> > preference?
>
> Ah, I missed that. Let's make that a separate patch, or fix it when
> you add support for the extended edid check.
>
> Thanks for fixing this up.
I'll send a patch for that one, as I found it. It is indeed unrelated
to the problem, I mentioned it only to avoid the same mistake in a
newly added function.
It's a very minor cleanup / optimization, BTW.
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
r one.
Signed-off-by: Jean Delvare
Cc: David Airlie
---
drivers/gpu/drm/drm_edid.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-3.0-rc4.orig/drivers/gpu/drm/drm_edid.c 2011-06-22
16:55:11.0 +0200
+++ linux-3.0-rc4/drivers/gpu/drm/drm_edid.c2011-06-27
No need for 2-byte buffers, we only send one byte and receive one
byte.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_i2c.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- linux-3.0-rc4.orig/drivers/gpu/drm/radeon
On Mon, 27 Jun 2011 22:44:42 +0200, Jean Delvare wrote:
> No need for 2-byte buffers, we only send one byte and receive one
> byte.
>
> Signed-off-by: Jean Delvare
> Cc: David Airlie
> Cc: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_i2c.c |7 +++
> 1
nce. I
would guess that you know what backend is present on a system when you
try to identify it.
At this point, I see the work needed to review your patches, the risk
of regressions due to the large size of the patch set, but I don't see
any immediate benefit. Thus I am not g
to.
* Fix swapped characters in the string used to name the GPIO-based
adapter.
* Add missing comma in gmbus name table.
Signed-off-by: Jean Delvare
Tested-by: Randy Dunlap
---
Chris, what's the status of this patch? I think it should go to Linus
ASAP.
drivers/gpu/drm/i915/intel_i2c.c | 11
e
check to i2c-core. This will avoid future bug reports which we don't
know how to process because we have no idea what the underlying faulty
I2C adapter is.
> Noticed by Ari Savolainen.
>
> Signed-off-by: Alex Deucher
> Cc: Ari Savolainen
> Cc: Jean Delvare
> Cc: sta..
On Thu, 18 Nov 2010 11:37:18 -0500, Alex Deucher wrote:
> As per advice from Jean Delvare.
>
> Signed-off-by: Alex Deucher
> Cc: Jean Delvare
Thanks Alex.
Acked-by: Jean Delvare
> ---
> drivers/gpu/drm/radeon/radeon_i2c.c |9 ++---
> 1 files changed, 6 inser
this bug? If not, I
can start a bisection.
I can also provide any additional data you need for investigation.
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Alex,
Thanks for your fast answer.
On Sun, 21 Nov 2010 11:12:32 -0500, Alex Deucher wrote:
> On Sun, Nov 21, 2010 at 9:38 AM, Jean Delvare wrote:
> > Running 2.6.37-rc2-git7 on x86_64, wine fails to start. I get the
> > following error in the kernel logs:
> >
&g
Hi Alex,
On Sun, 21 Nov 2010 19:57:23 -0500, Alex Deucher wrote:
> On Sun, Nov 21, 2010 at 1:51 PM, Jean Delvare wrote:
> > On Sun, 21 Nov 2010 11:12:32 -0500, Alex Deucher wrote:
> >> It's probably this patch:
> >> http://git.kernel.org/?p=linux/kernel/git/torva
Hi Alex, David,
On Sun, 21 Nov 2010 11:12:32 -0500, Alex Deucher wrote:
> On Sun, Nov 21, 2010 at 9:38 AM, Jean Delvare wrote:
> > Running 2.6.37-rc2-git7 on x86_64, wine fails to start. I get the
> > following error in the kernel logs:
> >
> > radeon :07:00.0
Hi Alex,
On Sun, 12 Dec 2010 23:33:42 -0500, Alex Deucher wrote:
> On Sun, Dec 12, 2010 at 7:31 PM, Alex Deucher wrote:
> > On Fri, Dec 10, 2010 at 7:01 AM, Jean Delvare wrote:
> >> Any progress on this? Linus' latest kernel (2.6.37-rc5-git3) still has
> >> the p
ode is wrong, and give up and become a farmer.
I wish you success in you upcoming endeavour! :D
I know what you mean. The kernel/user-space interface is sometimes very
difficult to live with.
--
Jean Delvare
___
dri-devel mailing li
I can help debugging this by providing extra information
or doing tests. This is low priority for me (I don't normally do 3D on
that machine) but you probably want the bug fixed before 2.6.34-final.
--
Jean Delvare
___
dri-devel mailing list
dri
On Wed, 5 May 2010 16:40:54 +0200, Jean Delvare wrote:
> With kernels 2.6.34-rc6-git{1,2,3}, glxgears crashes the radeon driver
> on my machine. Kernel 2.6.33.3 works fine. (...)
Still happens with -git6. Should I start bisecting?
--
Jean D
On Sun, 9 May 2010 13:36:35 +0200, Jean Delvare wrote:
> On Wed, 5 May 2010 16:40:54 +0200, Jean Delvare wrote:
> > With kernels 2.6.34-rc6-git{1,2,3}, glxgears crashes the radeon driver
> > on my machine. Kernel 2.6.33.3 works fine. (...)
>
> Still happens with -git6. Sho
Yes, it's me again ;)
On Sun, 9 May 2010 22:58:30 +0200, Jean Delvare wrote:
> Bisection says that the faulty commit is:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b4fe945405e477cded91772b4fec854705443dd5
>
> It doesn't revert cleanly
_each_drv() and from every
other function which raises this problem, or we must disable that new
type of warning gcc 4.6.0 generates. Depends which warnings we value
more, as we can't sanely have both.
> mutex_unlock(&core_lock);
>
> return 0;
--
Jean Delvare
_
On Tue, 15 Jun 2010 09:20:39 -0700, David Daney wrote:
> On 06/15/2010 04:40 AM, Jean Delvare wrote:
> > __process_new_adapter() calls i2c_do_add_adapter() which always returns
> > 0. Why should I check the return value of bus_for_each_drv() when I
> > know it will always
"radeon_atom_get_hpd_info_from_gpio":
drivers/gpu/drm/radeon/radeon_atombios.c:261: warning: "hpd.plugged_state" is
used uninitialized in this function
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex Deucher
---
As a side, note, passing whole structures on the
t is related (but it would certainly be nice to solve that
problem too.)
Let me know if I can provide more information, or help in any way with
debugging this issue.
Thanks,
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lis
On Thu, 30 Sep 2010 15:18:27 +0200, Jean Delvare wrote:
> I am running kernel 2.6.36-rc6 on a Radeon HD4350 (RV710), and I see
> the following error messages in the logs:
>
> Sep 30 14:09:27 endymion kernel: [21556.560593] radeon :07:00.0:
> 88007c334000 reserve failed fo
Hi again,
On Thu, 30 Sep 2010 15:18:27 +0200, Jean Delvare wrote:
> I am running kernel 2.6.36-rc6 on a Radeon HD4350 (RV710), and I see
> the following error messages in the logs:
>
> Sep 30 14:09:27 endymion kernel: [21556.560593] radeon :07:00.0:
> 88007c334000 res
ended. So remove the spurious log message.
Signed-off-by: Jean Delvare
Cc: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.h |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- linux-2.6.36-rc7.orig/drivers/gpu/drm/radeon/radeon_object.h
2010-10-08 13:32:46.
lined. The binary size benefit is
slightly smaller (-2294 bytes on x86-64) but the code would be slightly
faster (one function call saved.) What do you think?
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Function ttm_bo_wait_unreserved can be slightly simplified.
Signed-off-by: Jean Delvare
Cc: Thomas Hellstrom
Cc: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_bo.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
--- linux-2.6.36-rc7.orig/drivers/gpu/drm/ttm/ttm_bo.c 2010-10-09
From: Jean Delvare
Subject: drm/radeon/kms: Fix module parameter description format
Module parameter descriptions don't take a trailing \n, otherwise it
breaks formatting of modinfo's output. Also add missing space after
comma.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex D
Module parameter descriptions don't take a trailing \n, otherwise it
breaks formatting of modinfo's output. Also remove trailing space.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_drv.c | 12 ++--
1 file changed, 6 insert
direction, but was not sufficient IMHO.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex Deucher
---
Might be considered for stable, this is not a critical bug but it can
waste time of users and developers alike.
drivers/gpu/drm/radeon/radeon_acpi.c |3 ++-
1 file changed, 2 insertions(+), 1
I am under the impression that it only makes sense to call the ATIF
method if the graphics device has an ACPI handle attached. So we could
skip the call altogether if there is no such handle.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex Deucher
---
This is only tested on a system
Commit 9b9fe724 accidentally used RADEON_GPIO_EN_* where
RADEON_GPIO_MASK_* was intended. This caused improper initialization
of I2C buses, mostly visible when setting i2c_algo_bit.bit_test=1.
Using the right constants fixes the problem.
Signed-off-by: Jean Delvare
Cc: Alex Deucher
Cc: Jerome
There is no point in re-doing in post_xfer all the initialization
that was already done by pre_xfer. Instead, only do the work which
differs from pre_xfer.
Signed-off-by: Jean Delvare
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_i2c.c | 48
; > ? ? ? ? ? ? ? ?ret = i2c_transfer(adapter, msgs, 2);
> > + ? ? ? ? ? ? ? if (ret == -ENXIO) {
> > + ? ? ? ? ? ? ? ? ? ? ? DRM_DEBUG_KMS("drm: skipping non-existent adapter
> > %s\n",
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? adapter->name);
> > + ? ? ? ? ? ? ? ? ? ? ? break;
> > + ? ? ? ? ? ? ? }
> > ? ? ? ?} while (ret != 2 && --retries);
> >
> > ? ? ? ?return ret == 2 ? 0 : -1;
--
Jean Delvare
On Tue, 18 Oct 2011 11:37:38 -0200, Eugeni Dodonov wrote:
> On 10/18/2011 11:14, Jean Delvare wrote:
> > Hi Dave, Eugeni, Alex,
> >
> > On Tue, 18 Oct 2011 11:02:00 +0100, Dave Airlie wrote:
> >>> This allows to avoid talking to a non-existent bus repeatedly until
Forgot to attach the patch, sorry. Here it is.
--
Jean Delvare
-- next part --
A non-text attachment was scrubbed...
Name: i2c-algo-bit-export-test.patch
Type: text/x-patch
Size: 1702 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-de
On Thu, 20 Oct 2011 14:33:39 +0200, Jean Delvare wrote:
> That being said, even then the whole probe sequence shouldn't exceed
> 10 ms, which I wouldn't expect a user to notice. The user-reported 4
> second delay when running xrandr can't be caused by this. 4 seconds for
, the vast majority of framebuffer drivers set udelay to 10
already. So set it to 10 in DRM drivers too, this will make EDID block
reads faster. We might even lower the udelay value later if no problem
is reported.
Signed-off-by: Jean Delvare
Cc: Eugeni Dodonov
Cc: Dave Airlie
Cc: Keith Packard
Cc
The VESA specification suggests a 2.2 ms timeout on DDC channels.
Only the intel DRM driver implements this properly today, align all
drivers to the proper implementation.
Signed-off-by: Jean Delvare
Cc: Eugeni Dodonov
Cc: Dave Airlie
Cc: Keith Packard
Cc: Alex Deucher
---
drivers/gpu/drm
Hi Alan,
On Friday 21 October 2011 03:32:44 pm Alan Cox wrote:
> On Fri, 21 Oct 2011 09:08:30 +0200
>
> Jean Delvare wrote:
> > A udelay value of 20 leads to an I2C bus running at only 25 kbps. A
> > value of 40 as the nouveau driver has is even slower at 12.5 kbps
Hi Alex,
On Friday 21 October 2011 08:05:48 pm Alex Deucher wrote:
> On Fri, Oct 21, 2011 at 10:16 AM, Jean Delvare
> > Does anyone know at which speed hardware I2C engines are running
> > the DDC bus on various graphics cards?
>
> IIRC, we generally target the radeon hw
Hi Eugeni,
On Mon, 24 Oct 2011 12:40:14 -0200, Eugeni Dodonov wrote:
> On Thu, Oct 20, 2011 at 10:33, Jean Delvare wrote:
>
> > Just to clarify: by "connectivity is setup", do you mean code in the
> > driver setting the GPIO pin direction etc., or a display being
&
m-sensors.org/pipermail/lm-sensors/2012-April/035847.html
> http://lists.freedesktop.org/archives/xorg/2011-January/052239.html
>
> Signed-off-by: Alex Deucher
> Cc: stable at vger.kernel.org
> Cc: Jean Delvare
> ---
> drivers/gpu/drm/radeon/radeon_i2c.c |4
&
return ret == 2 ? 0 : -1;
> + return ret == xfers ? 0 : -1;
> }
>
> static bool drm_edid_is_zero(u8 *in_edid, int length)
Other than this, your code looks reasonable, not so different from what
I submitted 8 months ago actually. But ISTU you can test the code with
real hardware while I couldn't.
With the changes above applied, you can add:
Reviewed-by: Jean Delvare
--
Jean Delvare
Suse L3
Hi Ville,
On Monday 13 February 2012 07:24:23 pm Ville Syrj?l? wrote:
> On Wed, Dec 07, 2011 at 03:11:07PM +0100, Jean Delvare wrote:
> > When 2 or more EDID extension blocks are present, segment must be
> > selected prior to reading the extended EDID block over the DDC
> >
rt a
new function i2c_bit_add_numbered_bus() which would call
__i2c_bit_add_bus() with no callback function. If you do that, you may
not have to export anything else.
I leave it up to you which way you want to implement it, all are fine
with me, and we can always change later if more use cases show up which
would work better with a different implementation.
--
Jean Delvare
On Mon, 27 Feb 2012 23:52:23 +0100, Daniel Vetter wrote:
> On Mon, Feb 27, 2012 at 11:20:40PM +0100, Jean Delvare wrote:
> > If you need to hot-switch between hardware and bit-banged I2C, I suggest
> > that you lock the bus while doing so, to avoid switching while a
> > trans
; The new plan is to only set up one i2c adaptor and transparently fall
> back to bit-banging by directly calling the xfer function of the bit-
> banging algo in the i2c core.
>
> To make that possible, export the 2 i2c algo functions.
>
> v2: As suggested by Jean Delvare,
bit. If the code is broken, let's fix it for the benefit
of all users. Duplicating code around isn't going to help any.
Thanks,
--
Jean Delvare
Suse L3
On Wednesday 30 November 2011 05:59:57 pm Alex Deucher wrote:
> On Wed, Nov 30, 2011 at 11:22 AM, Jean Delvare
> wrote:
> > From: Jean Delvare
> > Subject: drm/radeon/kms: Fix module parameter description format
> >
> > Module parameter descriptions don't t
On Wednesday 30 November 2011 05:23:55 pm Jean Delvare wrote:
> Module parameter descriptions don't take a trailing \n, otherwise it
> breaks formatting of modinfo's output. Also remove trailing space.
>
> Signed-off-by: Jean Delvare
> Cc: David Airlie
> Cc: Ben Skeg
set it to 10 in DRM drivers too, this will make EDID block
reads faster. We might even lower the udelay value later if no problem
is reported.
Signed-off-by: Jean Delvare
Acked-by: Eugeni Dodonov
Cc: Dave Airlie
Cc: Keith Packard
Cc: Alex Deucher
---
Already sent on: 2011-10-21.
drivers/gpu
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.
Signed-off-by: Jean Delvare
Reviewed-by: Keith Packard
Cc: Dave Airlie
Cc: Alex Deucher
---
Already sent on: 2011-10-21.
drivers/gpu/drm/radeon
Properly set the parent device of i2c buses before registering them so
that they will show at the right place in the device tree (rather than
in /sys/devices directly.)
Signed-off-by: Jean Delvare
Cc: Dave Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_i2c.c |1 +
1 file
Properly set the parent device of DP i2c buses before registering them
too.
Signed-off-by: Jean Delvare
Cc: Dave Airlie
Cc: Alex Deucher
---
I'm sorry, my previous patch missed the fact that DP i2c buses are
handled separately so they need the same fix.
drivers/gpu/drm/radeon/radeon_
t is related (but it would certainly be nice to solve that
problem too.)
Let me know if I can provide more information, or help in any way with
debugging this issue.
Thanks,
--
Jean Delvare
s well.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=36221
>
> Cc: Jean Delvare
> Signed-off-by: Alex Deucher
Good catch, applied, thanks. I'll also push this to the stable kernel
trees (from .38 down to .34.)
> ---
> drivers/i2c/algos/i2c-algo-bit.c | 21
When 2 or more EDID extension blocks are present, segment must be
selected prior to reading the extended EDID block over the DDC
channel. Add support for this.
Signed-off-by: Jean Delvare
Cc: Adam Jackson
---
This needs testing by someone with access to such a display.
drivers/gpu/drm
n unusable display.
>
> Signed-off-by: Alex Deucher
> Cc: stable at kernel.org
> Cc: Jean Delvare
Thanks Alex. I tested this fix and it works to some degree, but it
doesn't solve all the issues.
What works:
* No garbage on the screen.
* X falls back to the vesa driver.
What doesn'
On Tue, 3 May 2011 13:32:36 -0400, Alex Deucher wrote:
> The most common use of the radeon i2c buses is for ddc.
>
> Signed-off-by: Alex Deucher
> Cc: Jean Delvare
Acked-by: Jean Delvare
> ---
> drivers/gpu/drm/radeon/radeon_i2c.c |2 ++
> 1 files changed, 2 inser
liar with git, a git bisection would help
too.
--
Jean Delvare
shouldn't be too difficult. Just clone Linus' kernel tree
and follow the git bisect manual page:
http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
--
Jean Delvare
I missed this part the first time through.
>
> Signed-off-by: Alex Deucher
> Cc: stable at kernel.org
> Cc: Jean Delvare
Acked-by: Jean Delvare
And the fix was tested successfully by one openSUSE 11.4 user, see:
https://bugzilla.novell.com/show_bug.cgi?id=691052#c37
Thanks Alex!
No
_each_drv() and from every
other function which raises this problem, or we must disable that new
type of warning gcc 4.6.0 generates. Depends which warnings we value
more, as we can't sanely have both.
> mutex_unlock(&core_lock);
>
> return 0;
--
Jean Delvare
On Tue, 15 Jun 2010 09:20:39 -0700, David Daney wrote:
> On 06/15/2010 04:40 AM, Jean Delvare wrote:
> > __process_new_adapter() calls i2c_do_add_adapter() which always returns
> > 0. Why should I check the return value of bus_for_each_drv() when I
> > know it will always
I can help debugging this by providing extra information
or doing tests. This is low priority for me (I don't normally do 3D on
that machine) but you probably want the bug fixed before 2.6.34-final.
--
Jean Delvare
On Wed, 5 May 2010 16:40:54 +0200, Jean Delvare wrote:
> With kernels 2.6.34-rc6-git{1,2,3}, glxgears crashes the radeon driver
> on my machine. Kernel 2.6.33.3 works fine. (...)
Still happens with -git6. Should I start bisecting?
--
Jean Delvare
On Sun, 9 May 2010 13:36:35 +0200, Jean Delvare wrote:
> On Wed, 5 May 2010 16:40:54 +0200, Jean Delvare wrote:
> > With kernels 2.6.34-rc6-git{1,2,3}, glxgears crashes the radeon driver
> > on my machine. Kernel 2.6.33.3 works fine. (...)
>
> Still happens with -git6. Sho
Yes, it's me again ;)
On Sun, 9 May 2010 22:58:30 +0200, Jean Delvare wrote:
> Bisection says that the faulty commit is:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b4fe945405e477cded91772b4fec854705443dd5
>
> It doesn't revert cleanly
to.
* Fix swapped characters in the string used to name the GPIO-based
adapter.
* Add missing comma in gmbus name table.
Signed-off-by: Jean Delvare
Tested-by: Randy Dunlap
---
Chris, what's the status of this patch? I think it should go to Linus
ASAP.
drivers/gpu/drm/i915/intel_i2c.c | 11
e
check to i2c-core. This will avoid future bug reports which we don't
know how to process because we have no idea what the underlying faulty
I2C adapter is.
> Noticed by Ari Savolainen.
>
> Signed-off-by: Alex Deucher
> Cc: Ari Savolainen
> Cc: Jean Delvare
> Cc: stable a
On Thu, 18 Nov 2010 11:37:18 -0500, Alex Deucher wrote:
> As per advice from Jean Delvare.
>
> Signed-off-by: Alex Deucher
> Cc: Jean Delvare
Thanks Alex.
Acked-by: Jean Delvare
> ---
> drivers/gpu/drm/radeon/radeon_i2c.c |9 ++---
> 1 files changed, 6 inser
this bug? If not, I
can start a bisection.
I can also provide any additional data you need for investigation.
--
Jean Delvare
Hi Alex,
Thanks for your fast answer.
On Sun, 21 Nov 2010 11:12:32 -0500, Alex Deucher wrote:
> On Sun, Nov 21, 2010 at 9:38 AM, Jean Delvare wrote:
> > Running 2.6.37-rc2-git7 on x86_64, wine fails to start. I get the
> > following error in the kernel logs:
> >
&g
Hi Alex,
On Sun, 21 Nov 2010 19:57:23 -0500, Alex Deucher wrote:
> On Sun, Nov 21, 2010 at 1:51 PM, Jean Delvare wrote:
> > On Sun, 21 Nov 2010 11:12:32 -0500, Alex Deucher wrote:
> >> It's probably this patch:
> >> http://git.kernel.org/?p=linux/kernel/git/torva
On Thu, 30 Sep 2010 15:18:27 +0200, Jean Delvare wrote:
> I am running kernel 2.6.36-rc6 on a Radeon HD4350 (RV710), and I see
> the following error messages in the logs:
>
> Sep 30 14:09:27 endymion kernel: [21556.560593] radeon :07:00.0:
> 88007c334000 reserve failed fo
Hi again,
On Thu, 30 Sep 2010 15:18:27 +0200, Jean Delvare wrote:
> I am running kernel 2.6.36-rc6 on a Radeon HD4350 (RV710), and I see
> the following error messages in the logs:
>
> Sep 30 14:09:27 endymion kernel: [21556.560593] radeon :07:00.0:
> 88007c334000 res
ended. So remove the spurious log message.
Signed-off-by: Jean Delvare
Cc: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.h |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- linux-2.6.36-rc7.orig/drivers/gpu/drm/radeon/radeon_object.h
2010-10-08 13:32:46.
lined. The binary size benefit is
slightly smaller (-2294 bytes on x86-64) but the code would be slightly
faster (one function call saved.) What do you think?
--
Jean Delvare
Function ttm_bo_wait_unreserved can be slightly simplified.
Signed-off-by: Jean Delvare
Cc: Thomas Hellstrom
Cc: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_bo.c |9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
--- linux-2.6.36-rc7.orig/drivers/gpu/drm/ttm/ttm_bo.c 2010-10-09
"radeon_atom_get_hpd_info_from_gpio":
drivers/gpu/drm/radeon/radeon_atombios.c:261: warning: "hpd.plugged_state" is
used uninitialized in this function
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex Deucher
---
As a side, note, passing whole structures on the
Hi Alex, David,
On Sun, 21 Nov 2010 11:12:32 -0500, Alex Deucher wrote:
> On Sun, Nov 21, 2010 at 9:38 AM, Jean Delvare wrote:
> > Running 2.6.37-rc2-git7 on x86_64, wine fails to start. I get the
> > following error in the kernel logs:
> >
> > radeon :07:00.0
Hi Alex,
On Sun, 12 Dec 2010 23:33:42 -0500, Alex Deucher wrote:
> On Sun, Dec 12, 2010 at 7:31 PM, Alex Deucher
> wrote:
> > On Fri, Dec 10, 2010 at 7:01 AM, Jean Delvare wrote:
> >> Any progress on this? Linus' latest kernel (2.6.37-rc5-git3) still has
>
ode is wrong, and give up and become a farmer.
I wish you success in you upcoming endeavour! :D
I know what you mean. The kernel/user-space interface is sometimes very
difficult to live with.
--
Jean Delvare
On Mon, 27 Jun 2011 22:44:42 +0200, Jean Delvare wrote:
> No need for 2-byte buffers, we only send one byte and receive one
> byte.
>
> Signed-off-by: Jean Delvare
> Cc: David Airlie
> Cc: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_i2c.c |7 +++
> 1
nce. I
would guess that you know what backend is present on a system when you
try to identify it.
At this point, I see the work needed to review your patches, the risk
of regressions due to the large size of the patch set, but I don't see
any immediate benefit. Thus I am not going to look into it at all,
sorry.
--
Jean Delvare
Revert commit 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f. This fixes a
hang when loading the eeprom driver (see bug #35572.) GMBUS will be
re-enabled later, differently.
Signed-off-by: Jean Delvare
Reported-by: Marek Otahal
Tested-by: Yermandu Patapitafious
Tested-by: Andrew Lutomirski
Acked-by
Hi Florian,
On Sat, 11 Jun 2011 13:28:15 +0200, Florian Mickler wrote:
> On Sat, 04 Jun 2011 19:34:56 -
> Jean Delvare wrote:
>
> > Revert commit 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f. This fixes a
> > hang when loading the eeprom driver (see bug #35572.) GMBUS w
101 - 200 of 228 matches
Mail list logo
