| 3 +--
> drivers/i2c/muxes/i2c-mux-ltc4306.c | 4 +---
> drivers/i2c/muxes/i2c-mux-pca9541.c | 3 +--
> drivers/i2c/muxes/i2c-mux-pca954x.c | 3 +--
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
top.org/show_bug.cgi?id=112140
> References: ae2a3495973e ("drm/amd: be quiet when no SAD block is found")
> Signed-off-by: Chris Wilson
> Cc: Harry Wentland
> Cc: Jean Delvare
> Cc: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
/show_bug.cgi?id=107825
Signed-off-by: Jean Delvare
Reviewed-by: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
---
Already sent on: 2019-09-04
Changes since v1:
* Treat CEA extension version < 3 as non-error too (suggested by Vi
The driver does not support these sensors yet and there is no point in
creating sysfs attributes which will always return an error.
Signed-off-by: Jean Delvare
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
---
This works for me however I couldn'
Comparing adev->family with CHIP constants is not correct.
adev->family can only be compared with AMDGPU_FAMILY constants and
adev->asic_type is the struct member to compare with CHIP constants.
They are separate identification spaces.
Signed-off-by: Jean Delvare
Fixes: 62a37553414a (&q
It is fine for displays without audio functionality to not provide
any SAD block in their EDID. Do not log an error in that case,
just return quietly.
This fixes half of bug fdo#107825:
https://bugs.freedesktop.org/show_bug.cgi?id=107825
Signed-off-by: Jean Delvare
Cc: Alex Deucher
Cc
Hi all,
This is my attempt to fix bug fdo#107825:
https://bugs.freedesktop.org/show_bug.cgi?id=107825
[PATCH 1/3] drm/amd: be quiet when no SAD block is found
[PATCH 2/3] drm/radeon: be quiet when no SAD block is found
[PATCH 3/3] drm/edid: no CEA extension is not an error
--
Jean Delvare
SUSE
=107825
Signed-off-by: Jean Delvare
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_edid.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-5.2.orig/drivers/gpu/drm/drm_edid.c 2019-08-30 17:57
-by: Jean Delvare
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_audio.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-5.2.orig/drivers/gpu/drm/radeon/radeon_au
Oops, sorry, I messed up the subject line of that one, which should
really read "drm/radeon: be quiet when no SAD block is found".
--
Jean Delvare
SUSE L3 Support
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freed
On Mon, 2 Sep 2019 14:46:51 +0300, Ville Syrjälä wrote:
> On Fri, Aug 30, 2019 at 06:16:52PM +0200, Jean Delvare wrote:
> > It is fine for displays without audio functionality to not implement
> > CEA extension in their EDID. Do not return an error in that case,
> > instead
/show_bug.cgi?id=107825
Signed-off-by: Jean Delvare
Reviewed-by: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
---
Changes since v1:
* Treat CEA extension version < 3 as non-error too (suggested by Ville
Syrjälä)
drivers/gpu/drm/drm_edi
-by: Jean Delvare
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: David Airlie
Cc: Daniel Vetter
---
Changes since v1:
* Fixed subject
drivers/gpu/drm/radeon/radeon_audio.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-5.2.
It is fine for displays without audio functionality to not provide
any SAD block in their EDID. Do not log an error in that case,
just return quietly.
This fixes half of bug fdo#107825:
https://bugs.freedesktop.org/show_bug.cgi?id=107825
Signed-off-by: Jean Delvare
Cc: Alex Deucher
Cc
:
* Fixed subject of patch 2
* Treat CEA extension version < 3 as non-error too (suggested by Ville
Syrjälä)
--
Jean Delvare
SUSE L3 Support
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/
r the caller
> to blindly iterate the data blocks even if there are none.
>
> Cc: Jean Delvare
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid
On Tue, 10 Sep 2019 12:48:42 +0300, Ville Syrjälä wrote:
> On Tue, Sep 10, 2019 at 11:46:20AM +0200, Jean Delvare wrote:
> > Hi Ville,
> >
> > On Mon, 2 Sep 2019 16:15:46 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Let&
ck they could end up misinterpreting
> whatever data is in the reserved section as CEA data blocks.
>
> Let's have cea_db_offsets() do the revision check so that the
> callers don't even have worry about it.
>
> Cc: Jean Delvare
> Signed-off-by: Ville Syrjälä
> ---
Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.
Signed-off-by: Jean Delvare
Cc: Da
Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.
Signed-off-by: Jean Delvare
e warnings.
Dropping COMPILE_TEST here improves the quality of our testing and
avoids wasting time on non-existent issues.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/display/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-5.19.or
e warnings.
Dropping COMPILE_TEST here improves the quality of our testing and
avoids wasting time on non-existent issues.
Signed-off-by: Jean Delvare
Cc: Paul Kocialkowski
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/logicvc/Kconfig |2 +-
1 file changed, 1 insertion(+),
U_NOTIFIER unconditionally?
The proliferation of kconfig options is not helping.
> That we have two options doing the same is just a matter of branching of
> amdgpu from radeon and not cleaning up the configuration options. So
> feel free to cleaning this up and write a patch which m
n why we can't just
unconditionally select MMU_NOTIFIER in these 3 drivers and be done with
it. That's less work at kernel configuration time AND fewer
preprocessing conditionals within the code, so easier/better testing
coverage and more readable code. We would need a very good reason for
NOT doing it.
--
Jean Delvare
SUSE L3 Support
Hi Christian,
On Thu, 18 Feb 2016 10:48:18 +0100, Christian König wrote:
> Am 18.02.2016 um 09:59 schrieb Jean Delvare:
> > Maybe I was not clear enough in my original post, but I am really
> > advocating for FEWER kconfig options, not more. Plus I just explained
> > why I
You can get the driver data from struct device directly, there's no
need to get the PCI device first.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
--- linux
The hwmon sysfs interface allows exposing temperature limits. The "max"
and "min" thresholds will be exposed as a critical high limit and its
hysteresis value, respectively. This gives the user a better idea of how
well cooling is doing and whether it is sufficient.
Signed-
en be moved together with the other I2C helper chip
drivers.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
---
drivers/gpu/drm/Kconfig|4 ++--
drivers/gpu/drm/exynos/Kconfig |2 +-
2 files changed, 3 i
The Renesas R-Car Display Unit driver is only useful on shmobile
unless build testing. The LVDS output is useful on an even more
reduced hardware set.
Signed-off-by: Jean Delvare
Cc: Laurent Pinchart
Cc: David Airlie
---
drivers/gpu/drm/rcar-du/Kconfig |2 ++
1 file changed, 2 insertions
Hi Laurent,
On Mon, 26 May 2014 13:36:11 +0200, Laurent Pinchart wrote:
> Thank you for the patch.
You're welcome. And thanks for your help :-)
> On Monday 26 May 2014 13:01:35 Jean Delvare wrote:
> > The Renesas R-Car Display Unit driver is only useful on shmobile
> > un
The shmobile DRM driver is only useful on SuperH and shmobile unless
build testing. I am dropping the SuperH dependencies though because
the driver doesn't even build there, so in practice it is an arm-only
driver for now.
Signed-off-by: Jean Delvare
Cc: Laurent Pinchart
Cc: David A
with a run-time option to
disable full userptr (drm.userptr=ro or some such.)
As a general rule, fewer configuration options is better.
Once a decision is made, I volunteer to write the patches.
Thanks,
--
Jean Delvare
SUSE L3 Support
call "cat" on a large text file, it takes almost
twice as much time to be displayed and scrolled completely.
Can you please check that the ast driver portion of that commit is both
correct and complete?
Thanks,
--
Jean Delvare
SUSE L3 Support
_
On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote:
> Hi David,
>
> The following commit:
>
> commit 7cf321d118a825c1541b43ca45294126fd474efa
> Author: Dave Airlie
> Date: Mon Oct 24 15:37:48 2016 +1000
>
> drm/drivers: add support for using the arch wc map
; on my old Asus Z6NA-D6 which has
either an AST 2050 device if I trust the board specifications on
asus.com, or an AST 1100 if I trust /var/log/Xorg.0.log.
Note however that I am still not certain that the problem I am seeing
is the same as what both customers reported. It is possible that we
ha
Hi David,
On Fri, 2018-11-09 at 10:04 +1000, David Airlie wrote:
> On Thu, Nov 8, 2018 at 10:05 PM Jean Delvare wrote:
> >
> > On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote:
> > > Hi David,
> > >
> > > The following commit:
> > >
&g
On Mon, 2018-11-12 at 15:45 +0100, Takashi Iwai wrote:
> On Mon, 12 Nov 2018 15:36:07 +0100,
> Jean Delvare wrote:
> > Takashi asked me to compare the contents of
> > /sys/kernel/debug/x86/pat_memtype_list before and after the commit
> > above. Before the commit, we have:
_bug.cgi?id=1112963
Thank you very much for looking into this bug. I tested the patch above
and yes, it solves my console performance problem. The performance with
your patch applied is roughly the same as with commit "drm/drivers: add
support for using the arch wc mapping API" rev
> + kfree(ap);
> +}
> +
> static int ast_pci_probe(struct pci_dev *pdev, const struct pci_device_id
> *ent)
> {
> + ast_kick_out_firmware_fb(pdev);
> +
> return drm_get_pci_dev(pdev, ent, &driver);
> }
>
Thank you very much Thomas.
Reviewed-by: Jean Delvare
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -568,6 +568,7 @@ static int ast_crtc_do_set_base(struct drm_crtc *crtc,
> }
> ast_bo_unreserve(bo);
>
> + ast_set_offset_reg(crtc);
> ast_set_start_address_crt1(crtc, (u32)gpu_addr);
>
> return 0;
see
how linux-media and dri-devel are relevant here for example.
--
Jean Delvare
SUSE L3 Support
seful on Loongson-based MIPS systems, therefore I believe it
should only be offered as an option on these systems.
Would the following change be OK with you?
From: Jean Delvare
Subject: drm/loongson: Add platform dependency
Only offer the Loongson DRM driver as an option on platforms where
it
Only offer the Loongson DRM driver as an option on platforms where
it makes sense.
Signed-off-by: Jean Delvare
Cc: Sui Jingfeng
Cc: David Airlie
Cc: Daniel Vetter
---
Changes since v1:
* Use the architecture dependencies suggested by Sui Jingfeng.
drivers/gpu/drm/loongson/Kconfig |1
Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.
Signed-off-by: Jean Delvare
Cc: Da
Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.
Signed-off-by: Jean Delvare
Reviewe
Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.
Signed-off-by: Jean Delvare
Reviewed-
Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.
Signed-off-by: Jean Delvare
Reviewe
Hi Dmitry,
Thanks for your feedback.
On Mon, 17 Jun 2024 12:57:19 +0300, Dmitry Baryshkov wrote:
> On Mon, Jun 17, 2024 at 10:30:30AM GMT, Jean Delvare wrote:
> > Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
> > is possible to test-build any driv
On Mon, 17 Jun 2024 14:55:22 +0300, Dmitry Baryshkov wrote:
> On Mon, Jun 17, 2024 at 01:23:48PM GMT, Jean Delvare wrote:
> > Hi Dmitry,
> >
> > Thanks for your feedback.
> >
> > On Mon, 17 Jun 2024 12:57:19 +0300, Dmitry Baryshkov wrote:
> > > On
Hi Doug,
On Mon, 17 Jun 2024 19:12:05 -0700, Doug Anderson wrote:
> On Mon, Jun 17, 2024 at 3:26 PM Dmitry Baryshkov
> wrote:
> >
> > On Mon, Jun 17, 2024 at 08:18:14PM GMT, Jean Delvare wrote:
> > > The major difference is that one can't possibly enable ARCH_Q
config bug originally fixed by commit
876271118aa4 ("drm/display: Fix build error without CONFIG_OF"),
DRM_MSM which selects DRM_DISPLAY_DP_HELPER must explicitly depend
on OF. This is consistent with what all other DRM drivers are doing.
Signed-off-by: Jean Delvare
Reviewed-by: Javier Martinez
message at KERN_WARNING level regardless of the level of the message
being suppressed. This makes ratelimiting debug, info or notice
messages awkward. Looks like a design overlook to me, maybe it should
be fixed, but that's a much bigger and intrusive change than the
proposal above.
ommit isn't an actual revert of the original.
This fixes bug #194761:
https://bugzilla.kernel.org/show_bug.cgi?id=194761
Signed-off-by: Jean Delvare
Fixes: f8d9422ef80c ("drm/amdgpu: update tile table for oland/hainan")
Cc: Flora Cui
Cc: Junwei Zhang
Cc: Alex Deucher
Cc: M
different version for older kernels already,
I'll post it to stable@ after the fix is merged into Linus' tree.
--
Jean Delvare
SUSE L3 Support
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
There are no external users of function amdgpu_atif_handler so it can
be static.
Signed-off-by: Jean Delvare
Cc: Alex Deucher
Cc: "Christian König"
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-4.12.orig/drivers/g
driver doesn't have any such fallthrough,
so I suspect this is not supposed to happen.
Signed-off-by: Jean Delvare
Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10")
Cc: Ken Wang
Cc: Alex Deucher
Cc: "Marek Olšák"
Cc: "Christian König"
Cc: Flo
There are no external users of function radeon_atif_handler so it can
be static.
Signed-off-by: Jean Delvare
Cc: Alex Deucher
Cc: "Christian König"
---
drivers/gpu/drm/radeon/radeon_acpi.c |2 +-
drivers/gpu/drm/radeon/radeon_acpi.h |3 ---
2 files changed, 1 insertion(+), 4
Include a missing header to get rid of the following warning:
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c:521:6: warning: no previous prototype for
'dce_v6_0_disable_dce' [-Wmissing-prototypes]
void dce_v6_0_disable_dce(struct amdgpu_device *adev)
^
Signed-off-by: Jean Delvare
Include a missing header to get rid of the following warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:65:6: warning: no previous prototype for
‘amdgpu_pm_acpi_event_handler’ [-Wmissing-prototypes]
void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev)
^
Signed-off-by: Jean Delvare
From: Jean Delvare
Subject: drm/i915: Optimize DIV_ROUND_CLOSEST call
DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
dealing with unsigned dividends.
Signed-off-by: Jean Delvare
Cc: Guenter Roeck
Cc: Andrew Morton
Cc: Daniel Vetter
Cc: David Airlie
---
Daniel, I think we
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 hardw
From: Jean Delvare
Subject: drm/i915: Optimize DIV_ROUND_CLOSEST call
DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
dealing with unsigned dividends.
Signed-off-by: Jean Delvare
Cc: Guenter Roeck
Cc: Andrew Morton
Cc: Daniel Vetter
Cc: David Airlie
---
Daniel, I think we
DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
dealing with unsigned dividends. This optimization rips 32 bytes of
binary code on x86_64.
Signed-off-by: Jean Delvare
Cc: Guenter Roeck
Cc: Andrew Morton
Cc: Daniel Vetter
Cc: David Airlie
---
Already sent on: 2012-09-03
On Mon, 12 Nov 2012 15:02:26 +0100, Daniel Vetter wrote:
> On Mon, Nov 12, 2012 at 02:18:02PM +0100, Jean Delvare wrote:
> > DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
> > dealing with unsigned dividends. This optimization rips 32 bytes of
> >
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;
&
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
---
drivers/i2c/algos/i2c-algo-bit.c |8 ++--
include/linux/i2c-algo-bit.h |3 +++
2 files changed, 9 insertions(+), 2 deletions(-)
--- linux-3.1-rc10.orig/drivers/i2c/algos/i2c-algo-bit.c 2011-10-20 12:03
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
&
ssed this part the first time through.
>
> Signed-off-by: Alex Deucher
> Cc: sta...@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!
Note
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
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: sta...@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'
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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_
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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,
ETIMEDOUT;
+ }
cond_resched();
}
#ifdef DEBUG
Functionally it should be equivalent to your proposal, but faster. I'll
apply that (and send for stable inclusion.)
Thanks,
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Ben,
I'm sorry for the very very late reply. Please do not jump to the
conclusion that I do not care - I do! Just I am very busy, just as you.
On Wednesday 11 January 2012 01:40:58 pm Ben Skeggs wrote:
> On Wed, 2012-01-11 at 11:17 +0100, Jean Delvare wrote:
> > In the commi
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 th
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
> &g
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
---
Changes since v1:
* Split per driver to make merging easier
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
Reviewed-by: Alex Deucher
Cc: Dave Airlie
---
Changes since v1:
* Split per driver to make merging easier.
* Make the subject
On Thursday 22 March 2012 09:50:23 pm Daniel Vetter wrote:
> On Wed, Mar 21, 2012 at 02:29:47PM +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
> > be fine
1 - 100 of 228 matches
Mail list logo
