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
return false;
--- linux-3.0-rc4.orig/include/drm/drm_crtc.h 2011-06-21 10:30:19.0
+0200
+++ linux-3.0-rc4/include/drm/drm_crtc.h2011-06-22 12:02:24.0
+0200
@@ -802,6 +802,7 @@ extern struct drm_display_mode *drm_gtf_
extern int drm_add_modes_noedid(struct drm_connect
bout 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
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
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
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: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
---
Changes since v1:
* Chunk missing for the nouveau driver, sorry
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.
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
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
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
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
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
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
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
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
> >
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 Tue, 15 Oct 2024 09:06:04 -0700, Doug Anderson wrote:
> On Tue, Oct 15, 2024 at 4:46 AM Jean Delvare wrote:
> > Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
> > is possible to test-build any driver which depends on OF on any
>
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
Reviewed-by: Paul Kocialkowski
---
Changes since v1:
* Rebase on top of v6.13.
* Extend the description to better explain the rationale behind the
201 - 228 of 228 matches
Mail list logo
