Allocate_respource question
Julia Elbert
jelbert at magma.com
Wed Mar 17 11:43:50 GMT 2004
Hello,
May someone please elaborate on allocate_resource?
It seems as though allocate_resource is changing the io space mapping
from what it should be to something higher and out of range and I don't
know why. When I force the io, my bridges to pci cards work.
If a dec bridge falls under a cardbus bridge, the io resources should
encompass the entire cardbus io range. The dec bridge can't be higher.
Comments.....
Thanks so much.
--Julia
-----Original Message-----
From: linux-pcmcia-bounces at lists.infradead.org
[mailto:linux-pcmcia-bounces at lists.infradead.org] On Behalf Of
linux-pcmcia-request at lists.infradead.org
Sent: Wednesday, March 17, 2004 4:00 AM
To: linux-pcmcia at lists.infradead.org
Subject: linux-pcmcia Digest, Vol 12, Issue 16
Send linux-pcmcia mailing list submissions to
linux-pcmcia at lists.infradead.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
or, via email, send a message with subject or body 'help' to
linux-pcmcia-request at lists.infradead.org
You can reach the person managing the list at
linux-pcmcia-owner at lists.infradead.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of linux-pcmcia digest..."
Today's Topics:
1. Re: [PATCH] Warning fix for "comparison is always false"
(Russell King)
2. Re: [PATCH] Warning fix for "comparison is always false"
(Russell King)
3. Re: [PATCH] Warning fix for "comparison is always false"
(Matthew Wilcox)
4. Re: [PATCH] Warning fix for "comparison is always false"
(Pavel Roskin)
5. Re: [PATCH] Warning fix for "comparison is always false"
(David Hinds)
6. Re: [PATCH] yenta: irq-routing for TI bridges...again
(Pavel Roskin)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Mar 2004 23:08:01 +0000
From: Russell King <rmk+pcmcia at arm.linux.org.uk>
Subject: Re: [PATCH] Warning fix for "comparison is always false"
To: Pavel Roskin <proski at gnu.org>
Cc: linux-pcmcia at lists.infradead.org
Message-ID: <20040316230801.C9931 at flint.arm.linux.org.uk>
Content-Type: text/plain; charset=us-ascii
On Tue, Mar 16, 2004 at 06:00:42PM -0500, Pavel Roskin wrote:
> The attached patch fixes all warnings of this type:
>
> drivers/pcmcia/i82365.c: In function `i365_set_io_map':
> drivers/pcmcia/i82365.c:1134: warning: comparison is always false due
> to limited range of data type
I'd rather they didn't get fixed just yet - my 11-pcmciaresource series
changes a fair amount in this area and this "fix" directly collides with
these patches. These patches are mostly prepared and this change will
mean fscking around with them yet again.
That said, I'm not going to be able to sort that out for at least two
days due to a meeting in another part of the UK taking precidence over
PCMCIA stuff (and the fact that Linus has put out the -rc releases
hasn't helped either.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
------------------------------
Message: 2
Date: Tue, 16 Mar 2004 23:10:10 +0000
From: Russell King <rmk+pcmcia at arm.linux.org.uk>
Subject: Re: [PATCH] Warning fix for "comparison is always false"
To: Pavel Roskin <proski at gnu.org>, linux-pcmcia at lists.infradead.org
Message-ID: <20040316231010.D9931 at flint.arm.linux.org.uk>
Content-Type: text/plain; charset=us-ascii
On Tue, Mar 16, 2004 at 11:08:01PM +0000, Russell King wrote:
> On Tue, Mar 16, 2004 at 06:00:42PM -0500, Pavel Roskin wrote:
> > The attached patch fixes all warnings of this type:
> >
> > drivers/pcmcia/i82365.c: In function `i365_set_io_map':
> > drivers/pcmcia/i82365.c:1134: warning: comparison is always false
due to
> > limited range of data type
>
> I'd rather they didn't get fixed just yet - my 11-pcmciaresource
series
> changes a fair amount in this area and this "fix" directly collides
> with these patches.
Oh, and these changes make these warnings go away as a matter of
course.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
------------------------------
Message: 3
Date: Tue, 16 Mar 2004 23:26:02 +0000
From: Matthew Wilcox <willy at debian.org>
Subject: Re: [PATCH] Warning fix for "comparison is always false"
To: Pavel Roskin <proski at gnu.org>, linux-pcmcia at lists.infradead.org
Message-ID: <20040316232602.GD25059 at parcelfarce.linux.theplanet.co.uk>
Content-Type: text/plain; charset=us-ascii
On Tue, Mar 16, 2004 at 11:08:01PM +0000, Russell King wrote:
> That said, I'm not going to be able to sort that out for at least two
> days due to a meeting in another part of the UK taking precidence over
> PCMCIA stuff (and the fact that Linus has put out the -rc releases
> hasn't helped either.)
I should ignore it if I were you. He doesn't mean it until the third
one.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and
refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
------------------------------
Message: 4
Date: Tue, 16 Mar 2004 19:00:11 -0500 (EST)
From: Pavel Roskin <proski at gnu.org>
Subject: Re: [PATCH] Warning fix for "comparison is always false"
To: Russell King <rmk+pcmcia at arm.linux.org.uk>
Cc: linux-pcmcia at lists.infradead.org
Message-ID:
<Pine.LNX.4.58.0403161826250.17405 at marabou.research.att.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 16 Mar 2004, Russell King wrote:
> On Tue, Mar 16, 2004 at 11:08:01PM +0000, Russell King wrote:
> > On Tue, Mar 16, 2004 at 06:00:42PM -0500, Pavel Roskin wrote:
> > > The attached patch fixes all warnings of this type:
> > >
> > > drivers/pcmcia/i82365.c: In function `i365_set_io_map':
> > > drivers/pcmcia/i82365.c:1134: warning: comparison is always false
due to
> > > limited range of data type
> >
> > I'd rather they didn't get fixed just yet - my 11-pcmciaresource
series
> > changes a fair amount in this area and this "fix" directly collides
> > with these patches.
>
> Oh, and these changes make these warnings go away as a matter of
> course.
It's not on http://pcmcia.arm.linux.org.uk/ yet, but I'll keep
monitoring
that site.
There is one more kind if warnings to be fixed:
drivers/pcmcia/i82365.c: In function `is_alive':
drivers/pcmcia/i82365.c:672: warning: `check_region' is deprecated
(declared at include/linux/ioport.h:121)
drivers/pcmcia/i82365.c: In function `isa_probe':
drivers/pcmcia/i82365.c:806: warning: `check_region' is deprecated
(declared at include/linux/ioport.h:121)
drivers/pcmcia/tcic.c: In function `is_active':
drivers/pcmcia/tcic.c:347: warning: `check_region' is deprecated
(declared
at include/linux/ioport.h:121)
I guess check_region is unneeded is isa_probe(). i82365 already uses
request_region() and handles its failure.
is_active()/is_alive() is more complicated. This probably was designed
to
work with such hacks as booting from PCMCIA flash or PCMCIA network
cards.
In this case the socket driver finds that somebody has already activated
the card and leaves it alone.
We probably could replace check_region() with
request_region()/release_region() to avoid the warning. On the other
hand, using PCMCIA devices without informing the socket driver is a
pretty
gross hack, and we should think whether we still want to allow it.
After
all, 2.6 kernels support early userspace
(Documentation/early-userspace).
--
Regards,
Pavel Roskin
------------------------------
Message: 5
Date: Tue, 16 Mar 2004 16:23:12 -0800
From: David Hinds <dhinds at sonic.net>
Subject: Re: [PATCH] Warning fix for "comparison is always false"
To: Pavel Roskin <proski at gnu.org>
Cc: linux-pcmcia at lists.infradead.org
Message-ID: <20040317002312.GA3715 at sonic.net>
Content-Type: text/plain; charset=us-ascii
On Tue, Mar 16, 2004 at 07:00:11PM -0500, Pavel Roskin wrote:
>
> is_active()/is_alive() is more complicated. This probably was
designed to
> work with such hacks as booting from PCMCIA flash or PCMCIA network
cards.
> In this case the socket driver finds that somebody has already
activated
> the card and leaves it alone.
Correct. Specifically, booting from a PCMCIA IDE device (flash or HD
or CD-ROM).
> We probably could replace check_region() with
> request_region()/ release_region() to avoid the warning. On the other
> hand, using PCMCIA devices without informing the socket driver is a
pretty
> gross hack, and we should think whether we still want to allow it.
After
> all, 2.6 kernels support early userspace
(Documentation/early-userspace).
The early userspace stuff may be part of a solution but I don't think
it is all there yet. All ISA bus driver probes would need to be done
late compared to PCMCIA device enumeration, so that no PCMCIA device
is misdetected as an ISA bus device. Or, something would have to
actively disable all PCMCIA devices early in the boot process, so that
the ISA probes would miss.
Or, it would work now if you built drivers that did ISA probes as
modules, and initialized PCMCIA before those drivers were loaded.
-- Dave
------------------------------
Message: 6
Date: Wed, 17 Mar 2004 04:35:58 -0500 (EST)
From: Pavel Roskin <proski at gnu.org>
Subject: Re: [PATCH] yenta: irq-routing for TI bridges...again
To: Daniel Ritz <daniel.ritz at gmx.ch>
Cc: linux-pcmcia <linux-pcmcia at lists.infradead.org>
Message-ID: <Pine.LNX.4.58.0403170353450.1345 at portland.hansa.lan>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 16 Mar 2004, Daniel Ritz wrote:
> > handlers:
> > [<f88b97b0>] (yenta_interrupt+0x0/0x30 [yenta_socket])
> > Disabling IRQ #12
>
> this is strange. there's the probe handler missing. which of the two
> yenta_probe_cb_irq() is responsible? can you add some printk's?
What happens is that when INTRTIE is set, both 00:08.0 and 00:08.1 have
"Interrupt: pin A routed to IRQ 12" in "lspci -vvv". It I unset it,
00:08.1 has "Interrupt: pin B routed to IRQ 11" instead:
00:08.0 CardBus bridge: Texas Instruments PCI1221
Subsystem: SCM Microsystems: Unknown device 1233
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 168, Cache Line Size: 0x10 (64 bytes)
Interrupt: pin A routed to IRQ 12
Region 0: Memory at ef00a000 (32-bit, non-prefetchable)
[size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
Memory window 0: ef000000-ef001000 (prefetchable)
Memory window 1: ef002000-ef003000
I/O window 0: 00004400-000044ff
I/O window 1: 0000d000-0000d403
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+
PostWrite+
16-bit legacy interface ports at 0001
00:08.1 CardBus bridge: Texas Instruments PCI1221
Subsystem: SCM Microsystems: Unknown device 1233
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 168, Cache Line Size: 0x10 (64 bytes)
Interrupt: pin B routed to IRQ 11
Region 0: Memory at ef004000 (32-bit, non-prefetchable)
[size=4K]
Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
Memory window 0: ef005000-ef006000 (prefetchable)
Memory window 1: ef007000-ef008000
I/O window 0: 00004800-000048ff
I/O window 1: 0000e000-0000e403
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt-
PostWrite+
16-bit legacy interface ports at 0001
If I unset INTRTIE before 00:08.0 is probed, then by the time when
00:08.1
is probed, its dev->irq is already set to 11. This means that
yenta_probe_handler() waits for irq 11, which doesn't arrive.
When the driver sets INTRTIE, dev->irq remains 11, and
yenta_probe_handler() still waits for irq 11. Instead, irq 12 arrives
to
yenta_interrupt(), which doesn't see any events. This condition is
detected and the interrupt is disabled.
Here's the log with some additional debug data:
yenta_probe_cb_irq: dev=0000:00:08.0, pci_irq=12 cb_irq=12 io_irq=0
yenta_probe_handler for 0000:00:08.0
Yenta: ISA IRQ mask 0x0000, PCI irq 12
Socket status: 30000006
Yenta: CardBus bridge found at 0000:00:08.1 [133f:1233]
sysctl before: 0x0844d060
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:08.1, mfunc 0x0cc07d22, devctl 0x60
yenta_probe_cb_irq: dev=0000:00:08.1, pci_irq=11 cb_irq=11 io_irq=0
Yenta TI: socket 0000:00:08.1 probing PCI interrupt failed, trying to
fix
parallel PCI
parallel PCI, mfunc = 0x0cc07d22, mfunc_old = 0x0cc07d22
parallel PCI, set INTRTIE
yenta_probe_cb_irq: dev=0000:00:08.1, pci_irq=11 cb_irq=11 io_irq=0
yenta_interrupt 12 - no events for 0000:00:08.0
[8 more lines]
yenta_interrupt 12 - no events for 0000:00:08.0
irq 12: nobody cared!
Call Trace:
[<c01098f7>] __report_bad_irq+0x27/0x80
[backtrace skipped]
handlers:
[<f88b97b0>] (yenta_interrupt+0x0/0x90 [yenta_socket])
Disabling IRQ #12
parallel PCI, unset INTRTIE
Yenta TI: socket 0000:00:08.1 no PCI interrupts. Fish. Please report.
Yenta: ISA IRQ mask 0x0000, PCI irq 0
Possible solutions:
Give up the idea of adjusting INTRTIE. Consider it a separate problem.
Simply set socket->cb_irq and socket->dev->irq to the same value as in
function 0. Worked for me, although I simply hardcoded 12. PCI
developers may be very angry. Changing socket->cb_irq only is not
enough
according to my tests.
Find why my card didn't produce irq 11 before INTRTIE was set. Make it
work with two different interrupts and hope that it will work for other
cards as well.
--
Regards,
Pavel Roskin
------------------------------
_______________________________________________
Linux PCMCIA reimplementation list digest
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
End of linux-pcmcia Digest, Vol 12, Issue 16
********************************************
More information about the linux-pcmcia
mailing list