Re: [PATCH v4 13/15] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT

2024-05-24 Thread Alex Deucher 
On Fri, May 24, 2024 at 5:16 AM Guenter Roeck  wrote:
>
> Hi,
>
> On Fri, Mar 29, 2024 at 12:18:28AM -0700, Samuel Holland wrote:
> > Now that all previously-supported architectures select
> > ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
> > of the existing list of architectures. It can also take advantage of the
> > common kernel-mode FPU API and method of adjusting CFLAGS.
> >
> > Acked-by: Alex Deucher 
> > Reviewed-by: Christoph Hellwig 
> > Signed-off-by: Samuel Holland 
>
> With this patch in the mainline kernel, I get the following build error
> when trying to build powerpc:ppc32_allmodconfig.
>
> powerpc64-linux-ld: 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o uses hard 
> float, drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.o 
> uses soft float
> powerpc64-linux-ld: failed to merge target specific data of file 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
>
> [ repeated many times ]
>
> The problem is no longer seen after reverting this patch.

Should be fixed with this patch:
https://gitlab.freedesktop.org/agd5f/linux/-/commit/5f56be33f33dd1d50b9433f842c879a20dc00f5b
Will pull it into my -fixes branch.

Alex

>
> Guenter

Re: [PATCH v4 13/15] drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT

2024-05-24 Thread Alex Deucher 
On Fri, May 24, 2024 at 9:17 AM Alex Deucher  wrote:
>
> On Fri, May 24, 2024 at 5:16 AM Guenter Roeck  wrote:
> >
> > Hi,
> >
> > On Fri, Mar 29, 2024 at 12:18:28AM -0700, Samuel Holland wrote:
> > > Now that all previously-supported architectures select
> > > ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
> > > of the existing list of architectures. It can also take advantage of the
> > > common kernel-mode FPU API and method of adjusting CFLAGS.
> > >
> > > Acked-by: Alex Deucher 
> > > Reviewed-by: Christoph Hellwig 
> > > Signed-off-by: Samuel Holland 
> >
> > With this patch in the mainline kernel, I get the following build error
> > when trying to build powerpc:ppc32_allmodconfig.
> >
> > powerpc64-linux-ld: 
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o uses hard 
> > float, drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.o 
> > uses soft float
> > powerpc64-linux-ld: failed to merge target specific data of file 
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> >
> > [ repeated many times ]
> >
> > The problem is no longer seen after reverting this patch.
>
> Should be fixed with this patch:
> https://gitlab.freedesktop.org/agd5f/linux/-/commit/5f56be33f33dd1d50b9433f842c879a20dc00f5b
> Will pull it into my -fixes branch.
>

Nevermind, this is something else.

Alex


> Alex
>
> >
> > Guenter

Re: [PATCH 0/3] Update LLVM Phabricator and Bugzilla links

2024-01-12 Thread Alex Deucher 
On Tue, Jan 9, 2024 at 5:26 PM Nathan Chancellor  wrote:
>
> This series updates all instances of LLVM Phabricator and Bugzilla links
> to point to GitHub commits directly and LLVM's Bugzilla to GitHub issue
> shortlinks respectively.
>
> I split up the Phabricator patch into BPF selftests and the rest of the
> kernel in case the BPF folks want to take it separately from the rest of
> the series, there are obviously no dependency issues in that case. The
> Bugzilla change was mechanical enough and should have no conflicts.
>
> I am aiming this at Andrew and CC'ing other lists, in case maintainers
> want to chime in, but I think this is pretty uncontroversial (famous
> last words...).
>

Acked-by: Alex Deucher 

> ---
> Nathan Chancellor (3):
>   selftests/bpf: Update LLVM Phabricator links
>   arch and include: Update LLVM Phabricator links
>   treewide: Update LLVM Bugzilla links
>
>  arch/arm64/Kconfig |  4 +--
>  arch/powerpc/Makefile  |  4 +--
>  arch/powerpc/kvm/book3s_hv_nested.c|  2 +-
>  arch/riscv/Kconfig |  2 +-
>  arch/riscv/include/asm/ftrace.h|  2 +-
>  arch/s390/include/asm/ftrace.h |  2 +-
>  arch/x86/power/Makefile|  2 +-
>  crypto/blake2b_generic.c   |  2 +-
>  drivers/firmware/efi/libstub/Makefile  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c   |  2 +-
>  drivers/media/test-drivers/vicodec/codec-fwht.c|  2 +-
>  drivers/regulator/Kconfig  |  2 +-
>  include/asm-generic/vmlinux.lds.h  |  2 +-
>  include/linux/compiler-clang.h |  2 +-
>  lib/Kconfig.kasan  |  2 +-
>  lib/raid6/Makefile |  2 +-
>  lib/stackinit_kunit.c  |  2 +-
>  mm/slab_common.c   |  2 +-
>  net/bridge/br_multicast.c  |  2 +-
>  security/Kconfig   |  2 +-
>  tools/testing/selftests/bpf/README.rst | 32 
> +++---
>  tools/testing/selftests/bpf/prog_tests/xdpwall.c   |  2 +-
>  .../selftests/bpf/progs/test_core_reloc_type_id.c  |  2 +-
>  23 files changed, 40 insertions(+), 40 deletions(-)
> ---
> base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a
> change-id: 20240109-update-llvm-links-d03f9d649e1e
>
> Best regards,
> --
> Nathan Chancellor 
>

Re: [PATCH v2 00/14] Unified cross-architecture kernel-mode FPU API

2024-01-03 Thread Alex Deucher 
On Thu, Dec 28, 2023 at 5:11 AM Samuel Holland
 wrote:
>
> This series unifies the kernel-mode FPU API across several architectures
> by wrapping the existing functions (where needed) in consistently-named
> functions placed in a consistent header location, with mostly the same
> semantics: they can be called from preemptible or non-preemptible task
> context, and are not assumed to be reentrant. Architectures are also
> expected to provide CFLAGS adjustments for compiling FPU-dependent code.
> For the moment, SIMD/vector units are out of scope for this common API.
>
> This allows us to remove the ifdeffery and duplicated Makefile logic at
> each FPU user. It then implements the common API on RISC-V, and converts
> a couple of users to the new API: the AMDGPU DRM driver, and the FPU
> self test.
>
> The underlying goal of this series is to allow using newer AMD GPUs
> (e.g. Navi) on RISC-V boards such as SiFive's HiFive Unmatched. Those
> GPUs need CONFIG_DRM_AMD_DC_FP to initialize, which requires kernel-mode
> FPU support.

Series is:
Acked-by: Alex Deucher 

>
> Previous versions:
> v1: 
> https://lore.kernel.org/linux-kernel/20231208055501.2916202-1-samuel.holl...@sifive.com/
> v0: 
> https://lore.kernel.org/linux-kernel/20231122030621.3759313-1-samuel.holl...@sifive.com/
>
> Changes in v2:
>  - Add documentation explaining the built-time and runtime APIs
>  - Add a linux/fpu.h header for generic isolation enforcement
>  - Remove file name from header comment
>  - Clean up arch/arm64/lib/Makefile, like for arch/arm
>  - Remove RISC-V architecture-specific preprocessor check
>  - Split altivec removal to a separate patch
>  - Use linux/fpu.h instead of asm/fpu.h in consumers
>  - Declare test_fpu() in a header
>
> Michael Ellerman (1):
>   drm/amd/display: Only use hard-float, not altivec on powerpc
>
> Samuel Holland (13):
>   arch: Add ARCH_HAS_KERNEL_FPU_SUPPORT
>   ARM: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
>   ARM: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
>   arm64: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
>   arm64: crypto: Use CC_FLAGS_FPU for NEON CFLAGS
>   lib/raid6: Use CC_FLAGS_FPU for NEON CFLAGS
>   LoongArch: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
>   powerpc: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
>   x86: Implement ARCH_HAS_KERNEL_FPU_SUPPORT
>   riscv: Add support for kernel-mode FPU
>   drm/amd/display: Use ARCH_HAS_KERNEL_FPU_SUPPORT
>   selftests/fpu: Move FP code to a separate translation unit
>   selftests/fpu: Allow building on other architectures
>
>  Documentation/core-api/floating-point.rst | 78 +++
>  Documentation/core-api/index.rst  |  1 +
>  Makefile  |  5 ++
>  arch/Kconfig  |  6 ++
>  arch/arm/Kconfig  |  1 +
>  arch/arm/Makefile |  7 ++
>  arch/arm/include/asm/fpu.h| 15 
>  arch/arm/lib/Makefile |  3 +-
>  arch/arm64/Kconfig|  1 +
>  arch/arm64/Makefile   |  9 ++-
>  arch/arm64/include/asm/fpu.h  | 15 
>  arch/arm64/lib/Makefile   |  6 +-
>  arch/loongarch/Kconfig|  1 +
>  arch/loongarch/Makefile   |  5 +-
>  arch/loongarch/include/asm/fpu.h  |  1 +
>  arch/powerpc/Kconfig  |  1 +
>  arch/powerpc/Makefile |  5 +-
>  arch/powerpc/include/asm/fpu.h| 28 +++
>  arch/riscv/Kconfig|  1 +
>  arch/riscv/Makefile   |  3 +
>  arch/riscv/include/asm/fpu.h  | 16 
>  arch/riscv/kernel/Makefile|  1 +
>  arch/riscv/kernel/kernel_mode_fpu.c   | 28 +++
>  arch/x86/Kconfig  |  1 +
>  arch/x86/Makefile | 20 +
>  arch/x86/include/asm/fpu.h| 13 
>  drivers/gpu/drm/amd/display/Kconfig   |  2 +-
>  .../gpu/drm/amd/display/amdgpu_dm/dc_fpu.c| 35 +
>  drivers/gpu/drm/amd/display/dc/dml/Makefile   | 36 +
>  drivers/gpu/drm/amd/display/dc/dml2/Makefile  | 36 +
>  include/linux/fpu.h   | 12 +++
>  lib/Kconfig.debug |  2 +-
>  lib/Makefile  | 26 +--
>  lib/raid6/Makefile| 31 ++--
>  lib/test_fpu.h|  8 ++
>  lib/{test_fpu.c => test_fpu_glue.c}   | 37 ++---
>  lib/test_fpu_impl.c   | 37 +
>  37 files changed

Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

