On Fri, Sep 27, 2024 at 12:30:04PM +0300, Jani Nikula wrote:
> On Thu, 26 Sep 2024, Andi Kleen wrote:
> > I have an old monitor that reports a zero EDID block, which results in a
> > warning message. This happens on every screen save cycle, and maybe in
> > some other situ
bad_edid_count like other verbose EDID
messages.
Signed-off-by: Andi Kleen
---
v2: Use bad_edid_count instead of _once.
---
drivers/gpu/drm/drm_edid.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index
bad_edid_count like other verbose EDID
messages.
Signed-off-by: Andi Kleen
---
v2: Use bad_edid_count instead of _once.
v3: Move rate limit logic into dedicated wrapper.
---
drivers/gpu/drm/drm_edid.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
> > -static void edid_block_status_print(enum edid_block_status status,
> > +static void edid_block_status_print(struct drm_connector *connector,
> > + enum edid_block_status status,
> > const struct edid *block,
> >
On Thu, Sep 26, 2024 at 03:51:09PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Thu, Sep 26, 2024 at 06:32:53AM GMT, Andi Kleen wrote:
> > I have an old monitor that reports a zero EDID block, which results in a
> > warning message. This happens on every screen save cycle, and ma
> It may be a good opportunity to switch these over to drm_notice_once()
> instead.
I looked at it, but the callers to several levels don't have the
drm pointer that would be needed for that. It would require changing
them, and then all the drivers which call into the generic EDID code.
And even t
the bad EDID notices as _once.
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 855beafb76ff..d6b47bdcd5d7 100644
--- a/drivers/gpu/drm/drm_edid.c
> > Increase all the latency fields to 8 members, which is enough for SKL.
> >
> > I don't know if they are correctly initialized upto 8, but dev_priv
> > should start out as zero, so presumably they will be zero.
>
> Thanks, the warning should be fixed by commit
>
> c6deb5e97ded ("drm/i915/pm: M
From: Andi Kleen
Newer gcc prints the following warning:
drivers/gpu/drm/i915/intel_pm.c:3057:9: warning: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Wstringop-overread]
and some other related warnings in similar functions.
gcc has a point here. Some of the latency
On Mon, Dec 22, 2014 at 10:49:40AM -0800, Andi Kleen wrote:
> On Mon, Dec 22, 2014 at 11:58:43AM -0500, Alex Deucher wrote:
> > On Mon, Dec 22, 2014 at 6:11 AM, Oded Gabbay wrote:
> > > amdkfd driver can be compiled only in 64-bit kernel. Therefore, there is
> > >
On Mon, Dec 22, 2014 at 11:58:43AM -0500, Alex Deucher wrote:
> On Mon, Dec 22, 2014 at 6:11 AM, Oded Gabbay wrote:
> > amdkfd driver can be compiled only in 64-bit kernel. Therefore, there is no
> > point in trying to initialize amdkfd in 32-bit kernel.
> >
> > In addition, in case of specific co
On Tue, May 20, 2014 at 06:16:48PM +0200, Marek Ol??k wrote:
> I think the function should stay in the header file. It's used in
> performance-critical code, so we want it to be inlined.
This doesn't make any sense. If it's talking to the hardware it will
be dominated by the cache misses.
-Andi
From: Andi Kleen
Saves about 5k of text
textdata bss dec hex filename
140803602008168 1507328 1759585610c7dd0 vmlinux-before-radeon
140749782008168 1507328 1759047410c68ca vmlinux-radeon
Cc: alexander.deucher at amd.com
Cc: dri-devel at
Stéphane Marchesin writes:
> While investing some Sandy Bridge rendering corruption, I found out
> that all physical memory pages below 1MiB were returning garbage when
> read through the GTT. This has been causing graphics corruption (when
> it's used for textures, render targets and pixmaps) an
St?phane Marchesin writes:
> While investing some Sandy Bridge rendering corruption, I found out
> that all physical memory pages below 1MiB were returning garbage when
> read through the GTT. This has been causing graphics corruption (when
> it's used for textures, render targets and pixmaps) an
From: Andi Kleen
This fixes size regressions like
radeon_set_suspend 17247873 +6149
radeon_reinitialize_M10 39749285 +5311
radeon_pm_disable_dynamic_mode 8686125 +5257
radeon_pm_enable_dynamic_mode985
From: Andi Kleen
Cc: David Airlie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon/r600_blit.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_blit.c
b/drivers/gpu/drm/radeon/r600_blit.c
index 7f10434..3c031a4
From: Andi Kleen
With this patch I'm only about 50k larger with DRM debugging
enables (why is that enabled by default?!?), and slightly
smaller without.
Cc: airl...@linux.ie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon/r100.c | 39 ++
driver
From: Andi Kleen
These are not time critical, and using an out of line function
saves about 2.5k text on a non force inline kernel.
I left the main hotpath user -- readahead -- inline for now.
Signed-off-by: Andi Kleen
---
drivers/base/node.c | 72
From: Andi Kleen
With the tracing code in there they are far too big to inline.
.text savings compared to a non force inline kernel:
i915_restore_display4393 12036 +7643
i915_save_display 4295 11459 +7164
i915_handle_error
From: Andi Kleen
I found that gcc 4.5 didn't inline a lot of inlines with
CONFIG_OPTIMIZE_INLINING and CONFIG_CC_OPTIMIZE_FOR_SIZE. It was quite
common to have very small inlines to be out of line, or worse inline
statics in include files to be out of line with a copy for every file
using i
From: Andi Kleen
Fixes
evergreen_cs_parse 4080 23124 +19044
and others compared to a non force inline kernel.
Cc: David Airlie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon/evergreen_cs.c |8
drivers/gpu/drm/radeon/r600_cs.c | 24
From: Andi Kleen
This saves about 2.5k text on a non force inline kernel.
Cc: x...@kernel.org
Signed-off-by: Andi Kleen
---
arch/x86/include/asm/desc.h | 17 +
arch/x86/kernel/irqinit.c | 20
2 files changed, 21 insertions(+), 16 deletions(-)
diff
From: Andi Kleen
Remove bogus inlines in evergreen and r100.
Cc: airl...@linux.ie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon/evergreen.c |4 +-
drivers/gpu/drm/radeon/evergreen_blit_kms.c |2 +-
drivers/gpu/drm/radeon/r100.c | 106
From: Andi Kleen
With the dropped inlines gccs starts warning about genuinely unused
functions. Remove r600_bpe_from_format, evergreen_cs_track_validate_cb,
evergreen-cs_packet_next_is_pkt3_nop which are all unused.
Cc: David Airlie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon
From: Andi Kleen
Drop some inlines to shrink code size with force inline
Still some unfixed growth in:
balance_leaf71908766 +1576
search_by_key 19633317 +1354
Cc: v...@zeniv.linux.org.uk
Cc: fweis...@gmail.com
Signed
From: Andi Kleen
This shrinks the sizes of a lot of functions in the radeon driver
dramatically.
With a non force inline + -Os kernel this is default anyways.
Cc: David Airlie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon/r100.c | 40
drivers
From: Andi Kleen
I found that gcc 4.5 didn't inline a lot of inlines with
CONFIG_OPTIMIZE_INLINING and CONFIG_CC_OPTIMIZE_FOR_SIZE. It was quite
common to have very small inlines to be out of line, or worse inline
statics in include files to be out of line with a copy for every file
using i
From: Andi Kleen
With the tracing code in there they are far too big to inline.
.text savings compared to a non force inline kernel:
i915_restore_display4393 12036 +7643
i915_save_display 4295 11459 +7164
i915_handle_error
From: Andi Kleen
Drop some inlines to shrink code size with force inline
Still some unfixed growth in:
balance_leaf71908766 +1576
search_by_key 19633317 +1354
Cc: viro at zeniv.linux.org.uk
Cc: fweisbec at gmail.com
From: Andi Kleen
These are not time critical, and using an out of line function
saves about 2.5k text on a non force inline kernel.
I left the main hotpath user -- readahead -- inline for now.
Signed-off-by: Andi Kleen
---
drivers/base/node.c | 72
From: Andi Kleen
This saves about 2.5k text on a non force inline kernel.
Cc: x86 at kernel.org
Signed-off-by: Andi Kleen
---
arch/x86/include/asm/desc.h | 17 +
arch/x86/kernel/irqinit.c | 20
2 files changed, 21 insertions(+), 16 deletions(-)
diff
From: Andi Kleen
With this patch I'm only about 50k larger with DRM debugging
enables (why is that enabled by default?!?), and slightly
smaller without.
Cc: airlied at linux.ie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon/r100.c | 39 ++
dr
From: Andi Kleen
Remove bogus inlines in evergreen and r100.
Cc: airlied at linux.ie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon/evergreen.c |4 +-
drivers/gpu/drm/radeon/evergreen_blit_kms.c |2 +-
drivers/gpu/drm/radeon/r100.c | 106
From: Andi Kleen
This fixes size regressions like
radeon_set_suspend 17247873 +6149
radeon_reinitialize_M10 39749285 +5311
radeon_pm_disable_dynamic_mode 8686125 +5257
radeon_pm_enable_dynamic_mode985
From: Andi Kleen
With the dropped inlines gccs starts warning about genuinely unused
functions. Remove r600_bpe_from_format, evergreen_cs_track_validate_cb,
evergreen-cs_packet_next_is_pkt3_nop which are all unused.
Cc: David Airlie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon
From: Andi Kleen
Cc: David Airlie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon/r600_blit.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_blit.c
b/drivers/gpu/drm/radeon/r600_blit.c
index 7f10434..3c031a4
From: Andi Kleen
This shrinks the sizes of a lot of functions in the radeon driver
dramatically.
With a non force inline + -Os kernel this is default anyways.
Cc: David Airlie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon/r100.c | 40
drivers
From: Andi Kleen
Fixes
evergreen_cs_parse 4080 23124 +19044
and others compared to a non force inline kernel.
Cc: David Airlie
Signed-off-by: Andi Kleen
---
drivers/gpu/drm/radeon/evergreen_cs.c |8
drivers/gpu/drm/radeon/r600_cs.c | 24
On Sun, Oct 10, 2010 at 03:44:29PM +0200, Markus Trippelsdorf wrote:
> On Sun, Oct 10, 2010 at 02:30:00PM +0200, Andi Kleen wrote:
> >
> > Hi,
> >
> > I see a radeon regression here with 2.6.36-rc7.
> >
> > I updated a system from 2.6.35 to 2.6.36-rc
Hi,
I see a radeon regression here with 2.6.36-rc7.
I updated a system from 2.6.35 to 2.6.36-rc7. Now I cannot
switch to the text console from the X server anymore; the screen just
keeps displaying the X desktop. Eventually when I switch back
to X things work again.
The console switching wor
On Sun, Oct 10, 2010 at 03:44:29PM +0200, Markus Trippelsdorf wrote:
> On Sun, Oct 10, 2010 at 02:30:00PM +0200, Andi Kleen wrote:
> >
> > Hi,
> >
> > I see a radeon regression here with 2.6.36-rc7.
> >
> > I updated a system from 2.6.35 to 2.6.36-rc
Hi,
I see a radeon regression here with 2.6.36-rc7.
I updated a system from 2.6.35 to 2.6.36-rc7. Now I cannot
switch to the text console from the X server anymore; the screen just
keeps displaying the X desktop. Eventually when I switch back
to X things work again.
The console switching wor
43 matches
Mail list logo
