From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261529AbUKJJii (ORCPT ); Wed, 10 Nov 2004 04:38:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261527AbUKJJii (ORCPT ); Wed, 10 Nov 2004 04:38:38 -0500 Received: from postino3.roma1.infn.it ([141.108.26.5]:52957 "EHLO postino3.roma1.infn.it") by vger.kernel.org with ESMTP id S261529AbUKJJh0 (ORCPT ); Wed, 10 Nov 2004 04:37:26 -0500 Subject: Re: isa memory address From: Antonino Sergi To: "Maciej W. Rozycki" Cc: "Randy.Dunlap" , linux-kernel@vger.kernel.org In-Reply-To: References: <1099901664.2718.92.camel@delphi.roma1.infn.it> <418FA2F1.2090003@osdl.org> <1100014956.30102.54.camel@delphi.roma1.infn.it> Content-Type: text/plain Message-Id: <1100079437.30102.66.camel@delphi.roma1.infn.it> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 10 Nov 2004 10:37:17 +0100 Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira Milter 1.0.6; VAE 6.28.0.12; VDF 6.28.0.65 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2004-11-09 at 17:56, Maciej W. Rozycki wrote: > On Tue, 9 Nov 2004, Antonino Sergi wrote: > > > I looked for iomem with a kernel-2.4.2: > > > > /proc/iomem reports > > 00000000-0009fbff : System RAM > > 0009fc00-0009ffff : reserved > > 000a0000-000bffff : Video RAM area > > 000c0000-000c7fff : Video ROM > > 000f0000-000fffff : System ROM > > 00100000-1fffbfff : System RAM > > > > Nothing in the region 000d0000-000d0006 (used by my driver), > > so why is it BUSY? > > Because you are trying to use the region in the I/O port space. That's > probably not what you want to do and an 8-bit ISA board cannot decode it > at all anyway. Actually for some platforms using the I/O space outside > the low 16-bit range may be quite difficult even for buses and devices > that support it and Linux does not support it then, either. So Linux > correctly informs you you cannot use that range. This is actually not clear for me. > > > > I'm working with an old data acquisition system that uses an 8-bit card > > > > in an ISA slot (address 0xd0000), by a simple driver I ported from > > > > kernel 1.1.x to 2.2.24. > > > > > > > > It works fine, but I'd like to have features by newer kernels (2.4 or > > > > even 2.6), like new filesystems support. > > > > > > > > On kernels >=2.4.0 check_region returns -EBUSY for that address, > > > > but it is not actually used; I tried to understand if something has been > > > > changed/removed, because of obsolescence of devices, in IO management, > > > > but I couldn't. > > Try check_mem_region() instead, ... > > > > You might have to dummy up a call to release_resource() first, > > > then use request_resource() to acquire it. > > ... or better yet request_mem_region()/release_resource(), as the former > is deprecated and will be removed. I tried but (on 2.4.2): - request_region fails but, ignoring it and remapping physical address to virtual, everything works fine, except for release_region, of course. - request_mem_region works but what I get from communication with the actual device are numbers that sometimes are surely wrong. I couldn't understand what is the actual difference between ioport_resource and iomem_resource to track the problem. Antonino > Maciej