2023-05-13 Thread Alex Deucher 
On Sat, May 13, 2023 at 12:11 PM Greg Kroah-Hartman
 wrote:
>
> On Fri, May 12, 2023 at 03:25:47PM +, Christophe Leroy wrote:
> >
> >
> > Le 12/05/2023 à 17:16, Christophe Leroy a écrit :
> > >
> > >
> > > Le 11/05/2023 à 19:25, Niccolò Belli a écrit :
> > >> [Vous ne recevez pas souvent de courriers de
> > >> darkba...@linuxsystems.it. D?couvrez pourquoi ceci est important ?
> > >> https://aka.ms/LearnAboutSenderIdentification ]
> > >>
> > >> Il 2023-05-12 10:32 Bagas Sanjaya ha scritto:
> > >>> #regzbot introduced: f4f3b7dedbe849
> > >>> #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/2553
> > >>
> > >> It doesn't look like the aforementioned patch made its way into 6.3 yet:
> > >>
> > >> niko@talos2 ~/devel/linux-stable $ git branch
> > >> * linux-6.3.y
> > >>master
> > >> niko@talos2 ~/devel/linux-stable $ git show f4f3b7dedbe8 | patch -p1
> > >> patching file
> > >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > >> Hunk #1 succeeded at 227 (offset 15 lines).
> > >> Hunk #2 succeeded at 269 with fuzz 2 (offset 19 lines).
> > >> patching file
> > >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
> > >> Hunk #1 succeeded at 49 with fuzz 2 (offset 15 lines).
> > >
> > > As far as I can see that patch has no Fixes: tag, so it will unlikely be
> > > automatically merged into stable.
> > >
> > > Has anybody requested greg/sasha to get it into 6.3 ?
> > >
> >
> > In fact, it seems that patch is already part of 6.3:
> >
> > $ git tag --contains f4f3b7dedbe8
> > v6.3
> > v6.3-rc5
> > v6.3-rc6
> > v6.3-rc7
> > v6.3.1
> > v6.3.2
> > v6.4-rc1
>
> And that commit is already in the following releases:
> 5.10.177 5.15.106 6.1.23 6.2.10 6.3
>
> So what needs to be done here?

Nothing needs to be done here.  We still don't know what the problem
is.  We are working on the issue on:
https://gitlab.freedesktop.org/drm/amd/-/issues/2553
Let's just track it there.  This email thread is just causing confusion.

Alex

>
> confused,
>
> greg k-h

Re: Fwd: Linux 6.3.1 + AMD RX 570 on ppc64le 4K: Kernel attempted to read user page (1128) - exploit attempt? (uid: 0)

2023-05-12 Thread Alex Deucher 
On Fri, May 12, 2023 at 11:16 AM Christophe Leroy
 wrote:
>
>
>
> Le 11/05/2023 à 19:25, Niccolò Belli a écrit :
> > [Vous ne recevez pas souvent de courriers de darkba...@linuxsystems.it.
> > D?couvrez pourquoi ceci est important ?
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > Il 2023-05-12 10:32 Bagas Sanjaya ha scritto:
> >> #regzbot introduced: f4f3b7dedbe849
> >> #regzbot link: https://gitlab.freedesktop.org/drm/amd/-/issues/2553
> >
> > It doesn't look like the aforementioned patch made its way into 6.3 yet:
> >
> > niko@talos2 ~/devel/linux-stable $ git branch
> > * linux-6.3.y
> >master
> > niko@talos2 ~/devel/linux-stable $ git show f4f3b7dedbe8 | patch -p1
> > patching file
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > Hunk #1 succeeded at 227 (offset 15 lines).
> > Hunk #2 succeeded at 269 with fuzz 2 (offset 19 lines).
> > patching file
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
> > Hunk #1 succeeded at 49 with fuzz 2 (offset 15 lines).
>
> As far as I can see that patch has no Fixes: tag, so it will unlikely be
> automatically merged into stable.
>
> Has anybody requested greg/sasha to get it into 6.3 ?

This is no fix identified yet.

Alex

Re: Build regressions/improvements in v6.2-rc1

2023-01-06 Thread Alex Deucher 
On Tue, Dec 27, 2022 at 10:34 AM Geert Uytterhoeven
 wrote:
>
> On Tue, 27 Dec 2022, Geert Uytterhoeven wrote:
> > Below is the list of build error/warning regressions/improvements in
> > v6.2-rc1[1] compared to v6.1[2].
> >
> > Summarized:
> >  - build errors: +11/-13
>
> amd-...@lists.freedesktop.org
> linux-arm-ker...@lists.infradead.org
> linux-me...@vger.kernel.org
> linux-wirel...@vger.kernel.org
> linux-m...@vger.kernel.org
> linux...@vger.kernel.org
> linux-f2fs-de...@lists.sourceforge.net
> linuxppc-dev@lists.ozlabs.org
> kasan-...@googlegroups.com
> linux-xte...@linux-xtensa.org
>
>+ 
> /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:
>  error: the frame size of 2224 bytes is larger than 2048 bytes 
> [-Werror=frame-larger-than=]:  => 7082:1
>+ 
> /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c:
>  error: the frame size of 2208 bytes is larger than 2048 bytes 
> [-Werror=frame-larger-than=]:  => 7127:1
>

@Siqueira, Rodrigo @Mahfooz, Hamza

Can you take a look at fixing the DML stack size here up?

Alex


> arm64-gcc5/arm64-allmodconfig
>
>+ /kisskb/src/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c: error: array 
> subscript 2 is above array bounds of 'u32[2]' {aka 'unsigned int[2]'} 
> [-Werror=array-bounds]:  => 641:28
>+ /kisskb/src/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c: error: array 
> subscript 3 is above array bounds of 'u32[2]' {aka 'unsigned int[2]'} 
> [-Werror=array-bounds]:  => 641:28
>
> m68k-gcc8/m68k-allmodconfig
> See also 
> https://lore.kernel.org/all/camuhmdwppx2mpqfewjjbjsqvdbqoxyjjdpknqu9qurauvzx...@mail.gmail.com
>
>+ /kisskb/src/include/linux/bitfield.h: error: call to '__field_overflow' 
> declared with attribute error: value doesn't fit into mask:  => 151:3
>
> In function 'u32_encode_bits',
>  inlined from 'ieee80211_mlo_multicast_tx' at 
> /kisskb/src/net/mac80211/tx.c:4435:17,
>  inlined from 'ieee80211_subif_start_xmit' at 
> /kisskb/src/net/mac80211/tx.c:4483:3:
>
> mipsel-gcc5/mips-allmodconfig
>
>+ /kisskb/src/include/linux/compiler_types.h: error: call to 
> '__compiletime_assert_262' declared with attribute error: Unsupported access 
> size for {READ,WRITE}_ONCE().:  => 358:45
>+ /kisskb/src/include/linux/compiler_types.h: error: call to 
> '__compiletime_assert_263' declared with attribute error: Unsupported access 
> size for {READ,WRITE}_ONCE().:  => 358:45
>
> In function 'follow_pmd_mask',
>  inlined from 'follow_pud_mask' at /kisskb/src/mm/gup.c:735:9,
>  inlined from 'follow_p4d_mask' at /kisskb/src/mm/gup.c:752:9,
>  inlined from 'follow_page_mask' at /kisskb/src/mm/gup.c:809:9:
>
> sh4-gcc11/sh-defconfig (Günter wondered if pmd_t should use union)
>
>+ /kisskb/src/include/linux/fortify-string.h: error: '__builtin_memcpy' 
> offset [0, 127] is out of the bounds [0, 0] [-Werror=array-bounds]:  => 57:33
>
> /kisskb/src/arch/s390/kernel/setup.c: In function 'setup_lowcore_dat_on':
> s390x-gcc11/s390-all{mod,yes}config
>
>+ /kisskb/src/include/linux/fortify-string.h: error: '__builtin_memset' 
> pointer overflow between offset [28, 898293814] and size [-898293787, -1] 
> [-Werror=array-bounds]:  => 59:33
>
> /kisskb/src/fs/f2fs/inline.c: In function 'f2fs_move_inline_dirents':
>
> powerpc-gcc11/ppc64_book3e_allmodconfig
> powerpc-gcc11/powerpc-all{mod,yes}config
>
>+ /kisskb/src/kernel/kcsan/kcsan_test.c: error: the frame size of 1680 
> bytes is larger than 1536 bytes [-Werror=frame-larger-than=]:  => 257:1
>
> xtensa-gcc11/xtensa-allmodconfig (patch available)
>
>+ {standard input}: Error: unknown pseudo-op: `.cfi_def_c':  => 1718
>
> sh4-gcc11/sh-allmodconfig (ICE = internal compiler error)
>
> > [1] 
> > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/1b929c02afd37871d5afb9d498426f83432e71c2/
> >  (all 152 configs)
> > [2] 
> > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/830b3c68c1fb1e9176028d02ef86f3cf76aa2476/
> >  (all 152 configs)
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCH] powerpc: export cpu_smallcore_map for modules

2022-08-22 Thread Alex Deucher 
On Mon, Aug 22, 2022 at 9:16 AM Christoph Hellwig  wrote:
>
> On Mon, Aug 22, 2022 at 01:40:23PM +1000, Michael Ellerman wrote:
> > Randy Dunlap  writes:
> > > drivers/gpu/drm/amd/amdkfd/kfd_device.c calls cpu_smt_mask().
> > > This is an inline function on powerpc which references
> > > cpu_smallcore_map.
> > >
> > > Fixes: 425752c63b6f ("powerpc: Detect the presence of big-cores via "ibm, 
> > > thread-groups"")
> > > Fixes: 7bc913085765 ("drm/amdkfd: Try to schedule bottom half on same 
> > > core")
> >
> > That 2nd commit is not in mainline, only linux-next.
> >
> > I don't mind merging this fix preemptively, but is that SHA stable?
>
> I really do not think this has any business being exported at all.
>
> kfd_queue_work is not something that should be done in a driver.
> Something like this belongs into the workqueue core, not in an
> underdocumented helper in a random driver.
>
> Drm guys:  once again, please please work with the maintainers instead
> of just making up random stuff in the drivers.

Discussions are already ongoing with the workqueue folks.  I'll drop
this for now.

Alex

Re: [PATCH] powerpc: export cpu_smallcore_map for modules

2022-08-19 Thread Alex Deucher 
On Fri, Aug 19, 2022 at 6:18 PM Randy Dunlap  wrote:
>
> Fix build error when CONFIG_DRM_AMDGPU=m:
>
> ERROR: modpost: "cpu_smallcore_map" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] 
> undefined!
>
> by exporting 'cpu_smallcore_map' just as other per_cpu
> symbols are exported.
>
> drivers/gpu/drm/amd/amdkfd/kfd_device.c calls cpu_smt_mask().
> This is an inline function on powerpc which references
> cpu_smallcore_map.
>
> Fixes: 425752c63b6f ("powerpc: Detect the presence of big-cores via "ibm, 
> thread-groups"")
> Fixes: 7bc913085765 ("drm/amdkfd: Try to schedule bottom half on same core")
> Signed-off-by: Randy Dunlap 
> Cc: Gautham R. Shenoy 
> Cc: Michael Ellerman 
> Cc: Nicholas Piggin 
> Cc: Christophe Leroy 
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: amd-...@lists.freedesktop.org
> Cc: Felix Kuehling 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: "Pan, Xinhui" 

Acked-by: Alex Deucher 

> ---
>  arch/powerpc/kernel/smp.c |1 +
>  1 file changed, 1 insertion(+)
>
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -86,6 +86,7 @@ DEFINE_PER_CPU(cpumask_var_t, cpu_core_m
>  static DEFINE_PER_CPU(cpumask_var_t, cpu_coregroup_map);
>
>  EXPORT_PER_CPU_SYMBOL(cpu_sibling_map);
> +EXPORT_PER_CPU_SYMBOL(cpu_smallcore_map);
>  EXPORT_PER_CPU_SYMBOL(cpu_l2_cache_map);
>  EXPORT_PER_CPU_SYMBOL(cpu_core_map);
>  EXPORT_SYMBOL_GPL(has_big_cores);

Re: Build regressions/improvements in v5.17-rc1

2022-01-24 Thread Alex Deucher 
On Mon, Jan 24, 2022 at 5:25 AM Geert Uytterhoeven  wrote:
>
> On Sun, 23 Jan 2022, Geert Uytterhoeven wrote:
> > Below is the list of build error/warning regressions/improvements in
> > v5.17-rc1[1] compared to v5.16[2].
> >
> > Summarized:
> >  - build errors: +17/-2
> >  - build warnings: +23/-25
> >
> > Note that there may be false regressions, as some logs are incomplete.
> > Still, they're build errors/warnings.
> >
> > Happy fixing! ;-)
> >
> > Thanks to the linux-next team for providing the build service.
> >
> > [1] 
> > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/e783362eb54cd99b2cac8b3a9aeac942e6f6ac07/
> >  (all 99 configs)
> > [2] 
> > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/df0cc57e057f18e44dac8e6c18aba47ab53202f9/
> >  (98 out of 99 configs)
> >
> >
> > *** ERRORS ***
> >
> > 17 error regressions:
> >  + /kisskb/src/arch/powerpc/kernel/stacktrace.c: error: implicit 
> > declaration of function 'nmi_cpu_backtrace' 
> > [-Werror=implicit-function-declaration]:  => 171:2
> >  + /kisskb/src/arch/powerpc/kernel/stacktrace.c: error: implicit 
> > declaration of function 'nmi_trigger_cpumask_backtrace' 
> > [-Werror=implicit-function-declaration]:  => 226:2
>
> powerpc-gcc5/skiroot_defconfig
>
> >  + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible 
> > function types from 'void (*)(long unsigned int)' to 'void (*)(long 
> > unsigned int,  long unsigned int,  long unsigned int,  long unsigned int,  
> > long unsigned int)' [-Werror=cast-function-type]:  => 1756:13, 1639:13
> >  + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible 
> > function types from 'void (*)(struct mm_struct *)' to 'void (*)(long 
> > unsigned int,  long unsigned int,  long unsigned int,  long unsigned int,  
> > long unsigned int)' [-Werror=cast-function-type]:  => 1674:29, 1662:29
> >  + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible 
> > function types from 'void (*)(struct mm_struct *, long unsigned int)' to 
> > 'void (*)(long unsigned int,  long unsigned int,  long unsigned int,  long 
> > unsigned int,  long unsigned int)' [-Werror=cast-function-type]:  => 1767:21
> >  + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible 
> > function types from 'void (*)(struct vm_area_struct *, long unsigned int)' 
> > to 'void (*)(long unsigned int,  long unsigned int,  long unsigned int,  
> > long unsigned int,  long unsigned int)' [-Werror=cast-function-type]:  => 
> > 1741:29, 1726:29
> >  + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible 
> > function types from 'void (*)(struct vm_area_struct *, long unsigned int,  
> > long unsigned int)' to 'void (*)(long unsigned int,  long unsigned int,  
> > long unsigned int,  long unsigned int,  long unsigned int)' 
> > [-Werror=cast-function-type]:  => 1694:29, 1711:29
>
> sparc64-gcc11/sparc-allmodconfig
>
> >  + /kisskb/src/arch/um/include/asm/processor-generic.h: error: called 
> > object is not a function or function pointer:  => 103:18
> >  + /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: assignment makes 
> > pointer from integer without a cast [-Werror=int-conversion]:  => 324:9, 
> > 317:9
> >  + /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: implicit 
> > declaration of function 'ioport_map' 
> > [-Werror=implicit-function-declaration]:  => 317:11
> >  + /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: implicit 
> > declaration of function 'ioport_unmap' 
> > [-Werror=implicit-function-declaration]:  => 338:15
>
> um-x86_64/um-allyesconfig
>
> >  + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c: error: 
> > control reaches end of non-void function [-Werror=return-type]:  => 1560:1

I don't really see what's going on here:

#ifdef CONFIG_X86_64
return cpu_data(first_cpu_of_numa_node).apicid;
#else
return first_cpu_of_numa_node;
#endif

Alex

>
> um-x86_64/um-all{mod,yes}config
>
> >  + /kisskb/src/drivers/net/ethernet/freescale/fec_mpc52xx.c: error: passing 
> > argument 2 of 'mpc52xx_fec_set_paddr' discards 'const' qualifier from 
> > pointer target type [-Werror=discarded-qualifiers]:  => 659:29
>
> powerpc-gcc5/ppc32_allmodconfig
>
> >  + /kisskb/src/drivers/pinctrl/pinctrl-thunderbay.c: error: assignment 
> > discards 'const' qualifier from pointer target type 
> > [-Werror=discarded-qualifiers]:  => 815:8, 815:29
>
> arm64-gcc5.4/arm64-allmodconfig
> arm64-gcc8/arm64-allmodconfig
>
> >  + /kisskb/src/lib/test_printf.c: error: "PTR" redefined [-Werror]:  => 
> > 247:0, 247
> >  + /kisskb/src/sound/pci/ca0106/ca0106.h: error: "PTR" redefined [-Werror]: 
> >  => 62, 62:0
>
> mips-gcc8/mips-allmodconfig
> mipsel/mips-allmodconfig
>
> >  + error: arch/powerpc/kvm/book3s_64_entry.o: relocation truncated to fit: 
> > R_PPC64_REL14 (stub) against symbol `machine_check_common' defined in .text 
> > section in arch/powerpc/kernel/head_64.o:  => (.text+0x3e4)
>
> powerpc-gcc5/powerpc-allyesconfig
>
> Gr{oetje,eeting}s,
>
>

Re: Build regressions/improvements in v5.12-rc1

2021-03-02 Thread Alex Deucher 
On Mon, Mar 1, 2021 at 9:21 AM Geert Uytterhoeven  wrote:
>
> On Mon, 1 Mar 2021, Geert Uytterhoeven wrote:
> > Below is the list of build error/warning regressions/improvements in
> > v5.12-rc1[1] compared to v5.11[2].
> >
> > Summarized:
> >  - build errors: +2/-0
>
> > [1] 
> > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8/
> >  (all 192 configs)
> > [2] 
> > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f40ddce88593482919761f74910f42f4b84c004b/
> >  (all 192 configs)
> >
> >
> > *** ERRORS ***
> >
> > 2 error regressions:
> >  + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: 
> > error: implicit declaration of function 'disable_kernel_vsx' 
> > [-Werror=implicit-function-declaration]:  => 674:2
> >  + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: 
> > error: implicit declaration of function 'enable_kernel_vsx' 
> > [-Werror=implicit-function-declaration]:  => 638:2
>
> powerpc-gcc4.9/ppc64_book3e_allmodconfig
>
> This was fixed in v5.11-rc1, but reappeared in v5.12-rc1?

Do you know what fixed in for 5.11?  I guess for PPC64 we depend on CONFIG_VSX?

Alex

>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc

2020-04-09 Thread Alex Deucher 
On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter  wrote:
>
> On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
>  wrote:
> >
> > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > > If this code was broken for non-coherent caches a crude powerpc hack
> > > > isn't going to help anyone else.  Remove the hack as it is the last
> > > > user of __vmalloc passing a page protection flag other than PAGE_KERNEL.
> > >
> > > Well Ben added this to make stuff work on ppc, ofc the home grown dma
> > > layer in drm from back then isn't going to work in other places. I guess
> > > should have at least an ack from him, in case anyone still cares about
> > > this on ppc. Adding Ben to cc.
> >
> > This was due to some drivers (radeon ?) trying to use vmalloc pages for
> > coherent DMA, which means on those 4xx powerpc's need to be non-cached.
> >
> > There were machines using that (440 based iirc), though I honestly
> > can't tell if anybody still uses any of it.
>
> agp subsystem still seems to happily do that (vmalloc memory for
> device access), never having been ported to dma apis (or well
> converted to iommu drivers, which they kinda are really). So I think
> this all still works exactly as back then, even with the kms radeon
> drivers. Question really is whether we have users left, and I have no
> clue about that either.
>
> Now if these boxes didn't ever have agp then I think we can get away
> with deleting this, since we've already deleted the legacy radeon
> driver. And that one used vmalloc for everything. The new kms one does
> use the dma-api if the gpu isn't connected through agp.

All radeons have a built in remapping table to handle non-AGP systems.
On the earlier radeons it wasn't quite as performant as AGP, but it
was always more reliable because AGP is AGP.  Maybe it's time to let
AGP go?

Alex

> -Daniel
>
> > Cheers,
> > Ben.
> >
> > > -Daniel
> > >
> > > >
> > > > Signed-off-by: Christoph Hellwig 
> > > > ---
> > > >  drivers/gpu/drm/drm_scatter.c | 11 +--
> > > >  1 file changed, 1 insertion(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_scatter.c 
> > > > b/drivers/gpu/drm/drm_scatter.c
> > > > index ca520028b2cb..f4e6184d1877 100644
> > > > --- a/drivers/gpu/drm/drm_scatter.c
> > > > +++ b/drivers/gpu/drm/drm_scatter.c
> > > > @@ -43,15 +43,6 @@
> > > >
> > > >  #define DEBUG_SCATTER 0
> > > >
> > > > -static inline void *drm_vmalloc_dma(unsigned long size)
> > > > -{
> > > > -#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> > > > -   return __vmalloc(size, GFP_KERNEL, 
> > > > pgprot_noncached_wc(PAGE_KERNEL));
> > > > -#else
> > > > -   return vmalloc_32(size);
> > > > -#endif
> > > > -}
> > > > -
> > > >  static void drm_sg_cleanup(struct drm_sg_mem * entry)
> > > >  {
> > > > struct page *page;
> > > > @@ -126,7 +117,7 @@ int drm_legacy_sg_alloc(struct drm_device *dev, 
> > > > void *data,
> > > > return -ENOMEM;
> > > > }
> > > >
> > > > -   entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> > > > +   entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> > > > if (!entry->virtual) {
> > > > kfree(entry->busaddr);
> > > > kfree(entry->pagelist);
> > > > --
> > > > 2.25.1
> > > >
> > >
> > >
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/amdgpu: Remove superfluous void * cast in debugfs_create_file() call

2019-10-28 Thread Alex Deucher 
On Mon, Oct 21, 2019 at 6:23 PM Geert Uytterhoeven
 wrote:
>
> There is no need to cast a typed pointer to a void pointer when calling
> a function that accepts the latter.  Remove it, as the cast prevents
> further compiler checks.
>
> Signed-off-by: Geert Uytterhoeven 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index 5652cc72ed3a9b3a..b97a38b1e089b3d6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -1090,8 +1090,8 @@ int amdgpu_debugfs_init(struct amdgpu_device *adev)
>  {
> adev->debugfs_preempt =
> debugfs_create_file("amdgpu_preempt_ib", 0600,
> -   adev->ddev->primary->debugfs_root,
> -   (void *)adev, _ib_preempt);
> +   adev->ddev->primary->debugfs_root, adev,
> +   _ib_preempt);
> if (!(adev->debugfs_preempt)) {
> DRM_ERROR("unable to create amdgpu_preempt_ib debugsfs 
> file\n");
> return -EIO;
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fix double ;;s in code

2018-02-20 Thread Alex Deucher 
On Tue, Feb 20, 2018 at 3:03 AM, Jani Nikula
 wrote:
> On Mon, 19 Feb 2018, Pavel Machek  wrote:
>> On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
>>> Yeah, pls split this into one patch per area, with a suitable patch
>>> subject prefix. Look at git log of each file to get a feeling for what's
>>> the standard in each area.
>>
>> Yeah I can spend hour spliting it, and then people will ignore it
>> anyway.
>>
>> If you care about one of the files being modified, please fix the
>> bug, ";;" is a clear bug.
>>
>> If you don't care ... well I don't care either.
>
> Look, if this causes just one conflict down the line because it touches
> the kernel all over the place, then IMO it already wasn't worth
> it. Merge conflicts are inevitable, but there's no reason to make life
> harder just to cater for a cleanup patch. It's not that important.
>
> Had it been split up, the drm parts would've been merged already.

FWIW, the amdgpu and scheduler changes have already been fixed for -next.

Alex

>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [trivial PATCH] treewide: Align function definition open/close braces

2017-12-18 Thread Alex Deucher 
On Sun, Dec 17, 2017 at 7:28 PM, Joe Perches <j...@perches.com> wrote:
> Some functions definitions have either the initial open brace and/or
> the closing brace outside of column 1.
>
> Move those braces to column 1.
>
> This allows various function analyzers like gnu complexity to work
> properly for these modified functions.
>
> Miscellanea:
>
> o Remove extra trailing ; and blank line from xfs_agf_verify
>
> Signed-off-by: Joe Perches <j...@perches.com>
> ---
> git diff -w shows no difference other than the above 'Miscellanea'
>
> (this is against -next, but it applies against Linus' tree
>  with a couple offsets)
>
>  arch/x86/include/asm/atomic64_32.h   |  2 +-
>  drivers/acpi/custom_method.c |  2 +-
>  drivers/acpi/fan.c   |  2 +-
>  drivers/gpu/drm/amd/display/dc/core/dc.c |  2 +-

For amdgpu:
Acked-by: Alex Deucher <alexander.deuc...@amd.com>

>  drivers/media/i2c/msp3400-kthreads.c |  2 +-
>  drivers/message/fusion/mptsas.c  |  2 +-
>  drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c |  2 +-
>  drivers/net/wireless/ath/ath9k/xmit.c|  2 +-
>  drivers/platform/x86/eeepc-laptop.c  |  2 +-
>  drivers/rtc/rtc-ab-b5ze-s3.c |  2 +-
>  drivers/scsi/dpt_i2o.c   |  2 +-
>  drivers/scsi/sym53c8xx_2/sym_glue.c  |  2 +-
>  fs/locks.c   |  2 +-
>  fs/ocfs2/stack_user.c|  2 +-
>  fs/xfs/libxfs/xfs_alloc.c|  5 ++---
>  fs/xfs/xfs_export.c  |  2 +-
>  kernel/audit.c   |  6 +++---
>  kernel/trace/trace_printk.c  |  4 ++--
>  lib/raid6/sse2.c | 14 +++---
>  sound/soc/fsl/fsl_dma.c  |  2 +-
>  20 files changed, 30 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/include/asm/atomic64_32.h 
> b/arch/x86/include/asm/atomic64_32.h
> index 97c46b8169b7..d4d4883080fa 100644
> --- a/arch/x86/include/asm/atomic64_32.h
> +++ b/arch/x86/include/asm/atomic64_32.h
> @@ -122,7 +122,7 @@ static inline long long atomic64_read(const atomic64_t *v)
> long long r;
> alternative_atomic64(read, "=" (r), "c" (v) : "memory");
> return r;
> - }
> +}
>
>  /**
>   * atomic64_add_return - add and return
> diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
> index c68e72414a67..e967c1173ba3 100644
> --- a/drivers/acpi/custom_method.c
> +++ b/drivers/acpi/custom_method.c
> @@ -94,7 +94,7 @@ static void __exit acpi_custom_method_exit(void)
>  {
> if (cm_dentry)
> debugfs_remove(cm_dentry);
> - }
> +}
>
>  module_init(acpi_custom_method_init);
>  module_exit(acpi_custom_method_exit);
> diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
> index 6cf4988206f2..3563103590c6 100644
> --- a/drivers/acpi/fan.c
> +++ b/drivers/acpi/fan.c
> @@ -219,7 +219,7 @@ fan_set_cur_state(struct thermal_cooling_device *cdev, 
> unsigned long state)
> return fan_set_state_acpi4(device, state);
> else
> return fan_set_state(device, state);
> - }
> +}
>
>  static const struct thermal_cooling_device_ops fan_cooling_ops = {
> .get_max_state = fan_get_max_state,
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index d1488d5ee028..1e0d1e7c5324 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -461,7 +461,7 @@ static void disable_dangling_plane(struct dc *dc, struct 
> dc_state *context)
>   
> **/
>
>  struct dc *dc_create(const struct dc_init_data *init_params)
> - {
> +{
> struct dc *dc = kzalloc(sizeof(*dc), GFP_KERNEL);
> unsigned int full_pipe_count;
>
> diff --git a/drivers/media/i2c/msp3400-kthreads.c 
> b/drivers/media/i2c/msp3400-kthreads.c
> index 4dd01e9f553b..dc6cb8d475b3 100644
> --- a/drivers/media/i2c/msp3400-kthreads.c
> +++ b/drivers/media/i2c/msp3400-kthreads.c
> @@ -885,7 +885,7 @@ static int msp34xxg_modus(struct i2c_client *client)
>  }
>
>  static void msp34xxg_set_source(struct i2c_client *client, u16 reg, int in)
> - {
> +{
> struct msp_state *state = to_state(i2c_get_clientdata(client));
> int source, matrix;
>
> diff --git a/drivers

Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI

2014-10-13 Thread Alex Deucher 
On Mon, Oct 13, 2014 at 4:11 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 On Wed, 2014-10-08 at 16:28 +1100, Benjamin Herrenschmidt wrote:

  Further discussion with the hw teams have revealed that this is still
  an issue on newer asics so I think your original patch is correct
  after all.  Just disable 64 bit MSIs on all AMD audio PCI ids.

 Allright, I won't resend the whole series, I can just pickup my previous
 patch. Takashi, Bjorn, Dave, this series covers your 3 areas of
 maintainership, how do you want to proceed ? I'm happy to merge the
 whole lot via powerpc ASAP (since it's all CC'ed stable) if you guys
 send me the appropriate acks, otherwise, let me know.

 So I got an Ack from Takashi but so far silence from Bjorn and Dave :-)

 Ping ?

I'm fine with the radeon patches going through your tree rather than
through my tree.

Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI

2014-10-08 Thread Alex Deucher 
On Wed, Oct 8, 2014 at 1:28 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 On Tue, 2014-10-07 at 19:47 -0400, Alex Deucher wrote:
  This moves the setting of the quirk flag to the audio driver.
 
  While recent ASICs have that problem fixed, they don't seem to
  be listed in the PCI IDs of the current driver, so let's quirk all
  the ATI HDMI for now. The consequences are nil on x86 anyway.
 
  Signed-off-by: Alex Deucher alexdeuc...@gmail.com
  Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
  CC: sta...@vger.kernel.org

 Further discussion with the hw teams have revealed that this is still
 an issue on newer asics so I think your original patch is correct
 after all.  Just disable 64 bit MSIs on all AMD audio PCI ids.

 Allright, I won't resend the whole series, I can just pickup my previous
 patch. Takashi, Bjorn, Dave, this series covers your 3 areas of
 maintainership, how do you want to proceed ? I'm happy to merge the
 whole lot via powerpc ASAP (since it's all CC'ed stable) if you guys
 send me the appropriate acks, otherwise, let me know.


I don't remember if I gave my formal review of your original patch, so if not,
Reviewed-by: Alex Deucher alexander.deuc...@amd.com

Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI

2014-10-07 Thread Alex Deucher 
On Tue, Oct 7, 2014 at 12:38 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 From: Signed-off-by: Alex Deucher alexdeuc...@gmail.com

 A number of radeon cards have a HW limitation causing them to be
 unable to generate the full 64-bit of address bits for MSIs. This
 breaks MSIs on some platforms such as POWER machines.

 We used to have a powerpc specific quirk to address that on a
 single card, but this doesn't scale very well, this is better
 put under control of the drivers who know precisely what a given
 HW revision can do.

 This moves the setting of the quirk flag to the audio driver.

 While recent ASICs have that problem fixed, they don't seem to
 be listed in the PCI IDs of the current driver, so let's quirk all
 the ATI HDMI for now. The consequences are nil on x86 anyway.

 Signed-off-by: Alex Deucher alexdeuc...@gmail.com
 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
 CC: sta...@vger.kernel.org

Further discussion with the hw teams have revealed that this is still
an issue on newer asics so I think your original patch is correct
after all.  Just disable 64 bit MSIs on all AMD audio PCI ids.

Alex

 ---
  sound/pci/hda/hda_intel.c | 96 
 +--
  sound/pci/hda/hda_priv.h  |  1 +
  2 files changed, 69 insertions(+), 28 deletions(-)

 diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
 index 99b367b..af38ed9 100644
 --- a/sound/pci/hda/hda_intel.c
 +++ b/sound/pci/hda/hda_intel.c
 @@ -1506,9 +1506,14 @@ static int azx_first_init(struct azx *chip)
 return -ENXIO;
 }

 -   if (chip-msi)
 +   if (chip-msi) {
 +   if (chip-driver_caps  AZX_DCAPS_NO_MSI64) {
 +   dev_dbg(card-dev, Disabling 64bit MSI\n);
 +   pci-no_64bit_msi = true;
 +   }
 if (pci_enable_msi(pci)  0)
 chip-msi = 0;
 +   }

 if (azx_acquire_irq(chip, 0)  0)
 return -EBUSY;
 @@ -2070,58 +2075,93 @@ static const struct pci_device_id azx_ids[] = {
 { PCI_DEVICE(0x1022, 0x780d),
   .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB },
 /* ATI HDMI */
 -   { PCI_DEVICE(0x1002, 0x793b),
 - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
 +   { PCI_DEVICE(0x1002, 0x1314),
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 { PCI_DEVICE(0x1002, 0x7919),
 - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 +   { PCI_DEVICE(0x1002, 0x7969),
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 +   { PCI_DEVICE(0x1002, 0x793b),
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 { PCI_DEVICE(0x1002, 0x960f),
 - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 +   { PCI_DEVICE(0x1002, 0x9646),
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 { PCI_DEVICE(0x1002, 0x970f),
 - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 { PCI_DEVICE(0x1002, 0xaa00),
 - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 { PCI_DEVICE(0x1002, 0xaa08),
 - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 { PCI_DEVICE(0x1002, 0xaa10),
 - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 { PCI_DEVICE(0x1002, 0xaa18),
 - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 { PCI_DEVICE(0x1002, 0xaa20),
 - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 { PCI_DEVICE(0x1002, 0xaa28),
 - .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI },
 + .driver_data = AZX_DRIVER_ATIHDMI | AZX_DCAPS_PRESET_ATI_HDMI |
 + AZX_DCAPS_NO_MSI64 },
 { PCI_DEVICE(0x1002, 0xaa30

Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI

2014-10-07 Thread Alex Deucher 
On Tue, Oct 7, 2014 at 7:49 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 On Tue, 2014-10-07 at 19:47 -0400, Alex Deucher wrote:
  While recent ASICs have that problem fixed, they don't seem to
  be listed in the PCI IDs of the current driver, so let's quirk all
  the ATI HDMI for now. The consequences are nil on x86 anyway.
 
  Signed-off-by: Alex Deucher alexdeuc...@gmail.com
  Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
  CC: sta...@vger.kernel.org

 Further discussion with the hw teams have revealed that this is still
 an issue on newer asics so I think your original patch is correct
 after all.  Just disable 64 bit MSIs on all AMD audio PCI ids.

 Ok. You confirm that this is however good on newer video side right ?


Yes, this was definitely fixed on the GPU side.

 Also, is there a known issue that if MSI were once enabled, the chip
 still shoots them even if we disable them in config space ?

 When testing my new patch set, I was trying to test the error path
 when the arch does *not* honor the limitation. The error went back
 up to the driver as far as I can tell (ie, pci_enable_msi() failed),
 but the system still got into error state as if the card had tried
 to shoot an MSI to the wrong address.

 (I suspect the graphics side)

I'm not aware of any such issue, but I can ask the hw guys if there is
anything special required to disable MSIs beyond the pci config space
settings.

Alex


 Cheers,
 Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 3/4] sound/radeon: Move 64-bit MSI quirk from arch to driver

2014-10-03 Thread Alex Deucher 
On Fri, Oct 3, 2014 at 1:23 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 On Wed, 2014-10-01 at 22:13 -0400, Alex Deucher wrote:

 The attached updated patch only flags the affected asics.

 I need formal (email :-) permission to add your s-o-b (and From: while
 at it since you wrote most of it) for this patch. I'll then include
 it in my new series.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/4] sounds/hda/radeon: Disable 64-bit DMA on radeon

2014-10-01 Thread Alex Deucher 
On Wed, Oct 1, 2014 at 4:30 AM, Takashi Iwai ti...@suse.de wrote:
 At Wed, 01 Oct 2014 10:09:28 +0200,
 Takashi Iwai wrote:

 At Wed, 01 Oct 2014 17:41:29 +1000,
 Benjamin Herrenschmidt wrote:
 
  On Wed, 2014-10-01 at 09:38 +0200, Takashi Iwai wrote:
 
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 3e6d22d..2b679d5 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -297,7 +297,7 @@ enum {
 /* quirks for ATI/AMD HDMI */
 #define AZX_DCAPS_PRESET_ATI_HDMI \
(AZX_DCAPS_NO_TCSEL | AZX_DCAPS_SYNC_WRITE | 
AZX_DCAPS_POSFIX_LPIB|\
-AZX_DCAPS_NO_MSI64)
+AZX_DCAPS_NO_MSI64 | AZX_DCAPS_NO_64BIT)
  
   The only concern is that this will disable 64bit DMA also on x86 where
   it has been working fine.  Can we add an ifdef CONFIG_PPC for this?
 
  I don't like that approach because technically the chip doesn't do
  64-bit DMA ... it does something like 40 or 48 (might actually depend on
  the chip version) and for all I know it will break on future x86 with
  more memory or other platforms with similar address encodings as
  powerpc...
 
  The right thing might be to get the exact number of bits and do the
  appropriate dma_set_mask() like the graphics driver does, but that's a
  bit tricky unless we add a DMA mask field in that big array of chips in
  there...

 I think setting the dma mask explicitly would be a better approach
 although it results in a bit bigger change.  At least, it would impact
 less than forcing 32bit DMA, as most desktop machines have less than
 40bit address.  How about a patch like below?

Patch looks good.  Audio DMAs are limited to 40 bits, same as the GPU
side.  I'm still waiting to hear back on the MSIs for audio, but they
probably follow the GPU side, so I expect they should be fixed on Sea
Islands as well.

Alex



 Oops, it obviously doesn't work with AMD ID...  Fixed in below.


 Takashi

 -- 8 --
 From: Takashi Iwai ti...@suse.de
 Subject: [PATCH v2] ALSA: hda - Limit 40bit DMA for AMD HDMI controllers

 AMD/ATI HDMI controller chip models, we already have a filter to lower
 to 32bit DMA, but the rest are supposed to be working with 64bit
 although the hardware doesn't really work with 63bit but only with 40
 or 48bit DMA.  In this patch, we take 40bit DMA for safety for the
 AMD/ATI controllers as the graphics drivers does.

 Signed-off-by: Takashi Iwai ti...@suse.de
 ---
  sound/pci/hda/hda_intel.c | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

 diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
 index aa302fb03fc5..99b367bd9b1b 100644
 --- a/sound/pci/hda/hda_intel.c
 +++ b/sound/pci/hda/hda_intel.c
 @@ -1482,6 +1482,7 @@ static int azx_first_init(struct azx *chip)
 struct snd_card *card = chip-card;
 int err;
 unsigned short gcap;
 +   unsigned int dma_bits = 64;

  #if BITS_PER_LONG != 64
 /* Fix up base address on ULI M5461 */
 @@ -1518,9 +1519,14 @@ static int azx_first_init(struct azx *chip)
 gcap = azx_readw(chip, GCAP);
 dev_dbg(card-dev, chipset global capabilities = 0x%x\n, gcap);

 +   /* AMD devices support 40 or 48bit DMA, take the safe one */
 +   if (chip-pci-vendor == PCI_VENDOR_ID_AMD)
 +   dma_bits = 40;
 +
 /* disable SB600 64bit support for safety */
 if (chip-pci-vendor == PCI_VENDOR_ID_ATI) {
 struct pci_dev *p_smbus;
 +   dma_bits = 40;
 p_smbus = pci_get_device(PCI_VENDOR_ID_ATI,
  PCI_DEVICE_ID_ATI_SBX00_SMBUS,
  NULL);
 @@ -1550,9 +1556,11 @@ static int azx_first_init(struct azx *chip)
 }

 /* allow 64bit DMA address if supported by H/W */
 -   if ((gcap  AZX_GCAP_64OK)  !pci_set_dma_mask(pci, 
 DMA_BIT_MASK(64)))
 -   pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64));
 -   else {
 +   if (!(gcap  AZX_GCAP_64OK))
 +   dma_bits = 32;
 +   if (!pci_set_dma_mask(pci, DMA_BIT_MASK(dma_bits))) {
 +   pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(dma_bits));
 +   } else {
 pci_set_dma_mask(pci, DMA_BIT_MASK(32));
 pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32));
 }
 --
 2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/4] sound/hda/radeon: Generalize 64-bit MSI quirks

2014-10-01 Thread Alex Deucher 
On Tue, Sep 30, 2014 at 10:09 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 A number of radeon cards have a HW limitation causing them to be
 unable to generate the full 64-bit of address bits for MSIs. This
 breaks MSIs on some platforms such as POWER machines.

 We used to have a powerpc specific quirk to address that on a
 single card, but this doesn't scale very well, this is better
 put under control of the drivers who know precisely what a given
 HW revision can do.

 This moves the setting of the quirk flag to the HDA driver when
 detecting the radeon audio interface.

 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
 CC: sta...@vger.kernel.org

This only applies to pre Sea-Islands asics, same as the GPU side.

Alex

 ---
  arch/powerpc/kernel/pci_64.c |  6 --
  sound/pci/hda/hda_intel.c| 10 --
  sound/pci/hda/hda_priv.h |  1 +
  3 files changed, 9 insertions(+), 8 deletions(-)

 diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
 index 66e1cd0..b15194e 100644
 --- a/arch/powerpc/kernel/pci_64.c
 +++ b/arch/powerpc/kernel/pci_64.c
 @@ -266,9 +266,3 @@ int pcibus_to_node(struct pci_bus *bus)
  }
  EXPORT_SYMBOL(pcibus_to_node);
  #endif
 -
 -static void quirk_radeon_32bit_msi(struct pci_dev *dev)
 -{
 -   dev-force_32bit_msi = true;
 -}
 -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0xaa68, quirk_radeon_32bit_msi);
 diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
 index aa302fb..3e6d22d 100644
 --- a/sound/pci/hda/hda_intel.c
 +++ b/sound/pci/hda/hda_intel.c
 @@ -296,7 +296,8 @@ enum {

  /* quirks for ATI/AMD HDMI */
  #define AZX_DCAPS_PRESET_ATI_HDMI \
 -   (AZX_DCAPS_NO_TCSEL | AZX_DCAPS_SYNC_WRITE | AZX_DCAPS_POSFIX_LPIB)
 +   (AZX_DCAPS_NO_TCSEL | AZX_DCAPS_SYNC_WRITE | AZX_DCAPS_POSFIX_LPIB|\
 +AZX_DCAPS_NO_MSI64)

  /* quirks for Nvidia */
  #define AZX_DCAPS_PRESET_NVIDIA \
 @@ -1505,9 +1506,14 @@ static int azx_first_init(struct azx *chip)
 return -ENXIO;
 }

 -   if (chip-msi)
 +   if (chip-msi) {
 +   if (chip-driver_caps  AZX_DCAPS_NO_MSI64) {
 +   dev_dbg(card-dev, Disabling 64bit MSI\n);
 +   pci-force_32bit_msi = true;
 +   }
 if (pci_enable_msi(pci)  0)
 chip-msi = 0;
 +   }

 if (azx_acquire_irq(chip, 0)  0)
 return -EBUSY;
 diff --git a/sound/pci/hda/hda_priv.h b/sound/pci/hda/hda_priv.h
 index 949cd43..5016014 100644
 --- a/sound/pci/hda/hda_priv.h
 +++ b/sound/pci/hda/hda_priv.h
 @@ -171,6 +171,7 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO1, SDO2, SDO3 };
  #define AZX_DCAPS_PM_RUNTIME   (1  26)   /* runtime PM support */
  #define AZX_DCAPS_I915_POWERWELL (1  27) /* HSW i915 powerwell support 
 */
  #define AZX_DCAPS_CORBRP_SELF_CLEAR (1  28)  /* CORBRP clears itself after 
 reset */
 +#define AZX_DCAPS_NO_MSI64  (1  29)  /* Stick to 32-bit MSIs */

  /* HD Audio class code */
  #define PCI_CLASS_MULTIMEDIA_HD_AUDIO  0x0403



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/4] sounds/hda/radeon: Disable 64-bit DMA on radeon

2014-10-01 Thread Alex Deucher 
On Wed, Oct 1, 2014 at 6:08 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 On Wed, 2014-10-01 at 13:58 -0400, Alex Deucher wrote:
 Patch looks good.  Audio DMAs are limited to 40 bits, same as the GPU
 side.  I'm still waiting to hear back on the MSIs for audio, but they
 probably follow the GPU side, so I expect they should be fixed on Sea
 Islands as well.

 In the audio driver we don't have the family names, just a list of
 PCI IDs, do you happen to know which ones are unaffected ?

The list of unaffected ones are:
0x1308 //kaveri
0x9840 //Kabini
0xaac0 //bonaire
0xaac8 //hawaii
0xaad8 //tonga
Pus all newer asics.

Alternatively, the list of older asics that are affected (some of
these may not even support MSI64 in the first place):
0x1314 //palm
0x7919 //RS690
0x793b //RS600
0x7969 //RS740
0x960f //RS780
0x9646 //sumo
0x970f //RS880
0x9902 //trinity
0xaa00 //R600
0xaa08 //RV630
0xaa10 //RV610
0xaa18 //RV670
0xaa20 //RV635
0xaa28 //RV620
0xaa30 //RV770
0xaa38 //RV730
0xaa40 //RV710
0xaa48 //RV740
0xaa50 //cypress
0xaa58 //juniper
0xaa60 //redwood
0xaa68 //cedar
0xaa80 //cayman
0xaa88 //barts
0xaa90 //turks
0xaa98 //caicos
0xaaa0 //tahiti
0xaab0 //verde, pitcairn, oland

It might be better to only set the msi32 flag on the above affected
asics so we don't have to worry about new ones.

Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 3/4] sound/radeon: Move 64-bit MSI quirk from arch to driver

2014-10-01 Thread Alex Deucher 
On Wed, Oct 1, 2014 at 8:34 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:

 A number of radeon cards have a HW limitation causing them to be
 unable to generate the full 64-bit of address bits for MSIs. This
 breaks MSIs on some platforms such as POWER machines.

 We used to have a powerpc specific quirk to address that on a
 single card, but this doesn't scale very well, this is better
 put under control of the drivers who know precisely what a given
 HW revision can do.

 This moves the setting of the quirk flag to the audio driver.

 While recent ASICs have that problem fixed, they don't seem to
 be listed in the PCI IDs of the current driver, so let's quirk all
 the ATI HDMI for now. The consequences are nil on x86 anyway.

 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
 CC: sta...@vger.kernel.org

The attached updated patch only flags the affected asics.

Alex

 ---
  arch/powerpc/kernel/pci_64.c |  6 --
  sound/pci/hda/hda_intel.c| 10 --
  sound/pci/hda/hda_priv.h |  1 +
  3 files changed, 9 insertions(+), 8 deletions(-)

 diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
 index 5330f6d..b15194e 100644
 --- a/arch/powerpc/kernel/pci_64.c
 +++ b/arch/powerpc/kernel/pci_64.c
 @@ -266,9 +266,3 @@ int pcibus_to_node(struct pci_bus *bus)
  }
  EXPORT_SYMBOL(pcibus_to_node);
  #endif
 -
 -static void quirk_radeon_32bit_msi(struct pci_dev *dev)
 -{
 -   dev-no_64bit_msi = true;
 -}
 -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0xaa68, quirk_radeon_32bit_msi);
 diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
 index aa302fb..f91ba7f 100644
 --- a/sound/pci/hda/hda_intel.c
 +++ b/sound/pci/hda/hda_intel.c
 @@ -296,7 +296,8 @@ enum {

  /* quirks for ATI/AMD HDMI */
  #define AZX_DCAPS_PRESET_ATI_HDMI \
 -   (AZX_DCAPS_NO_TCSEL | AZX_DCAPS_SYNC_WRITE | AZX_DCAPS_POSFIX_LPIB)
 +   (AZX_DCAPS_NO_TCSEL | AZX_DCAPS_SYNC_WRITE | AZX_DCAPS_POSFIX_LPIB|\
 +AZX_DCAPS_NO_MSI64)

  /* quirks for Nvidia */
  #define AZX_DCAPS_PRESET_NVIDIA \
 @@ -1505,9 +1506,14 @@ static int azx_first_init(struct azx *chip)
 return -ENXIO;
 }

 -   if (chip-msi)
 +   if (chip-msi) {
 +   if (chip-driver_caps  AZX_DCAPS_NO_MSI64) {
 +   dev_dbg(card-dev, Disabling 64bit MSI\n);
 +   pci-no_64bit_msi = true;
 +   }
 if (pci_enable_msi(pci)  0)
 chip-msi = 0;
 +   }

 if (azx_acquire_irq(chip, 0)  0)
 return -EBUSY;
 diff --git a/sound/pci/hda/hda_priv.h b/sound/pci/hda/hda_priv.h
 index 949cd43..5016014 100644
 --- a/sound/pci/hda/hda_priv.h
 +++ b/sound/pci/hda/hda_priv.h
 @@ -171,6 +171,7 @@ enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO1, SDO2, SDO3 };
  #define AZX_DCAPS_PM_RUNTIME   (1  26)   /* runtime PM support */
  #define AZX_DCAPS_I915_POWERWELL (1  27) /* HSW i915 powerwell support 
 */
  #define AZX_DCAPS_CORBRP_SELF_CLEAR (1  28)  /* CORBRP clears itself after 
 reset */
 +#define AZX_DCAPS_NO_MSI64  (1  29)  /* Stick to 32-bit MSIs */

  /* HD Audio class code */
  #define PCI_CLASS_MULTIMEDIA_HD_AUDIO  0x0403




From 412fce0929558602a43a41feab051c4cf73c7142 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Thu, 2 Oct 2014 10:34:42 +1000
Subject: [PATCH] sound/radeon: Move 64-bit MSI quirk from arch to driver (v2)

A number of radeon cards have a HW limitation causing them to be
unable to generate the full 64-bit of address bits for MSIs. This
breaks MSIs on some platforms such as POWER machines.

We used to have a powerpc specific quirk to address that on a
single card, but this doesn't scale very well, this is better
put under control of the drivers who know precisely what a given
HW revision can do.

This moves the setting of the quirk flag to the audio driver.

While recent ASICs have that problem fixed, they don't seem to
be listed in the PCI IDs of the current driver, so let's quirk all
the ATI HDMI for now. The consequences are nil on x86 anyway.

v2: Alex Deucher: only quirk the affected asics

Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: sta...@vger.kernel.org
---
 arch/powerpc/kernel/pci_64.c |  6 ---
 sound/pci/hda/hda_intel.c| 96 +++-
 sound/pci/hda/hda_priv.h |  1 +
 3 files changed, 69 insertions(+), 34 deletions(-)

diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 5330f6d..b15194e 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -266,9 +266,3 @@ int pcibus_to_node(struct pci_bus *bus)
 }
 EXPORT_SYMBOL(pcibus_to_node);
 #endif
-
-static void quirk_radeon_32bit_msi(struct pci_dev *dev)
-{
-	dev-no_64bit_msi = true;
-}
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0xaa68, quirk_radeon_32bit_msi);
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index

Re: [PATCH 4/4] ALSA: hda - Limit 40bit DMA for AMD HDMI controllers

2014-10-01 Thread Alex Deucher 
On Wed, Oct 1, 2014 at 8:34 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:

 AMD/ATI HDMI controller chip models, we already have a filter to lower
 to 32bit DMA, but the rest are supposed to be working with 64bit
 although the hardware doesn't really work with 63bit but only with 40
 or 48bit DMA.  In this patch, we take 40bit DMA for safety for the
 AMD/ATI controllers as the graphics drivers does.

 Signed-off-by: Takashi Iwai ti...@suse.de
 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
 CC: sta...@vger.kernel.org

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---

 Tested, works fine. This patch is actually independent of the rest
 of the series

  sound/pci/hda/hda_intel.c | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

 diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
 index f91ba7f..48d0f30 100644
 --- a/sound/pci/hda/hda_intel.c
 +++ b/sound/pci/hda/hda_intel.c
 @@ -1483,6 +1483,7 @@ static int azx_first_init(struct azx *chip)
 struct snd_card *card = chip-card;
 int err;
 unsigned short gcap;
 +   unsigned int dma_bits = 64;

  #if BITS_PER_LONG != 64
 /* Fix up base address on ULI M5461 */
 @@ -1524,9 +1525,14 @@ static int azx_first_init(struct azx *chip)
 gcap = azx_readw(chip, GCAP);
 dev_dbg(card-dev, chipset global capabilities = 0x%x\n, gcap);

 +   /* AMD devices support 40 or 48bit DMA, take the safe one */
 +   if (chip-pci-vendor == PCI_VENDOR_ID_AMD)
 +   dma_bits = 40;
 +
 /* disable SB600 64bit support for safety */
 if (chip-pci-vendor == PCI_VENDOR_ID_ATI) {
 struct pci_dev *p_smbus;
 +   dma_bits = 40;
 p_smbus = pci_get_device(PCI_VENDOR_ID_ATI,
  PCI_DEVICE_ID_ATI_SBX00_SMBUS,
  NULL);
 @@ -1556,9 +1562,11 @@ static int azx_first_init(struct azx *chip)
 }

 /* allow 64bit DMA address if supported by H/W */
 -   if ((gcap  AZX_GCAP_64OK)  !pci_set_dma_mask(pci, 
 DMA_BIT_MASK(64)))
 -   pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64));
 -   else {
 +   if (!(gcap  AZX_GCAP_64OK))
 +   dma_bits = 32;
 +   if (!pci_set_dma_mask(pci, DMA_BIT_MASK(dma_bits))) {
 +   pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(dma_bits));
 +   } else {
 pci_set_dma_mask(pci, DMA_BIT_MASK(32));
 pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(32));
 }




