From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264256AbUH3K0i (ORCPT ); Mon, 30 Aug 2004 06:26:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S267238AbUH3K0g (ORCPT ); Mon, 30 Aug 2004 06:26:36 -0400 Received: from cantor.suse.de ([195.135.220.2]:7387 "EHLO Cantor.suse.de") by vger.kernel.org with ESMTP id S264256AbUH3K0c (ORCPT ); Mon, 30 Aug 2004 06:26:32 -0400 Date: Mon, 30 Aug 2004 12:26:30 +0200 Message-ID: From: Takashi Iwai To: "David S. Miller" Cc: linux-kernel@vger.kernel.org, perex@suse.de Subject: Re: ALSA update broke Sparc In-Reply-To: <20040827183646.1da2befc.davem@davemloft.net> References: <20040827183646.1da2befc.davem@davemloft.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 15) (Security Through Obscurity) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Fri, 27 Aug 2004 18:36:46 -0700, David S. Miller wrote: > > > Each platform uses a different number of arguments for > io_remap_page_range(), so you can't just blindly call it > from generic code. > > However, sound/core/pcm_native.c is doing exactly that. Argh, sorry about that. My ignorance. > The reason each platform takes a different number of > args is that the "unsigned long" base address argument > is only 32-bits on 32-bit platforms yet on some of > such platforms I/O and physical memory addresses > are larger than 32-bits. > > Sparc and Sparc64 use a "space" argument to provide this > upper 32-bits of information. I'll fix this anyway - but, doesn't it make sense to change the argument type to more reasonable one for 64bit architectures (as wli posted)? > Also, what this PCM mmap'ing code is trying to do > is take I/O addresses and remap them into the process > address space. pci_resource_start() values are not necessarily > suitable for passing around as physical addresses. These > things are well defined when used with ioremap() but > that is it. I don't know if we've defined it such that > passing these into io_remap_page_range() can be expected > to work. > > In fact, because of the sparc 32-bit issue, I know it won't > work. You'll need to have the full resource structure > available, as that's where we hide the upper 32-bits of > the physical address on sparc32. > > This is really non-portable, what the PCM code is doing. > I would suggest, for the time being, to pass resources > around and then have an arch-defined macro which takes > the resource pointer and makes the appropriate io_remap_page_range() > call. Calling io_remap_page_range() in the PCM layer is provided only for certain PCI drivers such as nm256, so disabling this isn't a problem in general. Indeed, this feature should be disabled for architectures like sparc. Or even better, as Russell King suggested before, we can hide arch-specific things by creating a generic mmap method for struct device. I see that sparc already has pci_mmap_page_range() for a similar purpose. > Can I make a small formal request of the ALSA folks? Can you > at least setup a cross-compiler to make sure your ALSA merges > don't explode on sparc64? As it stands, 1 out of every 2 ALSA > merges breaks the build on that platform. I'll try to set up. -- Takashi Iwai ALSA Developer - www.alsa-project.org