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
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
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 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
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
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
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
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
see
how linux-media and dri-devel are relevant here for example.
--
Jean Delvare
SUSE L3 Support
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
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
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(+),
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
| 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
/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
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
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ä
> ---
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/
-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.
/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
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
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
-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
=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
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
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
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'
> +++ 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;
> + 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
_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
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:
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 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
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
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
_
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.
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
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
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
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
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
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
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
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
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
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
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 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
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
On Mon, 17 Mar 2014 15:49:10 +0100, Jean Delvare wrote:
> It was only ever used by the ACPI video driver, and that only use case
> vanished over 3 years ago (see commit 677bd810, "ACPI video: remove
> output switching control".) So this is dead code and I guess we can
> remo
On Wed, 19 Mar 2014 14:10:53 +0100, Rafael J. Wysocki wrote:
> On Wednesday, March 19, 2014 07:51:45 AM Jean Delvare wrote:
> > Hi Rafael,
> >
> > On Wed, 19 Mar 2014 02:26:52 +0100, Rafael J. Wysocki wrote:
> > > On Monday, March 17, 2014 03:46:44 PM Jean Del
Hi Rafael,
On Wed, 19 Mar 2014 02:26:52 +0100, Rafael J. Wysocki wrote:
> On Monday, March 17, 2014 03:46:44 PM Jean Delvare wrote:
> > From: Jean Delvare
> > Subject: ACPI: fix ACPI_VIDEO dependencies
> >
> > ACPI_VIDEO stopped depending on VIDEO_OUTPUT_CONTROL over
ACPI_VIDEO no longer depends on VIDEO_OUTPUT_CONTROL, so drivers which
want to select ACPI_VIDEO no longer have to select
VIDEO_OUTPUT_CONTROL.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
---
Changes since v1:
* Chunk missing for the nouveau driver, sorry
It was only ever used by the ACPI video driver, and that only use case
vanished over 3 years ago (see commit 677bd810, "ACPI video: remove
output switching control".) So this is dead code and I guess we can
remove it now.
Signed-off-by: Jean Delvare
Cc: Zhang Rui
Cc: Len Brown
Cc:
ACPI_VIDEO no longer depends on VIDEO_OUTPUT_CONTROL, so drivers which
want to select ACPI_VIDEO no longer have to select
VIDEO_OUTPUT_CONTROL.
Signed-off-by: Jean Delvare
Cc: "Lee, Chun-Yi"
Cc: Matthew Garrett
---
drivers/platform/x86/Kconfig |2 --
1 file changed, 2
ACPI_VIDEO no longer depends on VIDEO_OUTPUT_CONTROL, so drivers which
want to select ACPI_VIDEO no longer have to select
VIDEO_OUTPUT_CONTROL.
Signed-off-by: Jean Delvare
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
---
I can split that one further if needed.
drivers/gpu/drm/gma500
From: Jean Delvare
Subject: ACPI: fix ACPI_VIDEO dependencies
ACPI_VIDEO stopped depending on VIDEO_OUTPUT_CONTROL over 3 years ago
(see commit 677bd810, "ACPI video: remove output switching control".)
So it's about time to remove the Kconfig dependency between these two
options.
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-
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
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
> >
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
> >
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
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
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 hardware while I couldn't.
With the changes above applied, you can add:
Reviewed-by: Jean Delvare
--
Jean Delvare
Suse L3
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
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
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
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
&
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
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
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
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
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
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
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
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
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
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
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
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
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 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 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
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
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
; 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,
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,
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
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
1 - 100 of 225 matches
Mail list logo