___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 2/4] gpu/radeon: Move 64-bit MSI quirk from arch to driver

2014-10-01 Thread Alex Deucher 
On Wed, Oct 1, 2014 at 8:33 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 A number of radeon cards have a HW limitation causing them to be
 unable to generate the full 64-bit of address bits for MSIs. This
 breaks MSIs on some platforms such as POWER machines.

 We used to have a powerpc specific quirk to address that on a
 single card, but this doesn't scale very well, this is better
 put under control of the drivers who know precisely what a given
 HW revision can do.

 This moves the setting of the quirk flag to the radeon driver

 Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
 CC: sta...@vger.kernel.org

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---

 v2: This is just adjusted to the new flag name

  arch/powerpc/kernel/pci_64.c|  1 -
  drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 ++
  2 files changed, 10 insertions(+), 1 deletion(-)

 diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
 index d41a831..5330f6d 100644
 --- a/arch/powerpc/kernel/pci_64.c
 +++ b/arch/powerpc/kernel/pci_64.c
 @@ -271,5 +271,4 @@ static void quirk_radeon_32bit_msi(struct pci_dev *dev)
  {
 dev-no_64bit_msi = true;
  }
 -DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x68f2, quirk_radeon_32bit_msi);
  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0xaa68, quirk_radeon_32bit_msi);
 diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
 b/drivers/gpu/drm/radeon/radeon_irq_kms.c
 index 16807af..e760671 100644
 --- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
 +++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
 @@ -202,6 +202,16 @@ static bool radeon_msi_ok(struct radeon_device *rdev)
 if (rdev-flags  RADEON_IS_AGP)
 return false;

 +   /*
 +* Older chips have a HW limitation, they can only generate 40 bits
 +* of address for 64-bit MSIs which breaks on some platforms, 
 notably
 +* IBM POWER servers, so we limit them
 +*/
 +   if (rdev-family  CHIP_BONAIRE) {
 +   dev_info(rdev-dev, radeon: MSI limited to 32-bit\n);
 +   rdev-pdev-no_64bit_msi = true;
 +   }
 +
 /* force MSI on */
 if (radeon_msi == 1)
 return true;


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: 3.11-rc3+git: __divdi3 undefined on powerpc (from radeon)

