[RFC PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset
Hi Andrzej
Thank you for comments.
On 04/18/2014 09:15 PM, Andrzej Hajda wrote:
> Hi YoungJun,
>
> Thanks for the whole patchset.
>
> On 04/15/2014 07:47 AM, YoungJun Cho wrote:
>> Some phy control registers are not kept after software reset.
>> So this patch makes the clocks containing phy control to be set
>> after software reset.
>>
>> Signed-off-by: YoungJun Cho
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 956e5f3..2cf1f0b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void
>> *dev_id)
>>
>> static int exynos_dsi_init(struct exynos_dsi *dsi)
>> {
>> -exynos_dsi_enable_clock(dsi);
>> exynos_dsi_reset(dsi);
>> enable_irq(dsi->irq);
>> exynos_dsi_wait_for_reset(dsi);
>> +exynos_dsi_enable_clock(dsi);
>> exynos_dsi_init_link(dsi);
>>
>> return 0;
> Are you sure this sequence is OK? I have observed that sequence:
>
> dsi power off
> dsi power on
> dsi_reset
>
> on 4210 or 4412 resulted in lack of irq after reset, only enabling
> clocks helped.
> And according to documentation reset do not touch registers set by
> exynos_dsi_enable_clock,
> so the current solution should work.
As I mentioned in description, it came from phy control registers.
Fortunately Exynos4 SoCs are safe, but the DSIM_PHYCTRL_REG,
DSIM_PHYTIMING_REG, DSIM_PHYTIMING1_REG and DSIM_PHYTIMING2_REG are
affected which are used in exynos_dsi_set_pll() for Exynos5 SoCs.
So this patch is required for Exynos5 SoCs.
Thank you
best regards YJ
>
> Regards
> Andrzej
>
[RFC PATCH v2 05/14] ARM: dts: samsung-fimd: add I80 specific properties
Hi Andrzej Thank you for comments. On 04/18/2014 09:32 PM, Andrzej Hajda wrote: > Hi again, > > On 04/17/2014 01:53 PM, YoungJun Cho wrote: >> In case of using CPU interface panel, the relevant registers should be set. >> So this patch adds relevant dt bindings. >> >> Changelog v2: >> - Changes "samsung,sysreg-phandle" to "samsung,sysreg" >> >> Signed-off-by: YoungJun Cho >> Signed-off-by: Inki Dae >> Signed-off-by: Kyungmin Park >> --- >> .../devicetree/bindings/video/samsung-fimd.txt |9 + >> 1 file changed, 9 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt >> b/Documentation/devicetree/bindings/video/samsung-fimd.txt >> index 2dad41b..6ea1adc 100644 >> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt >> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt >> @@ -44,6 +44,15 @@ Optional Properties: >> - display-timings: timing settings for FIMD, as described in document [1]. >> Can be used in case timings cannot be provided otherwise >> or to override timings provided by the panel. >> +- samsung,sysreg: handle to syscon used to control the system registers >> +- vidout-i80-ldi: boolean to support i80 interface instead of rgb one >> +- cs-setup: clock cycles for the active period of address signal enable >> until >> +chip select is enable in i80 interface >> +- wr-setup: clock cycles for the active period of CS signal enable until >> +write signal is enable in i80 interface >> +- wr-act: clock cycles for the active period of CS enable in i80 interface >> +- wr-hold: clock cycles for the active period of CS disable until write >> signal >> +is disable in i80 interface > > As Laurent wrote earlier it would be good to consider providing these > properties > by panel. Panel can pass it to DSI probably via mipi_dsi_device > structure. DSI to FIMD > can use exynos drm_framework probably. > Anyway if you add optional properties please add info about default > value, ie when property > is not present. You and Laurent thought these CPU timings should be in panel. Ok, how about that vidout-i80-ldi is remained in fimd board specific DT entry and other CPU timings relevant properties are moved to panel for considering probe order? That's because the IRQ resource of fimd should be "lcd_sys" for I80 interface and decided in probe time(bind time after adopting super device node). But the fimd probe routine is prior to panel probe routine and it is also ugly that fimd parses the properties of panel DT for that. Do you have any better idea? Thank you Best regards YJ > > Regards > Andrzej > >> >> The device node can contain 'port' child nodes according to the bindings >> defined >> in [2]. The following are properties specific to those nodes: > >
[Bug 77673] [bisected] moving moire starting with "drm/radeon: improve PLL params if we don't match exactly v2"
https://bugs.freedesktop.org/show_bug.cgi?id=77673 --- Comment #8 from Alex Deucher --- (In reply to comment #6) > Please try the attached patch. > > We now always use the fixed reference divider if both RADEON_PLL_USE_REF_DIV > and RADEON_PLL_USE_FRAC_FB_DIV are set. > > If only RADEON_PLL_USE_REF_DIV is set then we only use the fixed value as > minimum limit. Does that make sense? Wouldn't we want to use use the fixed value if RADEON_PLL_USE_REF_DIV regardless of whether RADEON_PLL_USE_FRAC_FB_DIV is set? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/0219c8ad/attachment.html>
[Bug 77676] Graphical glitches when using vdpau mpeg-4 with xbmc
https://bugs.freedesktop.org/show_bug.cgi?id=77676 --- Comment #7 from Alex Deucher --- What kernel are you using? Is this a regression? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/7c6693ad/attachment.html>
[Bug 77677] HDMI audio on ati7750 choppy with ALSA multi-channel apps
https://bugs.freedesktop.org/show_bug.cgi?id=77677 --- Comment #4 from Alex Deucher --- Possibly a duplicate of bug 77002. Does the fix mentioned in that bug help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/5592791e/attachment-0001.html>
[PATCH] modetest: consider supported formats before selecting a DRM plane
On Fri, Mar 28, 2014 at 6:15 PM, Fabien DESSENNE wrote:
> This fixes an issue where the DRM planes do not support the same pixel
> formats.
> The current implementation selects a DRM plane without checking whether
> the pixel format is supported or not. As a consequence modetest may try
> to set up a plane not supporting the user request-format, which fails.
> Modetest has to check the supported formats accross the plane list before
> selecting a candidate.
>
> Signed-off-by: Fabien Dessenne
> ---
> tests/modetest/modetest.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 4761c60..866ea82 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -951,7 +951,7 @@ static int set_plane(struct device *dev, struct
> plane_arg *p)
> int crtc_x, crtc_y, crtc_w, crtc_h;
> struct crtc *crtc = NULL;
> unsigned int pipe;
> - unsigned int i;
> + unsigned int i, j;
>
> /* Find an unused plane which can be connected to our CRTC. Find
> the
> * CRTC index first, then iterate over available planes.
> @@ -974,8 +974,11 @@ static int set_plane(struct device *dev, struct
> plane_arg *p)
> if (!ovr)
> continue;
>
> - if ((ovr->possible_crtcs & (1 << pipe)) && !ovr->crtc_id)
> - plane_id = ovr->plane_id;
> + if ((ovr->possible_crtcs & (1 << pipe)) && !ovr->crtc_id) {
> + for (j = 0; j < ovr->count_formats; j++)
> + if (!strncmp(p->format_str, (char *)
> &ovr->formats[j], 4))
> + plane_id = ovr->plane_id;
> + }
>
This loop continues to cycle through the list even after a positive match.
A micro-optimization would be to add a "break;" after setting plane_id.
Either way, this patch is:
Reviewed-by: Daniel Kurtz
But, I can't help you get the patch actually committed to the DRM
repository...
I'm still trying to get someone to help me get my own patches in.
Best Regards,
-djk
}
>
> if (!plane_id) {
> --
> 1.9.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/a7e2db5c/attachment.html>
[git pull] drm fixes
On 2014.04.19 at 21:21 -0400, Alex Deucher wrote: > On Sat, Apr 19, 2014 at 3:03 PM, Markus Trippelsdorf > wrote: > > On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: > >> > >> Unfortunately this contains no easter eggs, its a bit larger than I'd > >> like, but I included a patch that just moves code from one file to another > >> and I'd like to avoid merge conflicts with that later, so it makes it seem > >> worse than it is, > > > >> Christian K?nig (2): > >> drm/radeon: apply more strict limits for PLL params v2 > >> drm/radeon: improve PLL params if we don't match exactly v2 > > > > commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e > > Author: Christian K?nig > > Date: Wed Apr 16 11:54:21 2014 +0200 > > > > drm/radeon: improve PLL params if we don't match exactly v2 > > > > The commit above causes my monitor to just stay blank after boot. > > No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. > > Can you try the patch on: > https://bugs.freedesktop.org/show_bug.cgi?id=77673 I did and it doesn't fix the issue. -- Markus
[Bug 77676] Graphical glitches when using vdpau mpeg-4 with xbmc
https://bugs.freedesktop.org/show_bug.cgi?id=77676 --- Comment #8 from dupont --- (In reply to comment #7) > What kernel are you using? Is this a regression? Right now I am using 3.15, but I have also encountered the problem with 3.14. I am not sure if it is a regression or not. Which kernels do you want me to test? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/a152f866/attachment.html>
[Bug 77673] [bisected] moving moire starting with "drm/radeon: improve PLL params if we don't match exactly v2"
https://bugs.freedesktop.org/show_bug.cgi?id=77673 --- Comment #9 from Christian K?nig --- (In reply to comment #8) > (In reply to comment #6) > > Please try the attached patch. > > > > We now always use the fixed reference divider if both RADEON_PLL_USE_REF_DIV > > and RADEON_PLL_USE_FRAC_FB_DIV are set. > > > > If only RADEON_PLL_USE_REF_DIV is set then we only use the fixed value as > > minimum limit. > > Does that make sense? Wouldn't we want to use use the fixed value if > RADEON_PLL_USE_REF_DIV regardless of whether RADEON_PLL_USE_FRAC_FB_DIV is > set? I don't really know, it's just the way how the old code handled this. If RADEON_PLL_USE_REF_DIV was set the RADEON_PLL_USE_FRAC_FB_DIV branch just used the value as provided, but the none RADEON_PLL_USE_FRAC_FB_DIV branch still tried to increment the vale. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/5bd1396f/attachment.html>
[Bug 73457] mpeg4 through vdpau randomly either correct or garbled (on same file!)
https://bugs.freedesktop.org/show_bug.cgi?id=73457 Christian K?nig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Christian K?nig --- *** This bug has been marked as a duplicate of bug 71812 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/d61ab2be/attachment-0001.html>
[Bug 71812] VDPAU: MPEG-4 ASP Garbling/Corruption
https://bugs.freedesktop.org/show_bug.cgi?id=71812 --- Comment #8 from Christian K?nig --- *** Bug 73457 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/29505dbd/attachment-0001.html>
[Bug 73457] mpeg4 through vdpau randomly either correct or garbled (on same file!)
https://bugs.freedesktop.org/show_bug.cgi?id=73457 Christian K?nig changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #13 from Christian K?nig --- Sorry that was the wrong bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/6c1709ed/attachment.html>
[Bug 77676] Graphical glitches when using vdpau mpeg-4 with xbmc
https://bugs.freedesktop.org/show_bug.cgi?id=77676 Christian K?nig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Christian K?nig --- *** This bug has been marked as a duplicate of bug 71812 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/fc359f57/attachment.html>
[Bug 71812] VDPAU: MPEG-4 ASP Garbling/Corruption
https://bugs.freedesktop.org/show_bug.cgi?id=71812 Christian K?nig changed: What|Removed |Added CC||trash.wxcvbn at gmail.com --- Comment #9 from Christian K?nig --- *** Bug 77676 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/96d52e88/attachment.html>
[Bug 77676] Graphical glitches when using vdpau mpeg-4 with xbmc
https://bugs.freedesktop.org/show_bug.cgi?id=77676 --- Comment #10 from Christian K?nig --- No kernel issue at all, but a very well known problem with the userspace UVD driver parts. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/001213d8/attachment.html>
[git pull] drm fixes
> I did and it doesn't fix the issue. In this case please open up a new bugreport on https://bugs.freedesktop.org/enter_bug.cgi?product=DRI and select DRM/Radeon as component. Additional to that please provide a dmesg output generated with drm.debug=0xE for both the good and the bad case. Thanks in advance, Christian. Am 20.04.2014 08:24, schrieb Markus Trippelsdorf: > On 2014.04.19 at 21:21 -0400, Alex Deucher wrote: >> On Sat, Apr 19, 2014 at 3:03 PM, Markus Trippelsdorf >> wrote: >>> On 2014.04.19 at 08:19 +0100, Dave Airlie wrote: Unfortunately this contains no easter eggs, its a bit larger than I'd like, but I included a patch that just moves code from one file to another and I'd like to avoid merge conflicts with that later, so it makes it seem worse than it is, Christian K?nig (2): drm/radeon: apply more strict limits for PLL params v2 drm/radeon: improve PLL params if we don't match exactly v2 >>> commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e >>> Author: Christian K?nig >>> Date: Wed Apr 16 11:54:21 2014 +0200 >>> >>> drm/radeon: improve PLL params if we don't match exactly v2 >>> >>> The commit above causes my monitor to just stay blank after boot. >>> No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780. >> Can you try the patch on: >> https://bugs.freedesktop.org/show_bug.cgi?id=77673 > I did and it doesn't fix the issue. >
[git pull] drm fixes
On 2014.04.20 at 10:27 +0200, Christian K?nig wrote: > > I did and it doesn't fix the issue. > In this case please open up a new bugreport on > https://bugs.freedesktop.org/enter_bug.cgi?product=DRI and select > DRM/Radeon as component. > > Additional to that please provide a dmesg output generated with > drm.debug=0xE for both the good and the bad case. Good vs. bad: -[drm:radeon_compute_pll_avivo] 146250 - 14439, pll dividers - fb: 2047.0 ref: 29, post 7 +[drm:radeon_compute_pll_avivo] 146250 - 14955, pll dividers - fb: 1023.5 ref: 14, post 7 Full bad dmesg is attached. -- Markus -- next part -- Linux version 3.15.0-rc1-00421-g6d4596905b65-dirty (markus at x4) (gcc version 4.9.0 20140417 (prerelease) (GCC) ) #24 SMP Sun Apr 20 11:44:09 CEST 2014 Command line: BOOT_IMAGE=/bzImage root=PARTUUID=3ce070b6-a2b4-4127-9478-6ea8ceb69db7 init=/sbin/minit fbcon=rotate:3 radeon.dpm=1 radeon.audio=0 drm_kms_helper.poll=0 quiet drm.debug=0xE KERNEL supported cpus: AMD AuthenticAMD e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000e6000-0x000f] reserved BIOS-e820: [mem 0x0010-0xdfe8] usable BIOS-e820: [mem 0xdfe9-0xdfea7fff] ACPI data BIOS-e820: [mem 0xdfea8000-0xdfec] ACPI NVS BIOS-e820: [mem 0xdfed-0xdfef] reserved BIOS-e820: [mem 0xfff0-0x] reserved BIOS-e820: [mem 0x0001-0x00021fff] usable NX (Execute Disable) protection: active SMBIOS 2.5 present. DMI: System manufacturer System Product Name/M4A78T-E, BIOS 350304/13/2011 e820: update [mem 0x-0x0fff] usable ==> reserved e820: remove [mem 0x000a-0x000f] usable e820: last_pfn = 0x22 max_arch_pfn = 0x4 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-E uncachable F-F write-protect MTRR variable ranges enabled: 0 base mask 8000 write-back 1 base 8000 mask C000 write-back 2 base C000 mask E000 write-back 3 disabled 4 disabled 5 disabled 6 disabled 7 disabled TOM2: 00022000 aka 8704M x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 e820: update [mem 0xe000-0x] usable ==> reserved e820: last_pfn = 0xdfe90 max_arch_pfn = 0x4 Base memory trampoline at [88099000] 99000 size 24576 Using GB pages for direct mapping init_memory_mapping: [mem 0x-0x000f] [mem 0x-0x000f] page 4k BRK [0x019bf000, 0x019b] PGTABLE BRK [0x019c, 0x019c0fff] PGTABLE BRK [0x019c1000, 0x019c1fff] PGTABLE init_memory_mapping: [mem 0x21fe0-0x21fff] [mem 0x21fe0-0x21fff] page 2M BRK [0x019c2000, 0x019c2fff] PGTABLE init_memory_mapping: [mem 0x21c00-0x21fdf] [mem 0x21c00-0x21fdf] page 2M init_memory_mapping: [mem 0x2-0x21bff] [mem 0x2-0x21bff] page 2M init_memory_mapping: [mem 0x0010-0xdfe8] [mem 0x0010-0x001f] page 4k [mem 0x0020-0x3fff] page 2M [mem 0x4000-0xbfff] page 1G [mem 0xc000-0xdfdf] page 2M [mem 0xdfe0-0xdfe8] page 4k init_memory_mapping: [mem 0x1-0x1] [mem 0x1-0x1] page 1G ACPI: RSDP 0x000FB880 24 (v02 ACPIAM) ACPI: XSDT 0xDFE90100 5C (v01 041311 XSDT1656 20110413 MSFT 0097) ACPI: FACP 0xDFE90290 F4 (v03 041311 FACP1656 20110413 MSFT 0097) ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x/0x1 (20140214/tbfadt-634) ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20140214/tbfadt-603) ACPI: DSDT 0xDFE90450 00E6FE (v01 A1152 A1152000 INTL 20060113) ACPI: FACS 0xDFEA8000 40 ACPI: APIC 0xDFE90390 7C (v01 041311 APIC1656 20110413 MSFT 0097) ACPI: MCFG 0xDFE90410 3C (v01 041311 OEMMCFG 20110413 MSFT 0097) ACPI: OEMB 0xDFEA8040 72 (v01 041311 OEMB1656 20110413 MSFT 0097) ACPI: SRAT 0xDFE9F450 E8 (v01 AMDFAM_F_10 0002 AMD 0001) ACPI: HPET 0xDFE9F540 38 (v01 041311 OEMHPET 20110413 MSFT 0097) ACPI: SSDT 0xDFE9F580 00088C (v01 A M I POWERNOW 0001 AMD 0001) ACPI: Local APIC address 0xfee0 [ea00-ea00087f] PMD -> [88021760-88021f5f] on node 0 Zone ranges: DMA [mem 0x1000-0x00ff] DMA32[mem 0x0100-0x] Normal [mem 0x1-0x21fff] Movable zone start for each node Early memory node ranges node 0: [mem 0x1000-0x0009efff] node 0: [mem 0x0010-0xdfe8] node 0: [mem 0x1-0x21fff] On node 0 totalpages: 2096686 DMA zone:
[git pull] drm fixes
On 2014.04.20 at 11:56 +0200, Markus Trippelsdorf wrote: > On 2014.04.20 at 10:27 +0200, Christian K?nig wrote: > > > I did and it doesn't fix the issue. > > In this case please open up a new bugreport on > > https://bugs.freedesktop.org/enter_bug.cgi?product=DRI and select > > DRM/Radeon as component. > > > > Additional to that please provide a dmesg output generated with > > drm.debug=0xE for both the good and the bad case. > > Good vs. bad: Sorry it is actually bad vs. good: > -[drm:radeon_compute_pll_avivo] 146250 - 14439, pll dividers - fb: 2047.0 > ref: 29, post 7 > +[drm:radeon_compute_pll_avivo] 146250 - 14955, pll dividers - fb: 1023.5 > ref: 14, post 7 -- Markus
[Bug 77673] [bisected] moving moire starting with "drm/radeon: improve PLL params if we don't match exactly v2"
https://bugs.freedesktop.org/show_bug.cgi?id=77673 Christian K?nig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Christian K?nig --- Marking as fixed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/ecb4fe0b/attachment.html>
[PATCH] drm/radeon: Inline r100_mm_rreg, v2
Am 19.04.2014 19:33, schrieb Lauri Kasanen: > On Sat, 19 Apr 2014 11:15:53 -0400 > Alex Deucher wrote: > >> On Sat, Apr 19, 2014 at 6:06 AM, Christian K?nig This was originally un-inlined by Andi Kleen in 2011 citing size concerns. Indeed, a first attempt at inlining it grew radeon.ko by 7%. However, 2% of cpu is spent in this function. Simply inlining it gave 1% more fps in Urban Terror. v2: We know the minimum MMIO size. Adding it to the if allows the compiler to optimize the branch out, improving both performance and size. The v2 patch decreases radeon.ko size by 2%. I didn't re-benchmark, but common sense says perf is now more than 1% better. >>> Nice! >>> >>> But are you sure that the register PCI bar is always at least 64K in size? >>> Keep in mind that this code is used over all generations since R100. >>> Additional to that we probably should have a define for that and also apply >>> the optimizations to r100_mm_wreg as well. > Yes, I checked the earlier code. It had 64kb hard-coded, and when it > was changed in 2010 to use the dynamic value, the commit said later > asics are larger. (07bec2df01) > > A quick google also didn't find any dmesg with smaller values, R100 > cards had 64kb. Thanks for digging that up, this indeed sounds valid and like a very nice optimization. Just as suggested before add a define for this in radeon.h, something like RADEON_MIN_PCI_BAR_SIZE and do the same for r100_mm_wreg as well. >> If most of the register accesses are for the interrupt setup, I wonder >> if it would be better to just clean up the irq_set functions to reduce >> the register accesses. E.g., only touch the registers for the >> specific irq masks have changed. > Yes, that should also be done. But as this function is used elsewhere > as well, having it fast (not to mention the size decrease) would be > good. > > I think this patch is safe enough for 3.15, but perhaps it's too late > now. Yeah, probably. But 3.16 should work as well. Christian. > - Lauri
[PATCH v2 2/3] drm/exynos: add support for apb mapped phys in hdmi driver
From: Rahul Sharma
Previous SoCs have hdmi phys which are accessible through
dedicated i2c lines. Newer SoCs have Apb mapped hdmi phys.
Hdmi driver is modified to support apb mapped phys.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 142 +-
drivers/gpu/drm/exynos/regs-hdmi.h |7 ++
2 files changed, 96 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 438eeda..f4566b1 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -67,6 +68,8 @@ enum hdmi_type {
struct hdmi_driver_data {
unsigned int type;
+ const struct hdmiphy_config *phy_confs;
+ unsigned int phy_conf_count;
unsigned int is_apb_phy:1;
};
@@ -196,6 +199,9 @@ struct hdmi_context {
struct hdmi_resources res;
int hpd_gpio;
+ void __iomem*regs_hdmiphy;
+ const struct hdmiphy_config *phy_confs;
+ unsigned intphy_conf_count;
enum hdmi_type type;
};
@@ -205,14 +211,6 @@ struct hdmiphy_config {
u8 conf[32];
};
-struct hdmi_driver_data exynos4212_hdmi_driver_data = {
- .type = HDMI_TYPE14,
-};
-
-struct hdmi_driver_data exynos5_hdmi_driver_data = {
- .type = HDMI_TYPE14,
-};
-
/* list of phy config settings */
static const struct hdmiphy_config hdmiphy_v13_configs[] = {
{
@@ -427,6 +425,21 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] =
{
},
};
+
+struct hdmi_driver_data exynos4212_hdmi_driver_data = {
+ .type = HDMI_TYPE14,
+ .phy_confs = hdmiphy_v14_configs,
+ .phy_conf_count = ARRAY_SIZE(hdmiphy_v14_configs),
+ .is_apb_phy = 0,
+};
+
+struct hdmi_driver_data exynos5_hdmi_driver_data = {
+ .type = HDMI_TYPE14,
+ .phy_confs = hdmiphy_v13_configs,
+ .phy_conf_count = ARRAY_SIZE(hdmiphy_v13_configs),
+ .is_apb_phy = 0,
+};
+
static inline u32 hdmi_reg_read(struct hdmi_context *hdata, u32 reg_id)
{
return readl(hdata->regs + reg_id);
@@ -446,6 +459,48 @@ static inline void hdmi_reg_writemask(struct hdmi_context
*hdata,
writel(value, hdata->regs + reg_id);
}
+static int hdmiphy_reg_writeb(struct hdmi_context *hdata,
+ u32 reg_offset, u8 value)
+{
+ if (hdata->hdmiphy_port) {
+ u8 buffer[2];
+ int ret;
+
+ buffer[0] = reg_offset;
+ buffer[1] = value;
+
+ ret = i2c_master_send(hdata->hdmiphy_port, buffer, 2);
+ if (ret == 2)
+ return 0;
+ return ret;
+ } else {
+ writeb(value, hdata->regs_hdmiphy + (reg_offset<<2));
+ return 0;
+ }
+}
+
+static int hdmiphy_reg_write_buf(struct hdmi_context *hdata,
+ u32 reg_offset, const u8 *buf, u32 len)
+{
+ if ((reg_offset + len) > 32)
+ return -EINVAL;
+
+ if (hdata->hdmiphy_port) {
+ int ret;
+
+ ret = i2c_master_send(hdata->hdmiphy_port, buf, len);
+ if (ret == len)
+ return 0;
+ return ret;
+ } else {
+ int i;
+ for (i = 0; i < len; i++)
+ writeb(buf[i], hdata->regs_hdmiphy +
+ ((reg_offset + i)<<2));
+ return 0;
+ }
+}
+
static void hdmi_v13_regs_dump(struct hdmi_context *hdata, char *prefix)
{
#define DUMPREG(reg_id) \
@@ -849,20 +904,10 @@ static int hdmi_get_modes(struct drm_connector *connector)
static int hdmi_find_phy_conf(struct hdmi_context *hdata, u32 pixel_clock)
{
- const struct hdmiphy_config *confs;
- int count, i;
-
- if (hdata->type == HDMI_TYPE13) {
- confs = hdmiphy_v13_configs;
- count = ARRAY_SIZE(hdmiphy_v13_configs);
- } else if (hdata->type == HDMI_TYPE14) {
- confs = hdmiphy_v14_configs;
- count = ARRAY_SIZE(hdmiphy_v14_configs);
- } else
- return -EINVAL;
+ int i;
- for (i = 0; i < count; i++)
- if (confs[i].pixel_clock == pixel_clock)
+ for (i = 0; i < hdata->phy_conf_count; i++)
+ if (hdata->phy_confs[i].pixel_clock == pixel_clock)
return i;
DRM_DEBUG_KMS("Could not find phy config for %d\n", pixel_clock);
@@ -1514,17 +1559,9 @@ static void hdmiphy_poweroff(struct hdmi_context *hdata)
static void hdmiphy_conf_apply(struct hdmi_context *hdata)
{
- const u8 *hdmiphy_data;
- u8 buffer[32];
- u8 operation[2];
int ret;
int i;
- if (!hdata
[PATCH] drm/exynos: enable fimd clocks in probe before accessing fimd registers
From: Rahul Sharma Fimd probe is accessing fimd Registers without enabling the fimd gate clocks. This hangs the system at boot time. This issue got surfaced when verifying with sysmmu enabled. Probe of fimd Sysmmu enables the master clock before accessing sysmmu regs and then disables. Later fimd probe tries to read the reegister without enabling the clock which is wrong and hangs the system. Signed-off-by: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_drm_fimd.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 40fd6cc..8706fde 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -916,9 +916,15 @@ static int fimd_probe(struct platform_device *pdev) pm_runtime_enable(dev); + clk_prepare_enable(ctx->bus_clk); + clk_prepare_enable(ctx->lcd_clk); + for (win = 0; win < WINDOWS_NR; win++) fimd_clear_win(ctx, win); + clk_disable_unprepare(ctx->lcd_clk); + clk_disable_unprepare(ctx->bus_clk); + return 0; } -- 1.7.9.5
[PATCH v2 0/3] drm/exynos: enable support for exynos5420 hdmi
From: Rahul Sharma V2: 1) Rebased on Tomasz Stanislawski at https://lkml.org/lkml/2014/4/8/226. Adds apb mapped phy support for exynos5420 hdmi. Replace dummy hdmiphy clock with regmap calls. Based on Inki Dae's exynos-drm-next branch. Rahul Sharma (3): drm/exynos: remove unnecessary read for phy configuration values drm/exynos: add support for apb mapped phys in hdmi driver drm/exynos: enable support for exynos5420 hdmi device .../devicetree/bindings/video/exynos_hdmi.txt |1 + drivers/gpu/drm/exynos/exynos_hdmi.c | 317 drivers/gpu/drm/exynos/regs-hdmi.h |7 + 3 files changed, 262 insertions(+), 63 deletions(-) -- 1.7.9.5
[PATCH v2 1/3] drm/exynos: remove unnecessary read for phy configuration values
From: Rahul Sharma
Cleaning up unnecessary i2c read call after hdmiphy configuration.
This check is redundant since check for hdmiphy pll lock status
confirms the correct settings for phy.
Signed-off-by: Rahul Sharma
Signed-off-by: Daniel Kurtz
Reviewed-by: Tomasz Figa
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index ef1cdd0..438eeda 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1517,7 +1517,6 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata)
const u8 *hdmiphy_data;
u8 buffer[32];
u8 operation[2];
- u8 read_buffer[32] = {0, };
int ret;
int i;
@@ -1557,15 +1556,6 @@ static void hdmiphy_conf_apply(struct hdmi_context
*hdata)
return;
}
- ret = i2c_master_recv(hdata->hdmiphy_port, read_buffer, 32);
- if (ret < 0) {
- DRM_ERROR("failed to read hdmiphy config\n");
- return;
- }
-
- for (i = 0; i < ret; i++)
- DRM_DEBUG_KMS("hdmiphy[0x%02x] write[0x%02x] - "
- "recv [0x%02x]\n", i, buffer[i], read_buffer[i]);
}
static void hdmi_conf_apply(struct hdmi_context *hdata)
--
1.7.9.5
[PATCH v2 3/3] drm/exynos: enable support for exynos5420 hdmi device
From: Rahul Sharma
Enable support for hdmi for exynos5420 hdmiphy. Add
compatible string in the of_match table. Also added
hdmiphy configuration values for exynos5420.
Signed-off-by: Rahul Sharma
Signed-off-by: Shirish S
---
.../devicetree/bindings/video/exynos_hdmi.txt |1 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 165
2 files changed, 166 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..75ada04 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -5,6 +5,7 @@ Required properties:
1) "samsung,exynos5-hdmi"
2) "samsung,exynos4210-hdmi"
3) "samsung,exynos4212-hdmi"
+ 4) "samsung,exynos5420-hdmi"
- reg: physical base address of the hdmi and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f4566b1..93f48aa 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -425,6 +425,168 @@ static const struct hdmiphy_config hdmiphy_v14_configs[]
= {
},
};
+static const struct hdmiphy_config hdmiphy_5420_configs[] = {
+ {
+ .pixel_clock = 2520,
+ .conf = {
+ 0x01, 0x52, 0x3F, 0x55, 0x40, 0x01, 0x00, 0xC8,
+ 0x82, 0xC8, 0xBD, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+ 0x06, 0x80, 0x01, 0x84, 0x05, 0x02, 0x24, 0x66,
+ 0x54, 0xF4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0xD1, 0x22, 0x51, 0x40, 0x08, 0xFC, 0xE0,
+ 0x98, 0xE8, 0xCB, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+ 0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+ 0x54, 0xE4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0xD1, 0x2D, 0x72, 0x40, 0x64, 0x12, 0xC8,
+ 0x43, 0xE8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+ 0x26, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+ 0x54, 0xE3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
+ .pixel_clock = 3600,
+ .conf = {
+ 0x01, 0x51, 0x2D, 0x55, 0x40, 0x40, 0x00, 0xC8,
+ 0x02, 0xC8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+ 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+ 0x54, 0xAB, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
+ .pixel_clock = 4000,
+ .conf = {
+ 0x01, 0xD1, 0x21, 0x31, 0x40, 0x3C, 0x28, 0xC8,
+ 0x87, 0xE8, 0xC8, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+ 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+ 0x54, 0x9A, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
+ .pixel_clock = 6500,
+ .conf = {
+ 0x01, 0xD1, 0x36, 0x34, 0x40, 0x0C, 0x04, 0xC8,
+ 0x82, 0xE8, 0x45, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+ 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+ 0x54, 0xBD, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
+ .pixel_clock = 7100,
+ .conf = {
+ 0x01, 0xD1, 0x3B, 0x35, 0x40, 0x0C, 0x04, 0xC8,
+ 0x85, 0xE8, 0x63, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+ 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+ 0x54, 0x57, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
+ .pixel_clock = 7325,
+ .conf = {
+ 0x01, 0xD1, 0x1F, 0x10, 0x40, 0x78, 0x8D, 0xC8,
+ 0x81, 0xE8, 0xB7, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+ 0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+ 0x54, 0xA8, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0xD1, 0x1F, 0x10, 0x40, 0x5B, 0xEF, 0xC8,
+ 0x81, 0xE8, 0xB9, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+ 0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
+ 0x54, 0xA6, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf
[PATCH v2 0/3] drm/exynos: enable support for exynos5420 hdmi
From: Rahul Sharma V2: 1) Rebased on Tomasz Stanislawski's Simple phy driver patches at https://lkml.org/lkml/2014/4/8/226. Adds apb mapped phy support for exynos5420 hdmi. Replace dummy hdmiphy clock with regmap calls. Based on Inki Dae's exynos-drm-next branch. Rahul Sharma (3): drm/exynos: remove unnecessary read for phy configuration values drm/exynos: add support for apb mapped phys in hdmi driver drm/exynos: enable support for exynos5420 hdmi device .../devicetree/bindings/video/exynos_hdmi.txt |1 + drivers/gpu/drm/exynos/exynos_hdmi.c | 317 drivers/gpu/drm/exynos/regs-hdmi.h |7 + 3 files changed, 262 insertions(+), 63 deletions(-) -- 1.7.9.5
[PATCH 0/6] File Sealing & memfd_create()
On Thu 2014-04-10 13:37:26, Andy Lutomirski wrote:
> On Thu, Apr 10, 2014 at 1:32 PM, Theodore Ts'o wrote:
> > On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote:
> >>
> >> This is the second time in a week that someone has asked for a way to
> >> have a struct file (or struct inode or whatever) that can't be reopened
> >> through /proc/pid/fd. This should be quite easy to implement as a
> >> separate feature.
> >
> > What I suggested on a different thread was to add the following new
> > file descriptor flags, to join FD_CLOEXEC, which would be maniuplated
> > using the F_GETFD and F_SETFD fcntl commands:
> >
> > FD_NOPROCFS disallow being able to open the inode via /proc//fd
> >
> > FD_NOPASSFD disallow being able to pass the fd via a unix domain socket
> >
> > FD_LOCKFLAGSif this bit is set, disallow any further changes of
> > FD_CLOEXEC,
> > FD_NOPROCFS, FD_NOPASSFD, and FD_LOCKFLAGS flags.
> >
> > Regardless of what else we might need to meet the use case for the
> > proposed File Sealing API, I think this is a useful feature that could
> > be used in many other contexts besides just the proposed
> > memfd_create() use case.
>
> It occurs to me that, before going nuts with these kinds of flags, it
> may pay to just try to fix the /proc/self/fd issue for real -- we
> could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is
> read-only. That may be enough for the file sealing thing.
Yes please.
Current behaviour is very unexpected, and unexpected behaviour in
security area is normally called "security hole".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[git pull] drm fixes
Dropping Linus and LKML for now. Does the attached patch help? If not please open up a bug, tracking all those logs in mails can become quite painful. Christian. Am 20.04.2014 12:04, schrieb Markus Trippelsdorf: > On 2014.04.20 at 11:56 +0200, Markus Trippelsdorf wrote: >> On 2014.04.20 at 10:27 +0200, Christian K?nig wrote: >>>> I did and it doesn't fix the issue. >>> In this case please open up a new bugreport on >>> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI and select >>> DRM/Radeon as component. >>> >>> Additional to that please provide a dmesg output generated with >>> drm.debug=0xE for both the good and the bad case. >> Good vs. bad: > Sorry it is actually bad vs. good: > >> -[drm:radeon_compute_pll_avivo] 146250 - 14439, pll dividers - fb: 2047.0 >> ref: 29, post 7 >> +[drm:radeon_compute_pll_avivo] 146250 - 14955, pll dividers - fb: 1023.5 >> ref: 14, post 7 -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-improve-PLL-limit-handling-in-post-div-ca.patch Type: text/x-diff Size: 5279 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/5987cc2a/attachment.patch>
[git pull] drm fixes
On 2014.04.20 at 17:23 +0200, Christian K?nig wrote: > Dropping Linus and LKML for now. > > Does the attached patch help? If not please open up a bug, tracking all > those logs in mails can become quite painful. Yes, this patch if fine. Everything is working fine again. Thanks. -- Markus
[Bug 77677] HDMI audio on ati7750 choppy with ALSA multi-channel apps
https://bugs.freedesktop.org/show_bug.cgi?id=77677 --- Comment #5 from Garrett --- (In reply to comment #4) > Possibly a duplicate of bug 77002. Does the fix mentioned in that bug help? Thanks. But no, unfortunately. I tested the reverse order patch (on 77002). I believe it may be part of my kernel 3.14.1testing patched by Fritsch/Peter for the PLL/24P optimizations (which works great BTW). Trusty release default kernel 3.13 displayed the same behavior. I noticed that there were 2 patches (77002). I only tried the reverse order patch. Did you want me to test your patch? Please let me know if I can provide anything. I know of an ATI 7870 that also is affected (in case it helps). I have been trying to help another XBMC user on OpenElec (it uses pure ALSA). I am going to get a new HDMI AVR today. So I can further test 5.1 HDMI audio, too, if needed. thanks, Garrett -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/9029d7f6/attachment.html>
[Bug 77677] HDMI audio on ati7750 choppy with ALSA multi-channel apps
https://bugs.freedesktop.org/show_bug.cgi?id=77677 --- Comment #6 from Peter Fr?hberger --- Please reproduce with a mainline kernel. It's not really a good idea to find regressions, when it's not fully clear which patches are integrated. Additionally the 3.14.1 kernel that I build, includes a non gpl module to drive Ngene dvb-c adapters. Please try 3.14.1 or a 3.15-rcX (it's clear that the PLL work is not in there - but currently you are tracking down Audio issues). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/6a0d263c/attachment.html>
[PATCH] drm/radeon: disable dpm on rv770 by default
Alex Deucher wrote: > I ran into similar issues right after dpm support was released. I'd > done most of my development on gcc 4.6 and everything worked fine > and upon upgrading to 4.7 or 4.8, tons of stuff broke. It ended up > at least partially being related to indexing variable sized arrays: > 48fa04c3fcdb4f6ac041976bedaf19ca5bee20c0 > f90555cbe629e14c6af1dcec1933a3833ecd321f > 607f2c2791ec81e5abca6213ff037e9405378be1 > a7ee824a6255e347ea76e2f00827e81bbe01004e plus some others, but there > may still be problematic cases. Ahh, thanks for that, at least I know now there's no point in me building a whole new LFS.
[PATCH] drm/radeon: Inline r100_mm_rreg, -wreg, v3
This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
Indeed, a first attempt at inlining it grew radeon.ko by 7%.
However, 2% of cpu is spent in this function. Simply inlining it gave 1% more
fps
in Urban Terror.
v2: We know the minimum MMIO size. Adding it to the if allows the compiler to
optimize the branch out, improving both performance and size.
The v2 patch decreases radeon.ko size by 2%. I didn't re-benchmark, but common
sense
says perf is now more than 1% better.
v3: Also change _wreg, make the threshold a define.
Inlining _wreg increased the size a bit compared to v2, so now radeon.ko
is only 1% smaller.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/r100.c | 33 -
drivers/gpu/drm/radeon/radeon.h | 40
2 files changed, 36 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index b6c3264..a4e7871 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -4086,39 +4086,6 @@ int r100_init(struct radeon_device *rdev)
return 0;
}
-uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
- bool always_indirect)
-{
- if (reg < rdev->rmmio_size && !always_indirect)
- return readl(((void __iomem *)rdev->rmmio) + reg);
- else {
- unsigned long flags;
- uint32_t ret;
-
- spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
- writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
- ret = readl(((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
- spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
-
- return ret;
- }
-}
-
-void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v,
- bool always_indirect)
-{
- if (reg < rdev->rmmio_size && !always_indirect)
- writel(v, ((void __iomem *)rdev->rmmio) + reg);
- else {
- unsigned long flags;
-
- spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
- writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
- writel(v, ((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
- spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
- }
-}
-
u32 r100_io_rreg(struct radeon_device *rdev, u32 reg)
{
if (reg < rdev->rio_mem_size)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index f21db7a..a749b6c 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2328,10 +2328,42 @@ int radeon_device_init(struct radeon_device *rdev,
void radeon_device_fini(struct radeon_device *rdev);
int radeon_gpu_wait_for_idle(struct radeon_device *rdev);
-uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
- bool always_indirect);
-void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v,
- bool always_indirect);
+#define RADEON_MIN_MMIO_SIZE 0x1
+
+static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
+ bool always_indirect)
+{
+ /* The mmio size is 64kb at minimum. Allows the if to be optimized out.
*/
+ if ((reg < rdev->rmmio_size || reg < RADEON_MIN_MMIO_SIZE) &&
!always_indirect)
+ return readl(((void __iomem *)rdev->rmmio) + reg);
+ else {
+ unsigned long flags;
+ uint32_t ret;
+
+ spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
+ writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
+ ret = readl(((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
+ spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
+
+ return ret;
+ }
+}
+
+static inline void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg,
uint32_t v,
+ bool always_indirect)
+{
+ if ((reg < rdev->rmmio_size || reg < RADEON_MIN_MMIO_SIZE) &&
!always_indirect)
+ writel(v, ((void __iomem *)rdev->rmmio) + reg);
+ else {
+ unsigned long flags;
+
+ spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
+ writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
+ writel(v, ((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
+ spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
+ }
+}
+
u32 r100_io_rreg(struct radeon_device *rdev, u32 reg);
void r100_io_wreg(struct radeon_device *rdev, u32 reg, u32 v);
--
1.8.3.1
[Bug 42960] Display does not work when resuming from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=42960 --- Comment #40 from S. Christian Collins --- Adding the quirk lines from comment #34 worked for me. ** My System ** OS: Kubuntu 14.04 amd64 w/ KDE SC 4.13.0 PC: HP Pavilion m6-1035dx CPU/GPU: AMD A10-4600M APU with Radeon HD 7660G Graphics RAM: 6GB DDR3 800 MHz Linux Kernel: 3.13.0-24-generic Screen Resolution: 1366 x 768 Xserver: 2:1.15.1-0ubuntu2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140420/333b8c44/attachment.html>
[PATCH] drm/radeon: Inline r100_mm_rreg, -wreg, v3
Am 20.04.2014 19:29, schrieb Lauri Kasanen:
> This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
> Indeed, a first attempt at inlining it grew radeon.ko by 7%.
>
> However, 2% of cpu is spent in this function. Simply inlining it gave 1% more
> fps
> in Urban Terror.
>
> v2: We know the minimum MMIO size. Adding it to the if allows the compiler to
> optimize the branch out, improving both performance and size.
>
> The v2 patch decreases radeon.ko size by 2%. I didn't re-benchmark, but
> common sense
> says perf is now more than 1% better.
>
> v3: Also change _wreg, make the threshold a define.
>
> Inlining _wreg increased the size a bit compared to v2, so now radeon.ko
> is only 1% smaller.
>
> Signed-off-by: Lauri Kasanen
Reviewed-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/r100.c | 33 -
> drivers/gpu/drm/radeon/radeon.h | 40
>
> 2 files changed, 36 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index b6c3264..a4e7871 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -4086,39 +4086,6 @@ int r100_init(struct radeon_device *rdev)
> return 0;
> }
>
> -uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
> - bool always_indirect)
> -{
> - if (reg < rdev->rmmio_size && !always_indirect)
> - return readl(((void __iomem *)rdev->rmmio) + reg);
> - else {
> - unsigned long flags;
> - uint32_t ret;
> -
> - spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
> - writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
> - ret = readl(((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
> - spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
> -
> - return ret;
> - }
> -}
> -
> -void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v,
> - bool always_indirect)
> -{
> - if (reg < rdev->rmmio_size && !always_indirect)
> - writel(v, ((void __iomem *)rdev->rmmio) + reg);
> - else {
> - unsigned long flags;
> -
> - spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
> - writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
> - writel(v, ((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
> - spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
> - }
> -}
> -
> u32 r100_io_rreg(struct radeon_device *rdev, u32 reg)
> {
> if (reg < rdev->rio_mem_size)
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index f21db7a..a749b6c 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2328,10 +2328,42 @@ int radeon_device_init(struct radeon_device *rdev,
> void radeon_device_fini(struct radeon_device *rdev);
> int radeon_gpu_wait_for_idle(struct radeon_device *rdev);
>
> -uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
> - bool always_indirect);
> -void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v,
> - bool always_indirect);
> +#define RADEON_MIN_MMIO_SIZE 0x1
> +
> +static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t reg,
> + bool always_indirect)
> +{
> + /* The mmio size is 64kb at minimum. Allows the if to be optimized out.
> */
> + if ((reg < rdev->rmmio_size || reg < RADEON_MIN_MMIO_SIZE) &&
> !always_indirect)
> + return readl(((void __iomem *)rdev->rmmio) + reg);
> + else {
> + unsigned long flags;
> + uint32_t ret;
> +
> + spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
> + writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
> + ret = readl(((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
> + spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
> +
> + return ret;
> + }
> +}
> +
> +static inline void r100_mm_wreg(struct radeon_device *rdev, uint32_t reg,
> uint32_t v,
> + bool always_indirect)
> +{
> + if ((reg < rdev->rmmio_size || reg < RADEON_MIN_MMIO_SIZE) &&
> !always_indirect)
> + writel(v, ((void __iomem *)rdev->rmmio) + reg);
> + else {
> + unsigned long flags;
> +
> + spin_lock_irqsave(&rdev->mmio_idx_lock, flags);
> + writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX);
> + writel(v, ((void __iomem *)rdev->rmmio) + RADEON_MM_DATA);
> + spin_unlock_irqrestore(&rdev->mmio_idx_lock, flags);
> + }
> +}
> +
> u32 r100_io_rreg(struct radeon_device *rdev, u32 reg);
> void r100_io_wreg(struct radeon_device *rdev, u32 reg, u32 v);
>
[Bug 73901] Kernel crash after modprobe radeon runpm=1
https://bugzilla.kernel.org/show_bug.cgi?id=73901 --- Comment #15 from Pali Roh?r --- Now I tested this patch with 3.15-rc2 kernel and no kernel crash with runpm=1 anymore... But there is another problem, runpm=1 somehow not working correctly. It does not poweroff radeon card when it is not used. -- You are receiving this mail because: You are watching the assignee of the bug.
Warning on resume
I got this on my desktop (Haswell) box when resuming from suspend with Debian testing kernel (3.13). [147765.739493] [ cut here ] [147765.739501] WARNING: CPU: 1 PID: 29426 at /build/linux-oxWk_8/linux-3.13.7/drivers/gpu/drm/i915/intel_ddi.c:763 intel_ddi_pll_mode_set+0x218/0x8e0 [i915]() [147765.739502] WRPLL already enabled [147765.739513] Modules linked in: nls_utf8 nls_cp437 vfat fat ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp tun bridge stp llc usb_storage ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables bnep rfcomm bluetooth rfkill cpufreq_conservative cpufreq_stats cpufreq_userspace cpufreq_powersave binfmt_misc sch_fq_codel fuse loop parport_pc ppdev lp parport snd_hda_codec_hdmi snd_hda_codec_realtek x86_pkg_temp_thermal intel_powerclamp iTCO_wdt coretemp iTCO_vendor_support kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel evdev aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper snd_seq_midi snd_hda_intel snd_seq_midi_event cryptd snd_hda_codec psmouse snd_rawmidi serio_raw snd_hwdep snd_pcm_oss snd_mixer_oss lpc_ich i915 mfd_core snd_seq snd_pcm snd_seq_device snd_page_alloc i2c_i801 snd_timer drm_kms_helper snd drm mei_me video mei soundcore processor button ext4 crc16 mbcache jbd2 btrfs xor raid6_pq crc32c libcrc32c dm_mod sg sd_mod sr_mod crc_t10dif cdrom crct10dif_common hid_generic hid_belkin usbhid hid ahci libahci firewire_ohci libata scsi_mod firewire_core crc_itu_t igb ehci_pci xhci_hcd i2c_algo_bit ehci_hcd e1000e i2c_core fan usbcore thermal usb_common thermal_sys ixgbe dca ptp pps_core mdio [147765.739526] CPU: 1 PID: 29426 Comm: kworker/u16:29 Tainted: GW 3.13-1-amd64 #1 Debian 3.13.7-1 [147765.739526] Hardware name: Supermicro X10SAE/X10SAE, BIOS 1.1a 01/03/2014 [147765.739528] Workqueue: events_unbound async_run_entry_fn [147765.739530] 0009 814a1327 8802ae387a88 8105ba72 [147765.739531] 88040b23c000 8802ae387ad8 0001 000278d0 [147765.739532] 880409928000 8105bad7 a0541431 88040018 [147765.739532] Call Trace: [147765.739534] [] ? dump_stack+0x41/0x51 [147765.739535] [] ? warn_slowpath_common+0x72/0x90 [147765.739536] [] ? warn_slowpath_fmt+0x47/0x50 [147765.739542] [] ? gen6_read32+0x48/0x110 [i915] [147765.739548] [] ? intel_ddi_pll_mode_set+0x218/0x8e0 [i915] [147765.739554] [] ? ironlake_enable_vblank+0x26/0x80 [i915] [147765.739560] [] ? haswell_crtc_mode_set+0x36/0x480 [i915] [147765.739566] [] ? __intel_set_mode+0x646/0x1500 [i915] [147765.739571] [] ? gen6_read32+0x48/0x110 [i915] [147765.739577] [] ? intel_modeset_setup_hw_state+0xb19/0xc20 [i915] [147765.739581] [] ? __i915_drm_thaw+0x14a/0x200 [i915] [147765.739585] [] ? i915_resume+0x51/0x70 [i915] [147765.739587] [] ? pci_pm_thaw+0x90/0x90 [147765.739588] [] ? dpm_run_callback+0x2e/0x70 [147765.739589] [] ? device_resume+0x8c/0x180 [147765.739591] [] ? async_resume+0x14/0x40 [147765.739592] [] ? async_run_entry_fn+0x2d/0x120 [147765.739593] [] ? process_one_work+0x16d/0x420 [147765.739594] [] ? worker_thread+0x116/0x3b0 [147765.739596] [] ? rescuer_thread+0x330/0x330 [147765.739596] [] ? kthread+0xc1/0xe0 [147765.739597] [] ? kthread_create_on_node+0x180/0x180 [147765.739599] [] ? ret_from_fork+0x7c/0xb0 [147765.739600] [] ? kthread_create_on_node+0x180/0x180 [147765.739600] ---[ end trace f16ec95e5a50ba64 ]---