2013-08-03 Thread Alex Deucher 
On Sat, Aug 3, 2013 at 8:44 AM, Meelis Roos mr...@linux.ee wrote:
 While trying to compile v3.11-rc3-288-gabe0308 on powerpc 32-bit,
 it failed with the following linking error:

 ERROR: __divdi3 [drivers/gpu/drm/radeon/radeon.ko] undefined!

 Some new 64-bit division in radeon that is not implemented on 32-bit
 powerpc?

 This is new - 3.11-rc3 worked fine.

Fix is already queued:
http://lists.freedesktop.org/archives/dri-devel/2013-August/042668.html

Alex


 --
 Meelis Roos (mr...@linux.ee)
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv5 0/2] Speed Cap fixes for ppc64

2013-05-15 Thread Alex Deucher 
On Wed, May 15, 2013 at 8:35 AM, Kleber Sacilotto de Souza
kleb...@linux.vnet.ibm.com wrote:
 On 05/06/2013 11:32 AM, Alex Deucher wrote:

 On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt
 b...@kernel.crashing.org wrote:

 On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote:

 This patch series does:
1. max_bus_speed is used to set the device to gen2 speeds
2. on power there's no longer a conflict between the pseries call and
 other
 architectures, because the overwrite is done via a ppc_md hook
3. radeon is using bus-max_bus_speed instead of
 drm_pcie_get_speed_cap_mask
 for gen2 capability detection

 The first patch consists of some architecture changes, such as adding a
 hook on
 powerpc for pci_root_bridge_prepare, so that pseries will initialize it
 to a
 function, while all other architectures get a NULL pointer. So that
 whenever
 pci_create_root_bus is called, we'll get max_bus_speed properly setup
 from
 OpenFirmware.

 The second patch consists of simple radeon changes not to call
 drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines,
 the max_bus_speed property will be properly set already.


 So I'm ok with the approach now and I might even put the powerpc patch
 in for 3.10 since arguably we are fixing a nasty bug (uninitialized
 max_bus_speed).

 David, what's your feeling about the radeon change ? It would be nice if
 that could go in soon for various distro targets :-) On the other hand
 I'm not going to be pushy if you are not comfortable with it.


 FWIW, the radeon change looks fine to me.

 Alex


 Hi David,

 Are you planning to accept the radeon patch? If yes, can we still expect it
 to make it for 3.10?

 As Ben mentioned, we have some distro targets to make and it would be nice
 to have an outlook of the upstream acceptance to start the conversations
 with those distros.

Is the rest of this series already upstream?  I don't see a problem
pulling it in if the rest of the patches are in Dave's tree.  Dave, do
you want to grab this, or do you wan me to pull it in through my tree?

Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv5 0/2] Speed Cap fixes for ppc64

2013-05-06 Thread Alex Deucher 
On Fri, May 3, 2013 at 7:01 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote:

 This patch series does:
   1. max_bus_speed is used to set the device to gen2 speeds
   2. on power there's no longer a conflict between the pseries call and other
 architectures, because the overwrite is done via a ppc_md hook
   3. radeon is using bus-max_bus_speed instead of 
 drm_pcie_get_speed_cap_mask
 for gen2 capability detection

 The first patch consists of some architecture changes, such as adding a hook 
 on
 powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a
 function, while all other architectures get a NULL pointer. So that whenever
 pci_create_root_bus is called, we'll get max_bus_speed properly setup from
 OpenFirmware.

 The second patch consists of simple radeon changes not to call
 drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines,
 the max_bus_speed property will be properly set already.

 So I'm ok with the approach now and I might even put the powerpc patch
 in for 3.10 since arguably we are fixing a nasty bug (uninitialized
 max_bus_speed).

 David, what's your feeling about the radeon change ? It would be nice if
 that could go in soon for various distro targets :-) On the other hand
 I'm not going to be pushy if you are not comfortable with it.

FWIW, the radeon change looks fine to me.

Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

2013-04-17 Thread Alex Deucher 
On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
luca...@linux.vnet.ibm.com wrote:
 On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:

 On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
 luca...@linux.vnet.ibm.com  wrote:

 radeon currently uses a drm function to get the speed capabilities for
 the bus. However, this is a non-standard method of performing this
 detection and this patch changes it to use the max_bus_speed attribute.
 ---
   drivers/gpu/drm/radeon/evergreen.c |9 ++---
   drivers/gpu/drm/radeon/r600.c  |8 +---
   drivers/gpu/drm/radeon/rv770.c |8 +---
   3 files changed, 4 insertions(+), 21 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen.c
 b/drivers/gpu/drm/radeon/evergreen.c
 index 305a657..3291f62 100644
 --- a/drivers/gpu/drm/radeon/evergreen.c
 +++ b/drivers/gpu/drm/radeon/evergreen.c
 @@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)

   void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
   {
 -   u32 link_width_cntl, speed_cntl, mask;
 -   int ret;
 +   u32 link_width_cntl, speed_cntl;

  if (radeon_pcie_gen2 == 0)
  return;
 @@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct
 radeon_device *rdev)
  if (ASIC_IS_X2(rdev))
  return;

 -   ret = drm_pcie_get_speed_cap_mask(rdev-ddev,mask);
 -   if (ret != 0)
 -   return;
 -
 -   if (!(mask  DRM_PCIE_SPEED_50))

 +   if (rdev-pdev-bus-max_bus_speed  PCIE_SPEED_5_0GT)


 For devices on a root bus, we previously dereferenced a NULL pointer
 in drm_pcie_get_speed_cap_mask() because pdev-bus-self is NULL on a
 root bus.  (I think this is the original problem you tripped over,
 Lucas.)

 These patches fix that problem.  On pseries, where the device *is* on
 a root bus, your patches set max_bus_speed so this will work as
 expected.  On most other systems, max_bus_speed for root buses will be
 PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
 most arches don't have code like the pseries code you're adding).

 PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
 the root bus, we'll attempt to enable Gen2 on the device even though
 we have no idea what the bus will support.

 That's why I originally suggested skipping the Gen2 stuff if
 max_bus_speed == PCI_SPEED_UNKNOWN.  I was just being conservative,
 thinking that it's better to have a functional but slow GPU rather
 than the unknown (to me) effects of enabling Gen2 on a link that might
 not support it.  But I'm fine with this being either way.


 You're right here, of course. I'll test for it being different from 5_0GT
 and 8_0GT instead. Though at some point I suppose someone will want to
 tackle Gen3 speeds.

drm_pcie_get_speed_cap_mask() actually checked the pci bridge to see
what speeds it supported.  If the new code doesn't actually check the
bridge caps then the new code does not seem like a valid replacement
unless I'm missing something.

Alex




 It would be nice if we could get rid of drm_pcie_get_speed_cap_mask()
 altogether.  It is exported, but I have no idea of anybody else uses
 it.  Maybe it could at least be marked __deprecated now?


 I'll mark it.

 I don't know who should take these patches.  They don't touch
 drivers/pci, but I'd be happy to push them, given the appropriate ACKs
 from DRM and powerpc folks.

 Bjorn

  return;

  speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
 diff --git a/drivers/gpu/drm/radeon/r600.c
 b/drivers/gpu/drm/radeon/r600.c
 index 0740db3..64b90c0 100644
 --- a/drivers/gpu/drm/radeon/r600.c
 +++ b/drivers/gpu/drm/radeon/r600.c
 @@ -4351,8 +4351,6 @@ static void r600_pcie_gen2_enable(struct
 radeon_device *rdev)
   {
  u32 link_width_cntl, lanes, speed_cntl, training_cntl, tmp;
  u16 link_cntl2;
 -   u32 mask;
 -   int ret;

  if (radeon_pcie_gen2 == 0)
  return;
 @@ -4371,11 +4369,7 @@ static void r600_pcie_gen2_enable(struct
 radeon_device *rdev)
  if (rdev-family= CHIP_R600)
  return;

 -   ret = drm_pcie_get_speed_cap_mask(rdev-ddev,mask);
 -   if (ret != 0)
 -   return;
 -
 -   if (!(mask  DRM_PCIE_SPEED_50))

 +   if (rdev-pdev-bus-max_bus_speed  PCIE_SPEED_5_0GT)
  return;

  speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
 diff --git a/drivers/gpu/drm/radeon/rv770.c
 b/drivers/gpu/drm/radeon/rv770.c
 index d63fe1d..c683c36 100644
 --- a/drivers/gpu/drm/radeon/rv770.c
 +++ b/drivers/gpu/drm/radeon/rv770.c
 @@ -1238,8 +1238,6 @@ static void rv770_pcie_gen2_enable(struct
 radeon_device *rdev)
   {
  u32 link_width_cntl, lanes, speed_cntl, tmp;
  u16 link_cntl2;
 -   u32 mask;
 -   int ret;

  if (radeon_pcie_gen2 == 0)
  return;
 @@ -1254,11 +1252,7 @@ static void rv770_pcie_gen2_enable(struct
 radeon_device *rdev)
  if

Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

2013-04-17 Thread Alex Deucher 
On Wed, Apr 17, 2013 at 4:11 PM, Bjorn Helgaas bhelg...@google.com wrote:
 On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
 luca...@linux.vnet.ibm.com wrote:
 On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:

 On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
 luca...@linux.vnet.ibm.com  wrote:

 radeon currently uses a drm function to get the speed capabilities for
 the bus. However, this is a non-standard method of performing this
 detection and this patch changes it to use the max_bus_speed attribute.
 ---
   drivers/gpu/drm/radeon/evergreen.c |9 ++---
   drivers/gpu/drm/radeon/r600.c  |8 +---
   drivers/gpu/drm/radeon/rv770.c |8 +---
   3 files changed, 4 insertions(+), 21 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen.c
 b/drivers/gpu/drm/radeon/evergreen.c
 index 305a657..3291f62 100644
 --- a/drivers/gpu/drm/radeon/evergreen.c
 +++ b/drivers/gpu/drm/radeon/evergreen.c
 @@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)

   void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
   {
 -   u32 link_width_cntl, speed_cntl, mask;
 -   int ret;
 +   u32 link_width_cntl, speed_cntl;

  if (radeon_pcie_gen2 == 0)
  return;
 @@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct
 radeon_device *rdev)
  if (ASIC_IS_X2(rdev))
  return;

 -   ret = drm_pcie_get_speed_cap_mask(rdev-ddev,mask);
 -   if (ret != 0)
 -   return;
 -
 -   if (!(mask  DRM_PCIE_SPEED_50))

 +   if (rdev-pdev-bus-max_bus_speed  PCIE_SPEED_5_0GT)


 For devices on a root bus, we previously dereferenced a NULL pointer
 in drm_pcie_get_speed_cap_mask() because pdev-bus-self is NULL on a
 root bus.  (I think this is the original problem you tripped over,
 Lucas.)

 These patches fix that problem.  On pseries, where the device *is* on
 a root bus, your patches set max_bus_speed so this will work as
 expected.  On most other systems, max_bus_speed for root buses will be
 PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
 most arches don't have code like the pseries code you're adding).

 PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
 the root bus, we'll attempt to enable Gen2 on the device even though
 we have no idea what the bus will support.

 That's why I originally suggested skipping the Gen2 stuff if
 max_bus_speed == PCI_SPEED_UNKNOWN.  I was just being conservative,
 thinking that it's better to have a functional but slow GPU rather
 than the unknown (to me) effects of enabling Gen2 on a link that might
 not support it.  But I'm fine with this being either way.


 You're right here, of course. I'll test for it being different from 5_0GT
 and 8_0GT instead. Though at some point I suppose someone will want to
 tackle Gen3 speeds.

 drm_pcie_get_speed_cap_mask() actually checked the pci bridge to see
 what speeds it supported.  If the new code doesn't actually check the
 bridge caps then the new code does not seem like a valid replacement
 unless I'm missing something.

 The max_bus_speed in struct pci_bus is set in pci_set_bus_speed()
 based on the PCIe, PCI-X, or AGP capabilities.  This happens when we
 enumerate the bridge device.  Or, in this case, Lucas added
 powerpc-specific code to set max_bus_speed for the root bus based on
 platform-specific host bridge knowledge.

 So it still does check the PCI bridge capabilities, just not as
 directly as it did before.

Ah, ok.  Thanks.  The previous comments about PCI_SPEED_UNKNOWN being
set in pci_alloc_bus() and never updated confused me.

Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Oops with Radeon/Uninorth on Maple

2012-05-25 Thread Alex Deucher 
On Thu, May 24, 2012 at 2:18 AM, Dmitry Eremin-Solenikov
dmitry_ere...@mentor.com wrote:
 Hello, colleagues,

 I'm trying to enable an AGP slot (again) on my Maple board (dual PPC970FX
 board, with CPC925 (U3H) north bridge).

  For now I'm stuck with a problem: I use radeon card, drm-radeon driver with
 KMS.

 If I force drm-radeon to think about a card as about PCI card (by commenting
 corresponding lines in drm_radeon_kms.c), everything works, I get
 framebuffer, working X11, etc. If I enable agpgart-uninorth driver
 and RADEON_IS_AGP flag in drm driver, I get an Oops early during the
 bootstrap. Relevant part of the log (I can send full dmesg of normal
 bootstrap or this oops on request, if that would help).

For future reference, you can disable AGP by loading radeon with the
agpmode parameter set to -1, e.g., radeon.agpmode=-1

No need to edit the source.

Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev