[parisc-linux] [PATCH] PCMCIA: Disable probing on parisc

[parisc-linux] [PATCH] PCMCIA: Disable probing on parisc

[Kyle McMartin]

PCMCIA port and memory probing is broken on parisc, disabling both
allows the PCMCIA subsystem to work on parisc systems.

Signed-off-by: James Bottomley <jejb@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>

--- a/drivers/pcmcia/Kconfig	2005-11-29 10:53:24.000000000 -0700
+++ b/drivers/pcmcia/Kconfig	2005-11-11 21:08:04.000000000 -0700
@@ -200,7 +200,11 @@
 
 config PCMCIA_PROBE
 	bool
-	default y if ISA && !ARCH_SA1100 && !ARCH_CLPS711X
+	default y if ISA && !ARCH_SA1100 && !ARCH_CLPS711X && !PARISC
+
+config PCMCIA_PROBE_MEM
+	bool
+	default y if !PARISC
 
 config M32R_PCC
 	bool "M32R PCMCIA I/F"
--- a/drivers/pcmcia/rsrc_nonstatic.c	2005-11-29 10:53:24.000000000 -0700
+++ b/drivers/pcmcia/rsrc_nonstatic.c	2005-11-11 21:08:04.000000000 -0700
@@ -43,7 +43,11 @@
 
 #define INT_MODULE_PARM(n, v) static int n = v; module_param(n, int, 0444)
 
+#ifdef CONFIG_PCMCIA_PROBE_MEM
 INT_MODULE_PARM(probe_mem,	1);		/* memory probe? */
+#else
+INT_MODULE_PARM(probe_mem,	0);		/* memory probe? */
+#endif
 #ifdef CONFIG_PCMCIA_PROBE
 INT_MODULE_PARM(probe_io,	1);		/* IO port probe? */
 INT_MODULE_PARM(mem_limit,	0x10000);
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Russell King]

On Sun, Dec 04, 2005 at 01:04:23AM -0500, Kyle McMartin wrote:
> PCMCIA port and memory probing is broken on parisc, disabling both
> allows the PCMCIA subsystem to work on parisc systems.

Do you know why it's broken?

The memory probing works by mapping the CIS into memory and then trying
to read it.  If you're saying it's broken, that implies that we can't
read the CIS, and therefore we can't use the addresses being probed.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Kyle McMartin]

On Sun, Dec 04, 2005 at 10:33:38AM +0000, Russell King wrote:
> Do you know why it's broken?
>

I'll have to defer to James Bottomley. He was the one who committed
the fixes (I believe he's using pcmcia on a parisc machine for wireless)
originally, I'm just passing along the patches.
 
Cheers,
	Kyle

> The memory probing works by mapping the CIS into memory and then trying
> to read it.  If you're saying it's broken, that implies that we can't
> read the CIS, and therefore we can't use the addresses being probed.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[James Bottomley]

On Sun, 2005-12-04 at 10:33 +0000, Russell King wrote:
> On Sun, Dec 04, 2005 at 01:04:23AM -0500, Kyle McMartin wrote:
> > PCMCIA port and memory probing is broken on parisc, disabling both
> > allows the PCMCIA subsystem to work on parisc systems.
> 
> Do you know why it's broken?
> 
> The memory probing works by mapping the CIS into memory and then trying
> to read it.  If you're saying it's broken, that implies that we can't
> read the CIS, and therefore we can't use the addresses being probed.

On parisc, any read to a region that doesn't respond HPMCs (crashes) the
box.  PA also has separated I/O space, so most random I/O reads are of
non-responding regions.

My solution was simply to force the pcmcia subsystem not to probe and
instead believe the map we passed in from the pcmcia daemon.

James


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Russell King]

On Mon, Dec 05, 2005 at 04:32:19PM -0500, James Bottomley wrote:
> On Sun, 2005-12-04 at 10:33 +0000, Russell King wrote:
> > On Sun, Dec 04, 2005 at 01:04:23AM -0500, Kyle McMartin wrote:
> > > PCMCIA port and memory probing is broken on parisc, disabling both
> > > allows the PCMCIA subsystem to work on parisc systems.
> > 
> > Do you know why it's broken?
> > 
> > The memory probing works by mapping the CIS into memory and then trying
> > to read it.  If you're saying it's broken, that implies that we can't
> > read the CIS, and therefore we can't use the addresses being probed.
> 
> On parisc, any read to a region that doesn't respond HPMCs (crashes) the
> box.  PA also has separated I/O space, so most random I/O reads are of
> non-responding regions.

I don't have issue with the I/O side.  It's the memory side I'm
wondering about.

The probing code sets up a mapping to place the CIS at one of the
regions, and then tries to validate/read the CIS.  It then unmaps
it and maps it into the next place and repeats.  Hence, we're
reading data from the PCMCIA card after setting up various valid
mappings.

These mappings are not much different from the mappings which are
used to interpret the CIS data from the card after the memory
probing has completed.

Hence, if the memory probing is causing you issues, I'd be concerned
about the reliability of reading the CIS data from the card under
the non-probing scenarios.

Alternatively, maybe you've found a real bug somewhere in PCMCIA
which needs fixing...

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[James Bottomley]

On Mon, 2005-12-05 at 22:03 +0000, Russell King wrote:
> I don't have issue with the I/O side.  It's the memory side I'm
> wondering about.

I'm sorry, by I/O reads I mean memory.  PA doesn't have any I/O port
cycles (except those which are generated in the busses via mmio
read/write sequences).

> The probing code sets up a mapping to place the CIS at one of the
> regions, and then tries to validate/read the CIS.  It then unmaps
> it and maps it into the next place and repeats.  Hence, we're
> reading data from the PCMCIA card after setting up various valid
> mappings.

Yes, that's what crashes.  Any memory probe to a non-responding address
on PA causes a high priority machine check.  This is what trips us up.
We have to explicitly list the responding regions in the config file.

James


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Grant Grundler]

On Mon, Dec 05, 2005 at 10:03:44PM +0000, Russell King wrote:
..
> I don't have issue with the I/O side.  It's the memory side I'm
> wondering about.
> 
> The probing code sets up a mapping to place the CIS at one of the
> regions,

How is the region selected? (ie please point me at the right code)

Is there some obvious document that explains my basic questions?
I'm happy to read to learn a bit more.  My ob600ct is still
here waiting for me to fix PCMCIA on it...*sigh*


If using IO port space, parisc can be very flexible as each PCI bus
essentially has it's own IO port space range.

But with MMIO space, routing is typically setup by firmware.
Each PCI bus controller will get one(*) region of MMIO space
routed to it by the chipset. Children of that PCI bus must use
MMIO addresses allocated from that region.

(*) I'm simplifying a bit here. The full explanation is more complex.
   But treating it like one region is sufficient in practice
   and for the purpose of this discussion.

>  and then tries to validate/read the CIS.  It then unmaps
> it and maps it into the next place and repeats.  Hence, we're
> reading data from the PCMCIA card after setting up various valid
> mappings.

Ok. More basic questions:
Why are we doing this? Is this a form of bus walk?

> These mappings are not much different from the mappings which are
> used to interpret the CIS data from the card after the memory
> probing has completed.

I'm not familiar with how CIS data is read from a PCMCIA device.
Normal PCI uses "Config Space". Is PCMCIA using MMIO space
for both CIS/device discovery and assigning MMIO space to
PCMCIA device registers?

> Hence, if the memory probing is causing you issues, I'd be concerned
> about the reliability of reading the CIS data from the card under
> the non-probing scenarios.

If PCMCIA is susceptible to write posting issues, then a
PCI-PCMCIA bridge on PARISC is likely to expose those issues.
ie timing of register writes are likely different.


> Alternatively, maybe you've found a real bug somewhere in PCMCIA
> which needs fixing...

That's possible. If PCMCIA is assigning MMIO addresses outside the
range routed down the PCI bus, the box will HPMC. The "PIM dump"
(CPU state when it HPMC'd) can tell which address the CPU failed
to access. So we should be able to determine if this is the case
or not pretty easily.

I don't have any PCI-PCMCIA adapters...so may have to wait until
james is home again and has an hour to poke at this again.

hth,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Russell King]

On Mon, Dec 05, 2005 at 07:45:23PM -0500, James Bottomley wrote:
> On Mon, 2005-12-05 at 22:03 +0000, Russell King wrote:
> > The probing code sets up a mapping to place the CIS at one of the
> > regions, and then tries to validate/read the CIS.  It then unmaps
> > it and maps it into the next place and repeats.  Hence, we're
> > reading data from the PCMCIA card after setting up various valid
> > mappings.
> 
> Yes, that's what crashes.  Any memory probe to a non-responding address
> on PA causes a high priority machine check.  This is what trips us up.
> We have to explicitly list the responding regions in the config file.

I don't think you've fully understood what I've been saying.
When we try to do memory probing, we setup a mapping in the same
way that we setup a mapping to read the CIS from the card.

Therefore, when we read from the regions we're probing, we should
see valid CIS data.  Therefore, we are _not_ accessing an address
which doesn't respond, but we're accessing an address which we've
asked the PCMCIA bridge to map the card memory to.

If the hardware decides that, despite us setting up such a mapping,
the address we're accessing is not valid, then rather than disabling
the probing we should not ask PCMCIA to use it because the address
range is not available.

In either case, if the memory probe fails in some way, the solution
is not to disable it because then you're just papering over whatever
real problem exists.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Russell King]

On Tue, Dec 06, 2005 at 01:14:58AM -0700, Grant Grundler wrote:
> On Mon, Dec 05, 2005 at 10:03:44PM +0000, Russell King wrote:
> ..
> > I don't have issue with the I/O side.  It's the memory side I'm
> > wondering about.
> > 
> > The probing code sets up a mapping to place the CIS at one of the
> > regions,
> 
> How is the region selected? (ie please point me at the right code)

By the addresses passed in as available resources, or the parent bridge
resources if the cardbus bridge is attached to a P2P bridge.

We start at the start of each resource and interate over it with a step
size of 16k to 8MB depending on the size of the resource.  We ioremap
the physical address, and then ask the PCMCIA controller to forward
accesses targetted at the physical address to the PCMCIA card.

We then access the physical address to check whether it looks like the
cards CIS data, and then we destroy the mapping and iounmap.  Repeat
for each step until we reach the end of the resource.

If that fails, we perform the same thing (mapping the CIS data) but
we use a checksum method on the mapped card data instead.

> Is there some obvious document that explains my basic questions?

Unfortunately the only thing which exists is the code, sorry.

> If using IO port space, parisc can be very flexible as each PCI bus
> essentially has it's own IO port space range.
> 
> But with MMIO space, routing is typically setup by firmware.
> Each PCI bus controller will get one(*) region of MMIO space
> routed to it by the chipset. Children of that PCI bus must use
> MMIO addresses allocated from that region.
> 
> (*) I'm simplifying a bit here. The full explanation is more complex.
>    But treating it like one region is sufficient in practice
>    and for the purpose of this discussion.

I hope you are aware that PCMCIA bridges use memory and IO outside
their own BARs when setting up mappings for legacy PCMCIA cards?
Hence, the parent bridge needs to forward _more_ IO and memory than
the bus would appear to require.

> >  and then tries to validate/read the CIS.  It then unmaps
> > it and maps it into the next place and repeats.  Hence, we're
> > reading data from the PCMCIA card after setting up various valid
> > mappings.
> 
> Ok. More basic questions:
> Why are we doing this? Is this a form of bus walk?

We are doing this to ensure that the memory really is available - on
PCs it may clash with weirdo ACPI/SMM/BIOS crap which we don't know
about.  On non-PCs it should be completely harmless.  If it isn't,
that indicates that we found another hardware problem which precludes
us from using the addresses we're attempting to use.

So the memory probe itself is not the problem, but it found something
we weren't expecting which will cause a problem later.

> > These mappings are not much different from the mappings which are
> > used to interpret the CIS data from the card after the memory
> > probing has completed.
> 
> I'm not familiar with how CIS data is read from a PCMCIA device.
> Normal PCI uses "Config Space". Is PCMCIA using MMIO space
> for both CIS/device discovery and assigning MMIO space to
> PCMCIA device registers?

CIS data describes the PCMCIA card - how much IO and memory space it
needs, the supply voltages, access timings, device IDs and so forth.
It is only accessed once a card has been inserted, and we have asked
the PCMCIA controller to map the CIS memory from the card into the
hosts memory space - which must be available.

> > Hence, if the memory probing is causing you issues, I'd be concerned
> > about the reliability of reading the CIS data from the card under
> > the non-probing scenarios.
> 
> If PCMCIA is susceptible to write posting issues, then a
> PCI-PCMCIA bridge on PARISC is likely to expose those issues.
> ie timing of register writes are likely different.

It could be - the control registers are MMIO, and we would be reading
a different MMIO address.  However, since both of those are on the same
bus (even to the same device) shouldn't the writes complete before the
reads?

> > Alternatively, maybe you've found a real bug somewhere in PCMCIA
> > which needs fixing...
> 
> That's possible. If PCMCIA is assigning MMIO addresses outside the
> range routed down the PCI bus, the box will HPMC. The "PIM dump"
> (CPU state when it HPMC'd) can tell which address the CPU failed
> to access. So we should be able to determine if this is the case
> or not pretty easily.
> 
> I don't have any PCI-PCMCIA adapters...so may have to wait until
> james is home again and has an hour to poke at this again.

Hope the above points folk in the right direction. 8)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[James Bottomley]

On Tue, 2005-12-06 at 09:36 +0000, Russell King wrote:
> I don't think you've fully understood what I've been saying.
> When we try to do memory probing, we setup a mapping in the same
> way that we setup a mapping to read the CIS from the card.

Yes, I do.  On PARISC, memory I/O ranges are directed.  If you program
the CIS to respond outside the directed range of its parent, the I/O
transaction will never get through because the direction is done by the
parent bus (which you aren't programming).  This then causes a HPMC
because no entity on the runway bus responds to the memory read.

James


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Grant Grundler]

On Tue, Dec 06, 2005 at 09:49:08AM +0000, Russell King wrote:
> > How is the region selected? (ie please point me at the right code)
> 
> By the addresses passed in as available resources, or the parent bridge
> resources if the cardbus bridge is attached to a P2P bridge.
> 
> We start at the start of each resource and interate over it with a step
> size of 16k to 8MB depending on the size of the resource.  We ioremap
> the physical address, and then ask the PCMCIA controller to forward
> accesses targetted at the physical address to the PCMCIA card.
> 
> We then access the physical address to check whether it looks like the
> cards CIS data, and then we destroy the mapping and iounmap.  Repeat
> for each step until we reach the end of the resource.

Ok. As long as the MMIO bus addresses used fall within the
range being forwarded down the PCI bus, this should work fine.

> If that fails, we perform the same thing (mapping the CIS data) but
> we use a checksum method on the mapped card data instead.
> 
> > Is there some obvious document that explains my basic questions?
> 
> Unfortunately the only thing which exists is the code, sorry.

I'll try to summarize this thread later this week and mail you a new file
for Documentation/pcmcia/.

> I hope you are aware that PCMCIA bridges use memory and IO outside
> their own BARs when setting up mappings for legacy PCMCIA cards?

I'm not. But that's perfectly ok as long as PCMCIA code only deals
with the MMIO resources associated with that parent PCI bus.

> Hence, the parent bridge needs to forward _more_ IO and memory than
> the bus would appear to require.

We typically assign 8MB-256MB of MMIO space per PCI bus depending
on IO configuration and platforms/chipset. I expect that's more
than what the PCMCIA bridge would request for itself.

> > Ok. More basic questions:
> > Why are we doing this? Is this a form of bus walk?
> 
> We are doing this to ensure that the memory really is available - on
> PCs it may clash with weirdo ACPI/SMM/BIOS crap which we don't know
> about.  On non-PCs it should be completely harmless.  If it isn't,
> that indicates that we found another hardware problem which precludes
> us from using the addresses we're attempting to use.

Ok - that makes sense. I agree it should be harmless.
Sounds like there is a real problem here with how MMIO resources
are being assigned or used.

> So the memory probe itself is not the problem, but it found something
> we weren't expecting which will cause a problem later.

*nod*

> > If PCMCIA is susceptible to write posting issues, then a
> > PCI-PCMCIA bridge on PARISC is likely to expose those issues.
> > ie timing of register writes are likely different.
> 
> It could be - the control registers are MMIO, and we would be reading
> a different MMIO address.  However, since both of those are on the same
> bus (even to the same device) shouldn't the writes complete before the
> reads?

I'm certain PCI ordering rules are enforced. With "write posting" I
was referring to my favorite problem that I talked about here:
	http://iou.parisc-linux.org/ols_2002/4_3MMIO_is_harder.html

Ie any dependency on udelay() after an MMIO write is problematic.

> > That's possible. If PCMCIA is assigning MMIO addresses outside the
> > range routed down the PCI bus, the box will HPMC. The "PIM dump"
> > (CPU state when it HPMC'd) can tell which address the CPU failed
> > to access. So we should be able to determine if this is the case
> > or not pretty easily.
> > 
> > I don't have any PCI-PCMCIA adapters...so may have to wait until
> > james is home again and has an hour to poke at this again.
> 
> Hope the above points folk in the right direction. 8)

Yes - it does. thanks!

grant

> 
> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:  2.6 Serial core
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Dominik Brodowski]

Hi,

On Tue, Dec 06, 2005 at 08:36:48AM -0500, James Bottomley wrote:
> On Tue, 2005-12-06 at 09:36 +0000, Russell King wrote:
> > I don't think you've fully understood what I've been saying.
> > When we try to do memory probing, we setup a mapping in the same
> > way that we setup a mapping to read the CIS from the card.
> 
> Yes, I do.  On PARISC, memory I/O ranges are directed.  If you program
> the CIS to respond outside the directed range of its parent,

Which we do not -- at least what I can see from the code.
drivers/pcmcia/rsrc_nonstatic.c:
	-> pcmcia_nonstatic_validate_mem()
	-> validate_mem()
	-> do_mem_probe()
	-> cis_readable()
	-> claim_region()
		if (s && s->cb_dev)
			parent = pci_find_parent_resource(s->cb_dev, res);
		if (!parent || request_resource(parent, res))
			=> break out
As we should.

And only if it succeeds, we read (or write) to such addresses. At least in
theory. There seems to be a bug -- either in the PARISC setup, or in the
PCMCIA code -- which triggers this HMAC. Let's find it, as _not_ doing these
checks seems to be the wrong thing to do. James, could you find out what
call exactly does this HMAC? Which kernel are you referring to? Also, maybe
a pcibios_resource_to_bus or pcibios_bus_to_resource translation is missing
somewhere?

Thanks,
	Dominik
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[James Bottomley]

On Wed, 2005-12-07 at 13:21 +0100, Dominik Brodowski wrote:
> And only if it succeeds, we read (or write) to such addresses. At least in
> theory. There seems to be a bug -- either in the PARISC setup, or in the
> PCMCIA code -- which triggers this HMAC. Let's find it, as _not_ doing these
> checks seems to be the wrong thing to do. James, could you find out what
> call exactly does this HMAC? Which kernel are you referring to? Also, maybe
> a pcibios_resource_to_bus or pcibios_bus_to_resource translation is missing
> somewhere?

Ah, well, this code has been in parisc for ages ... since I started
using my PA box as a wireless router about two years ago.  My
recollection is that it claimed to probe something in low memory as its
first printout.  Let me reverse the patch and see what happens now (I
assume the code has been updated a bit since we first had to do this).
It will take a while; I have to bring down my home network to do it and
I won't be back home until Friday.

James


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Grant Grundler]

On Wed, Dec 07, 2005 at 01:21:29PM +0100, Dominik Brodowski wrote:
> Which we do not -- at least what I can see from the code.
> drivers/pcmcia/rsrc_nonstatic.c:
...
> 	-> claim_region()
> 		if (s && s->cb_dev)
> 			parent = pci_find_parent_resource(s->cb_dev, res);
> 		if (!parent || request_resource(parent, res))
> 			=> break out
> As we should.

James,
Could post the /proc/iomem output?

It just occurred to me that you shouldn't need to bring down the network.
We can verify if an IO range resource didn't get parented correctly or
otherwise failed to get registered.

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Grant Grundler]

On Tue, Dec 06, 2005 at 09:49:08AM +0000, Russell King wrote:
> > Is there some obvious document that explains my basic questions?
> 
> Unfortunately the only thing which exists is the code, sorry.

Russell,
As promised, here's a first cut on something to add to
Documentation/pcmcia/memory_probe. This is in the hope of
being helpful to others porting PCMCIA to their platform.

There is a "FIXME" bit that you'll need to rephrase or perhaps delete.
I'm not clear if you generalized when mentioning P2P bridges as
the parent of the resources.

I also think the distinction between, CIS memory and PCMCIA
card MMIO ranges isn't as sharp as it could be. The last bit
at the bottom hints at it but doesn't say anything about
why the additional MMIO address space is needed.

I also assumed "CIS data" is the content in "CIS memmory".


/dream on
And someday it might be interesting to use the PCI error recovery
code in PCMCIA memory probing to recovery from failures on PPC and
ia64 platforms. It might be possible on some PARISC chipsets as well
but no one is working on PCI error recovery for any PARISC chipset AFAIK.
/dream off

thanks,
grant



PCMCIA Memory Probing
---------------------

Summarized from parisc-linux mailing thread by Grant Grundler:
http://lists.parisc-linux.org/pipermail/parisc-linux/2005-December/027743.html


Abstract
--------
The memory probing code sets up a mapping to place the CIS in one of
the available regions, and then tries to validate/read the CIS.
The probe code then unmaps the CIS data, maps it into the next place,
and repeats.  We're reading data from the PCMCIA card after setting
up various valid mappings.



> Why are we doing this? Is this a form of bus walk?

We are ensuring the MMIO resource really is available. On PCs this
resource may clash with weirdo ACPI/SMM/BIOS crap which we don't know
about.  On non-PCs probing should be completely harmless.  If it isn't,
we found another hardware problem which precludes use of the offending
address range. So the memory probe itself is not the problem, but it may
find something we weren't expecting which will cause a problem later.


[ unfortunately, it's not always harmless on PA-RISC and some
IA64 platforms. These platforms will HPMC (or MCA respectively) if a
CPU times out on an MMIO read. Error recovery on ia64 could eventually
deal sanely with this. -ggg ]


CIS data describes how much IO and memory space PCMCIA card needs,
the supply voltages, access timings, device IDs and so forth.
It is only accessed once a card has been inserted, and we have asked
the PCMCIA controller to map the CIS memory from the card into the
hosts memory space - which must be available.

CIS data is memory mapped the same way the memory probing is done.
Hence, if the memory probing causes issues, reading CIS data from the
card under the non-probing scenarios is not realiable either.



> How is the region selected? (ie please point me at the right code)

By the addresses passed in as available resources, or the parent bridge
resources if the cardbus bridge is attached to a P2P bridge.

# FIXME - what if the PCMCIA controller is connected to a Host PCI
# Bus controller?
# Maybe I'm being a bit anal in the intrepretation here because
# Host PCI bus controllers *act* like PCI-PCI Bridges from
# a PCI Point of view. But the number and type of resources
# available from a Host PCI bus controller is NOT architected
# as is the case for a PCI-PCI Bridge. 

PCMCIA Probe interates over the entire MMIO resource with a step size
of 16k to 8MB depending on the size of the resource.  We ioremap
the physical address, and then ask the PCMCIA controller to forward
accesses targetted at the physical address to the PCMCIA card.
We then access the physical address, verify the card's CIS data matches
previously read data, and then we destroy the mapping and iounmap.
Repeat for each step until we reach the end of the MMIO resource.

If that fails, we perform the same thing (mapping the CIS data) but
we use a checksum method on the mapped card data instead.


PCMCIA bridges use memory and IO outside their own BARs when setting
up mappings for legacy PCMCIA cards.  Hence, the parent bridge needs
to forward _more_ IO and memory than the bus would appear to require.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[James Bottomley]

On Sat, 2005-12-10 at 23:50 -0700, Grant Grundler wrote:
> Could post the /proc/iomem output?

Sure, it's below

> It just occurred to me that you shouldn't need to bring down the network.
> We can verify if an IO range resource didn't get parented correctly or
> otherwise failed to get registered.

Well, yes I do.  I still need to verify that the kernel works without
the probe prevention hack.  The problem years ago wasn't the parenting,
it was PCMCIA looking for things like ISA memory regions.  I know the
card currently gets the correct parenting and regions (because it
works).  The question is would it without the pcmcia hack?

James

00000000-1fffffff : System RAM
  00000000-000009ff : PDC data (Page Zero)
  00100000-002b8fff : Kernel code
  002b9000-003efe0b : Kernel data
f0190001-f0190001 : led_data
f0800000-f0ffffff : Dino LMMIO 0
  f0800000-f0800fff : 0000:00:02.0
    f0800000-f0800fff : yenta_socket
  f0801000-f0801fff : 0000:00:13.0
    f0801000-f0801fff : sym53c8xx
  f0802000-f08020ff : 0000:00:13.0
    f0802000-f08020ff : sym53c8xx
  f0803000-f080307f : 0000:00:01.0
  f0804000-f080407f : 0000:00:14.0
    f0804000-f080407f : tulip
  f0805000-f0805fff : pcmcia_socket0
  f0900000-f09fffff : PCI CardBus #01
  f0a00000-f0afffff : PCI CardBus #01
f8000000-f8000fff : sti
f8100000-f84fffff : stifb mmio
f9000000-f917ffff : stifb fb
ffd00000-ffdfffff : Lasi
  ffd00000-ffd00fff : Lasi
  ffd05800-ffd05807 : serial
  ffd08000-ffd08fff : GSC PS2
fff80000-fffaffff : Central Bus
  fff80000-fff80fff : Dino
  fff83800-fff83807 : serial
fffb0000-fffdffff : Local Broadcast
  fffbe000-fffbefff : CPU
fffe0000-ffffffff : Global Broadcast


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Grant Grundler]

On Sun, Dec 11, 2005 at 09:14:33AM -0600, James Bottomley wrote:
> On Sat, 2005-12-10 at 23:50 -0700, Grant Grundler wrote:
> > Could post the /proc/iomem output?
> 
> Sure, it's below

thanks

> > It just occurred to me that you shouldn't need to bring down the network.
> > We can verify if an IO range resource didn't get parented correctly or
> > otherwise failed to get registered.
> 
> Well, yes I do.  I still need to verify that the kernel works without
> the probe prevention hack.

Sorry, I wasn't clear - just referring to grabbing the /proc/iomem output.

>   The problem years ago wasn't the parenting,
> it was PCMCIA looking for things like ISA memory regions.  I know the
> card currently gets the correct parenting and regions (because it
> works).

I agree - the output for "Dino LMMIO 0" is correct.

>  The question is would it without the pcmcia hack?

*nod*.  If PCMCIA code is accessing IO Port space looking for legacy
ISA devices, then a parisc box will definitely HPMC.

Most of the parisc PCI bus controllers can only "hard fail" on a
PCI Master Abort for both IO Port and MMIO space accesses. I know
this isn't expected behavior for IO port space but HPUX didn't need
to handle this more gracefully.

I've learned that "ISA Memory regions" are 20 bits for 8-bit ISA or
24-bits for 16-bit ISA. In both cases, I would expect Host RAM to
respond instead of any IO device.  E.g. VGA memory at 0xa0000-0xb0000
would get garbage instead of an HPMC.

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[James Bottomley]

On Sun, 2005-12-11 at 10:50 -0700, Grant Grundler wrote:
> On Sun, Dec 11, 2005 at 09:14:33AM -0600, James Bottomley wrote:
> >  The question is would it without the pcmcia hack?
> 
> *nod*.  If PCMCIA code is accessing IO Port space looking for legacy
> ISA devices, then a parisc box will definitely HPMC.

Well, I pulled out the mem probe and left in the PCMCIA_PROBE config
setting based on !PARISC.

Everything seems to work.  Here's the relevant dmesg output 

Yenta: CardBus bridge found at 0000:00:02.0 [0000:0000]
PCI: Bus 1, cardbus bridge: 0000:00:02.0
  IO window: 00000400-000005ff
  IO window: 00000800-000009ff
  PREFETCH window: f0c00000-f0ffffff
  MEM window: f0900000-f09fffff
Yenta: Enabling burst memory read transactions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:02.0, mfunc 0x00000000, devctl 0x66
Yenta TI: socket 0000:00:02.0 probing PCI interrupt failed, trying to
fix
Yenta TI: socket 0000:00:02.0 falling back to parallel PCI interrupts
Yenta TI: socket 0000:00:02.0 parallel PCI interrupts ok
Yenta: ISA IRQ mask 0x0000, PCI irq 23
Socket status: 30000010
pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
pcmcia: parent PCI bridge Memory window: 0xf0800000 - 0xf0ffffff
pccard: PCMCIA card inserted into slot 0
[...]
cs: memory probe 0xf0800000-0xf0ffffff: excluding 0xf0800000-0xf087ffff
0xf0900000-0xf09fffff 0xf0c00000-0xf0ffffff
pcmcia: registering new device pcmcia0.0
pcmcia: Detected deprecated PCMCIA ioctl usage.
pcmcia: This interface will soon be removed from the kernel; please
expect breakage unless you upgrade to new tools.
pcmcia: see
http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for
details.
orinoco 0.15rc3 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel
Roskin <proski@gnu.org>, et al)

As you can see, we do get the cis memory probe occuring within the
correct boundaries now.

Helge, I think the next test is over to you, could you see how CVS tree
head fares on your tadpole?

Thanks,

James

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Helge Deller]

On Sunday 11 December 2005 19:01, James Bottomley wrote:
> Well, I pulled out the mem probe and left in the PCMCIA_PROBE config
> setting based on !PARISC.
> 
> Everything seems to work.  Here's the relevant dmesg output 
> Yenta: CardBus bridge found at 0000:00:02.0 [0000:0000]
> PCI: Bus 1, cardbus bridge: 0000:00:02.0
>   IO window: 00000400-000005ff
>   IO window: 00000800-000009ff
>   PREFETCH window: f0c00000-f0ffffff
>   MEM window: f0900000-f09fffff
> Yenta: Enabling burst memory read transactions
> Yenta: Using CSCINT to route CSC interrupts to PCI
> Yenta: Routing CardBus interrupts to PCI
> Yenta TI: socket 0000:00:02.0, mfunc 0x00000000, devctl 0x66
> Yenta TI: socket 0000:00:02.0 probing PCI interrupt failed, trying to
> fix
> Yenta TI: socket 0000:00:02.0 falling back to parallel PCI interrupts
> Yenta TI: socket 0000:00:02.0 parallel PCI interrupts ok
> Yenta: ISA IRQ mask 0x0000, PCI irq 23
> Socket status: 30000010
> pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
> pcmcia: parent PCI bridge Memory window: 0xf0800000 - 0xf0ffffff
> pccard: PCMCIA card inserted into slot 0
> [...]
> cs: memory probe 0xf0800000-0xf0ffffff: excluding 0xf0800000-0xf087ffff
> 0xf0900000-0xf09fffff 0xf0c00000-0xf0ffffff
> pcmcia: registering new device pcmcia0.0
>
> As you can see, we do get the cis memory probe occuring within the
> correct boundaries now.
> 
> Helge, I think the next test is over to you, could you see how CVS tree
> head fares on your tadpole?

Hi James,

Seems ok, but I still have the "stuck IRQ" problem:

Dec 11 19:46:11 rdi kernel: Yenta: CardBus bridge found at 0000:00:02.0 [0000:0000]
Dec 11 19:46:11 rdi kernel: PCI: Bus 1, cardbus bridge: 0000:00:02.0
Dec 11 19:46:11 rdi kernel:   IO window: 00000400-000005ff
Dec 11 19:46:11 rdi kernel:   IO window: 00000800-000009ff
Dec 11 19:46:11 rdi kernel:   PREFETCH window: f0c00000-f0ffffff
Dec 11 19:46:11 rdi kernel:   MEM window: f0900000-f09fffff
Dec 11 19:46:12 rdi kernel: Dino 0xfff80000: stuck interrupt 2
Dec 11 19:46:12 rdi last message repeated 7 times
Dec 11 19:46:12 rdi kernel: Yenta: ISA IRQ mask 0x0000, PCI irq 25
Dec 11 19:46:12 rdi kernel: Socket status: 30000007
Dec 11 19:46:12 rdi kernel: pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
Dec 11 19:46:12 rdi kernel: pcmcia: parent PCI bridge Memory window: 0xf0800000 - 0xf0ffffff
Dec 11 19:46:12 rdi kernel: Yenta: CardBus bridge found at 0000:00:02.1 [0000:0000]
Dec 11 19:46:12 rdi kernel: PCI: Bus 5, cardbus bridge: 0000:00:02.1
Dec 11 19:46:12 rdi kernel:   IO window: 00000c00-00000dff
Dec 11 19:46:12 rdi kernel:   IO window: 00001000-000011ff
Dec 11 19:46:12 rdi kernel:   PREFETCH window: f0a00000-f0afffff
Dec 11 19:46:12 rdi kernel:   MEM window: f0b00000-f0bfffff
Dec 11 19:46:12 rdi kernel: Dino 0xfff80000: stuck interrupt 4
Dec 11 19:46:12 rdi last message repeated 7 times
Dec 11 19:46:12 rdi kernel: Yenta: ISA IRQ mask 0x0000, PCI irq 26
Dec 11 19:46:12 rdi kernel: Socket status: 30000811
Dec 11 19:46:12 rdi kernel: pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
Dec 11 19:46:12 rdi kernel: pcmcia: parent PCI bridge Memory window: 0xf0800000 - 0xf0ffffff
Dec 11 19:46:13 rdi kernel: pccard: PCMCIA card inserted into slot 1

Helge
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Matthew Wilcox]

On Sun, Dec 11, 2005 at 07:55:09PM +0100, Helge Deller wrote:
> Seems ok, but I still have the "stuck IRQ" problem:

We have that problem with cardmode dino too ... may or may not be the
same root cause.

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Dominik Brodowski]

Hi,

On Sun, Dec 11, 2005 at 12:01:02PM -0600, James Bottomley wrote:
> On Sun, 2005-12-11 at 10:50 -0700, Grant Grundler wrote:
> > On Sun, Dec 11, 2005 at 09:14:33AM -0600, James Bottomley wrote:
> > >  The question is would it without the pcmcia hack?
> > 
> > *nod*.  If PCMCIA code is accessing IO Port space looking for legacy
> > ISA devices, then a parisc box will definitely HPMC.
> 
> Well, I pulled out the mem probe and left in the PCMCIA_PROBE config
> setting based on !PARISC.
> 
> Everything seems to work.  Here's the relevant dmesg output 
> 
> Yenta: CardBus bridge found at 0000:00:02.0 [0000:0000]
> PCI: Bus 1, cardbus bridge: 0000:00:02.0
>   IO window: 00000400-000005ff
>   IO window: 00000800-000009ff
>   PREFETCH window: f0c00000-f0ffffff
>   MEM window: f0900000-f09fffff
> Yenta: Enabling burst memory read transactions
> Yenta: Using CSCINT to route CSC interrupts to PCI
> Yenta: Routing CardBus interrupts to PCI
> Yenta TI: socket 0000:00:02.0, mfunc 0x00000000, devctl 0x66
> Yenta TI: socket 0000:00:02.0 probing PCI interrupt failed, trying to
> fix
> Yenta TI: socket 0000:00:02.0 falling back to parallel PCI interrupts
> Yenta TI: socket 0000:00:02.0 parallel PCI interrupts ok
> Yenta: ISA IRQ mask 0x0000, PCI irq 23
> Socket status: 30000010
> pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
> pcmcia: parent PCI bridge Memory window: 0xf0800000 - 0xf0ffffff
> pccard: PCMCIA card inserted into slot 0
> [...]
> cs: memory probe 0xf0800000-0xf0ffffff: excluding 0xf0800000-0xf087ffff
> 0xf0900000-0xf09fffff 0xf0c00000-0xf0ffffff

> As you can see, we do get the cis memory probe occuring within the
> correct boundaries now.

Excellent. So is this patch OK? If yes, I'll try to get it into 2.6.16-rc1.

Thanks,
	Dominik


diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index 309eb55..d07b01f 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -200,7 +200,7 @@ config PCMCIA_PXA2XX
 
 config PCMCIA_PROBE
 	bool
-	default y if ISA && !ARCH_SA1100 && !ARCH_CLPS711X
+	default y if ISA && !ARCH_SA1100 && !ARCH_CLPS711X && !PARISC
 
 config M32R_PCC
 	bool "M32R PCMCIA I/F"

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Dominik Brodowski]

Hi,

On Sun, Dec 11, 2005 at 07:55:09PM +0100, Helge Deller wrote:
> Hi James,
> 
> Seems ok, but I still have the "stuck IRQ" problem:
> 
> Dec 11 19:46:11 rdi kernel: Yenta: CardBus bridge found at 0000:00:02.0 [0000:0000]
> Dec 11 19:46:11 rdi kernel: PCI: Bus 1, cardbus bridge: 0000:00:02.0
> Dec 11 19:46:11 rdi kernel:   IO window: 00000400-000005ff
> Dec 11 19:46:11 rdi kernel:   IO window: 00000800-000009ff
> Dec 11 19:46:11 rdi kernel:   PREFETCH window: f0c00000-f0ffffff
> Dec 11 19:46:11 rdi kernel:   MEM window: f0900000-f09fffff
> Dec 11 19:46:12 rdi kernel: Dino 0xfff80000: stuck interrupt 2
> Dec 11 19:46:12 rdi last message repeated 7 times

On Sun, Dec 11, 2005 at 12:09:04PM -0700, Matthew Wilcox wrote:
> On Sun, Dec 11, 2005 at 07:55:09PM +0100, Helge Deller wrote:
> > Seems ok, but I still have the "stuck IRQ" problem:
> 
> We have that problem with cardmode dino too ... may or may not be the
> same root cause.

Does PCMCIA still work? Does it go away with the no-mem-probing hack? I
don't think so. Probably PARISC doesn't like us trying out the ISA interrupt
routing in yenta-socket?

Thanks,
	Dominik

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[James Bottomley]

On Sun, 2005-12-11 at 20:48 +0100, Dominik Brodowski wrote:
> diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
> index 309eb55..d07b01f 100644
> --- a/drivers/pcmcia/Kconfig
> +++ b/drivers/pcmcia/Kconfig
> @@ -200,7 +200,7 @@ config PCMCIA_PXA2XX
>  
>  config PCMCIA_PROBE
>  	bool
> -	default y if ISA && !ARCH_SA1100 && !ARCH_CLPS711X
> +	default y if ISA && !ARCH_SA1100 && !ARCH_CLPS711X && !PARISC

Yes, that's what we have left in the parisc tree.

James

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[James Bottomley]

On Sun, 2005-12-11 at 19:55 +0100, Helge Deller wrote:
> Seems ok, but I still have the "stuck IRQ" problem:

Hmm, perhaps the place to start for this is the firmware information:
In my system, the firmware actually disables the PCMCIA bridge (I assume
because it doesn't understand it).  That's why I added all the code to
dino to redo the entire PCI resource tree, so that it automatically
brings up the PCMCIA bridge.  However, your firmware should understand
the PCMCIA bridge, but it might have some other way of routing the IRQ.

James

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Helge Deller]

[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]

On Sunday 11 December 2005 21:37, James Bottomley wrote:
> On Sun, 2005-12-11 at 19:55 +0100, Helge Deller wrote:
> > Seems ok, but I still have the "stuck IRQ" problem:
> 
> Hmm, perhaps the place to start for this is the firmware information:
> In my system, the firmware actually disables the PCMCIA bridge (I assume
> because it doesn't understand it).  That's why I added all the code to
> dino to redo the entire PCI resource tree, so that it automatically
> brings up the PCMCIA bridge.  However, your firmware should understand
> the PCMCIA bridge, but it might have some other way of routing the IRQ.

Grant helped me to analyze this problem.
The pcmcia irq line seems to be allways off-by-one, e.g. PCI irq 25 got local irq 2 on dino which was wrong and should have become "1".
Grants comment on this was: "Sounds like we need a quirk in drivers/pci/quirks.c to deal with this."
 "or our algorithm for routing IRQ_PIN to INTERRUPT_LINE routing is broken."

Based on that I just created the attached patch. With it pcmcia now works for me.
Maybe you have an idea if something in dino is wrong ?

Helge

dmesg:
PCI: Cirrus Cardbus IRQ fixup for 0000:00:02.0, from 25 to 24 (old native irq=2)
Yenta: CardBus bridge found at 0000:00:02.0 [0000:0000]
PCI: Bus 1, cardbus bridge: 0000:00:02.0
  IO window: 00000400-000005ff
  IO window: 00000800-000009ff
  PREFETCH window: f0c00000-f0ffffff
  MEM window: f0900000-f09fffff
Yenta: ISA IRQ mask 0x0000, PCI irq 24
Socket status: 30000007
pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
pcmcia: parent PCI bridge Memory window: 0xf0800000 - 0xf0ffffff
PCI: Cirrus Cardbus IRQ fixup for 0000:00:02.1, from 26 to 25 (old native irq=3)
Yenta: CardBus bridge found at 0000:00:02.1 [0000:0000]
PCI: Bus 5, cardbus bridge: 0000:00:02.1
  IO window: 00000c00-00000dff
  IO window: 00001000-000011ff
  PREFETCH window: f0a00000-f0afffff
  MEM window: f0b00000-f0bfffff
Yenta: ISA IRQ mask 0x0000, PCI irq 25
Socket status: 30000007
pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
pcmcia: parent PCI bridge Memory window: 0xf0800000 - 0xf0ffffff
ds: ds_open(socket 0)

[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 1358 bytes --]

Index: quirks.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/pci/quirks.c,v
retrieving revision 1.35
diff -u -p -r1.35 quirks.c
--- quirks.c	12 Nov 2005 04:08:03 -0000	1.35
+++ quirks.c	11 Dec 2005 22:22:58 -0000
@@ -862,6 +862,28 @@ static void __init quirk_eisa_bridge(str
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82375,	quirk_eisa_bridge );
 
 /*
+ * Cirrus 6832 Cardbus reports wrong irq on RDI Tadpole PARISC Laptop.
+ */
+#if defined(CONFIG_PARISC)
+static void __devinit quirk_hp_cardbus(struct pci_dev *dev)
+{
+        u8 irq, new_irq;
+
+	new_irq = dev->irq - 1;
+        pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
+
+	printk(KERN_ERR "PCI: Cirrus Cardbus IRQ fixup for %s, from %d to %d (old native irq=%d)\n",
+                        pci_name(dev), dev->irq, new_irq, irq);
+	dev->irq = new_irq;
+
+	udelay(15);     /* unknown if delay really needed */
+	pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+
+}
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_CIRRUS,	PCI_DEVICE_ID_CIRRUS_6832,	quirk_hp_cardbus );
+#endif
+
+/*
  * On ASUS P4B boards, the SMBus PCI Device within the ICH2/4 southbridge
  * is not activated. The myth is that Asus said that they do not want the
  * users to be irritated by just another PCI Device in the Win98 device

[-- Attachment #3: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Grant Grundler]

On Sun, Dec 11, 2005 at 11:35:02PM +0100, Helge Deller wrote:
> Grant helped me to analyze this problem.
> The pcmcia irq line seems to be allways off-by-one, e.g. PCI irq 25
> got local irq 2 on dino which was wrong and should have become "1".
> Grants comment on this was:
>  "Sounds like we need a quirk in drivers/pci/quirks.c to deal with this."

Before I propose the quirk to linux-pci, I need to know the scope of the
problem. Is this a problem only for that PCI slot on that box, for any
slot under dino, any PARISC PCI, or any PCI platform?

For starters, can someone test this on same card on a C3000 or A500?
Both of those use a routing table instead of magic values in PCI device
config registers.

# lspci -vs 00:02.0
0000:00:02.0 CardBus bridge: Cirrus Logic PD 6832 PCMCIA/CardBus Ctrlr (rev c1)
	Flags: bus master, medium devsel, latency 168, IRQ 25
	Memory at f0800000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=01, subordinate=04, sec-latency=176
	Memory window 0: f0c00000-f0fff000
	Memory window 1: f0900000-f09ff000
	I/O window 0: 00000400-000005ff
	I/O window 1: 00000800-000009ff
	16-bit legacy interface ports at 0001

>  "or our algorithm for routing IRQ_PIN to INTERRUPT_LINE routing is broken."

Right now, I can't convinced myself this is a PDC bug on platforms
with built-in Dino.  PDC fills in PCI_INTERRUPT_LINE (becomes pci_dev->irq)
value with the DINO input Interrupt Line (ie index into dino->global_irq[]).
This is used by dino code instead of a "Routing Table".

Other parisc boxes and most architectures use some form of
"IRQ Line Routing Table" to communicate PCI device IRQ_PIN output
to Interrupt Controller input lines mappings to the OS.

But other PCI LAN and SCSI cards work fine under built-in Dino AFAIK.
That's why I'm not sure about the scope of the problem.

> Based on that I just created the attached patch.
> With it pcmcia now works for me.

Yeah, the patch looks fine to me.
I'd just like confirmation that C3000 has the same problem before
I forget how all this works again.

If it doesn't, then we need to figure out how to make this
a dino specific "quirk".

> Maybe you have an idea if something in dino is wrong ?

I don't think there is anything wrong with dino.
Otherwise other cards wouldn't work right either.

thanks,
grant

> 
> Helge
> 
> dmesg:
> PCI: Cirrus Cardbus IRQ fixup for 0000:00:02.0, from 25 to 24 (old native irq=2)
> Yenta: CardBus bridge found at 0000:00:02.0 [0000:0000]
> PCI: Bus 1, cardbus bridge: 0000:00:02.0
>   IO window: 00000400-000005ff
>   IO window: 00000800-000009ff
>   PREFETCH window: f0c00000-f0ffffff
>   MEM window: f0900000-f09fffff
> Yenta: ISA IRQ mask 0x0000, PCI irq 24
> Socket status: 30000007
> pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
> pcmcia: parent PCI bridge Memory window: 0xf0800000 - 0xf0ffffff
> PCI: Cirrus Cardbus IRQ fixup for 0000:00:02.1, from 26 to 25 (old native irq=3)
> Yenta: CardBus bridge found at 0000:00:02.1 [0000:0000]
> PCI: Bus 5, cardbus bridge: 0000:00:02.1
>   IO window: 00000c00-00000dff
>   IO window: 00001000-000011ff
>   PREFETCH window: f0a00000-f0afffff
>   MEM window: f0b00000-f0bfffff
> Yenta: ISA IRQ mask 0x0000, PCI irq 25
> Socket status: 30000007
> pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
> pcmcia: parent PCI bridge Memory window: 0xf0800000 - 0xf0ffffff
> ds: ds_open(socket 0)

> Index: quirks.c
> ===================================================================
> RCS file: /var/cvs/linux-2.6/drivers/pci/quirks.c,v
> retrieving revision 1.35
> diff -u -p -r1.35 quirks.c
> --- quirks.c	12 Nov 2005 04:08:03 -0000	1.35
> +++ quirks.c	11 Dec 2005 22:22:58 -0000
> @@ -862,6 +862,28 @@ static void __init quirk_eisa_bridge(str
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82375,	quirk_eisa_bridge );
>  
>  /*
> + * Cirrus 6832 Cardbus reports wrong irq on RDI Tadpole PARISC Laptop.
> + */
> +#if defined(CONFIG_PARISC)
> +static void __devinit quirk_hp_cardbus(struct pci_dev *dev)
> +{
> +        u8 irq, new_irq;
> +
> +	new_irq = dev->irq - 1;
> +        pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
> +
> +	printk(KERN_ERR "PCI: Cirrus Cardbus IRQ fixup for %s, from %d to %d (old native irq=%d)\n",
> +                        pci_name(dev), dev->irq, new_irq, irq);
> +	dev->irq = new_irq;
> +
> +	udelay(15);     /* unknown if delay really needed */
> +	pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
> +
> +}
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_CIRRUS,	PCI_DEVICE_ID_CIRRUS_6832,	quirk_hp_cardbus );
> +#endif
> +
> +/*
>   * On ASUS P4B boards, the SMBus PCI Device within the ICH2/4 southbridge
>   * is not activated. The myth is that Asus said that they do not want the
>   * users to be irritated by just another PCI Device in the Win98 device

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[James Bottomley]

On Mon, 2005-12-12 at 00:30 -0700, Grant Grundler wrote:
> Before I propose the quirk to linux-pci, I need to know the scope of the
> problem. Is this a problem only for that PCI slot on that box, for any
> slot under dino, any PARISC PCI, or any PCI platform?

Actually, that's the problem.  This device is a built in PCI<->PCMCIA
bridge in the tadpole.  I'm the one with the PCI<->PCMCIA card, and that
doesn't need this quirk.  So, as far as we know (until someone tries
other PCI<->PCMCIA cards) this is the only quirk needed.

So perhaps we should do it in dino_fixup_bus() instead.

James


> For starters, can someone test this on same card on a C3000 or A500?
> Both of those use a routing table instead of magic values in PCI device
> config registers.
> 
> # lspci -vs 00:02.0
> 0000:00:02.0 CardBus bridge: Cirrus Logic PD 6832 PCMCIA/CardBus Ctrlr (rev c1)
> 	Flags: bus master, medium devsel, latency 168, IRQ 25
> 	Memory at f0800000 (32-bit, non-prefetchable) [size=4K]
> 	Bus: primary=00, secondary=01, subordinate=04, sec-latency=176
> 	Memory window 0: f0c00000-f0fff000
> 	Memory window 1: f0900000-f09ff000
> 	I/O window 0: 00000400-000005ff
> 	I/O window 1: 00000800-000009ff
> 	16-bit legacy interface ports at 0001
> 
> >  "or our algorithm for routing IRQ_PIN to INTERRUPT_LINE routing is broken."
> 
> Right now, I can't convinced myself this is a PDC bug on platforms
> with built-in Dino.  PDC fills in PCI_INTERRUPT_LINE (becomes pci_dev->irq)
> value with the DINO input Interrupt Line (ie index into dino->global_irq[]).
> This is used by dino code instead of a "Routing Table".
> 
> Other parisc boxes and most architectures use some form of
> "IRQ Line Routing Table" to communicate PCI device IRQ_PIN output
> to Interrupt Controller input lines mappings to the OS.
> 
> But other PCI LAN and SCSI cards work fine under built-in Dino AFAIK.
> That's why I'm not sure about the scope of the problem.
> 
> > Based on that I just created the attached patch.
> > With it pcmcia now works for me.
> 
> Yeah, the patch looks fine to me.
> I'd just like confirmation that C3000 has the same problem before
> I forget how all this works again.
> 
> If it doesn't, then we need to figure out how to make this
> a dino specific "quirk".
> 
> > Maybe you have an idea if something in dino is wrong ?
> 
> I don't think there is anything wrong with dino.
> Otherwise other cards wouldn't work right either.
> 
> thanks,
> grant
> 
> > 
> > Helge
> > 
> > dmesg:
> > PCI: Cirrus Cardbus IRQ fixup for 0000:00:02.0, from 25 to 24 (old native irq=2)
> > Yenta: CardBus bridge found at 0000:00:02.0 [0000:0000]
> > PCI: Bus 1, cardbus bridge: 0000:00:02.0
> >   IO window: 00000400-000005ff
> >   IO window: 00000800-000009ff
> >   PREFETCH window: f0c00000-f0ffffff
> >   MEM window: f0900000-f09fffff
> > Yenta: ISA IRQ mask 0x0000, PCI irq 24
> > Socket status: 30000007
> > pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
> > pcmcia: parent PCI bridge Memory window: 0xf0800000 - 0xf0ffffff
> > PCI: Cirrus Cardbus IRQ fixup for 0000:00:02.1, from 26 to 25 (old native irq=3)
> > Yenta: CardBus bridge found at 0000:00:02.1 [0000:0000]
> > PCI: Bus 5, cardbus bridge: 0000:00:02.1
> >   IO window: 00000c00-00000dff
> >   IO window: 00001000-000011ff
> >   PREFETCH window: f0a00000-f0afffff
> >   MEM window: f0b00000-f0bfffff
> > Yenta: ISA IRQ mask 0x0000, PCI irq 25
> > Socket status: 30000007
> > pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
> > pcmcia: parent PCI bridge Memory window: 0xf0800000 - 0xf0ffffff
> > ds: ds_open(socket 0)
> 
> > Index: quirks.c
> > ===================================================================
> > RCS file: /var/cvs/linux-2.6/drivers/pci/quirks.c,v
> > retrieving revision 1.35
> > diff -u -p -r1.35 quirks.c
> > --- quirks.c	12 Nov 2005 04:08:03 -0000	1.35
> > +++ quirks.c	11 Dec 2005 22:22:58 -0000
> > @@ -862,6 +862,28 @@ static void __init quirk_eisa_bridge(str
> >  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82375,	quirk_eisa_bridge );
> >  
> >  /*
> > + * Cirrus 6832 Cardbus reports wrong irq on RDI Tadpole PARISC Laptop.
> > + */
> > +#if defined(CONFIG_PARISC)
> > +static void __devinit quirk_hp_cardbus(struct pci_dev *dev)
> > +{
> > +        u8 irq, new_irq;
> > +
> > +	new_irq = dev->irq - 1;
> > +        pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
> > +
> > +	printk(KERN_ERR "PCI: Cirrus Cardbus IRQ fixup for %s, from %d to %d (old native irq=%d)\n",
> > +                        pci_name(dev), dev->irq, new_irq, irq);
> > +	dev->irq = new_irq;
> > +
> > +	udelay(15);     /* unknown if delay really needed */
> > +	pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
> > +
> > +}
> > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_CIRRUS,	PCI_DEVICE_ID_CIRRUS_6832,	quirk_hp_cardbus );
> > +#endif
> > +
> > +/*
> >   * On ASUS P4B boards, the SMBus PCI Device within the ICH2/4 southbridge
> >   * is not activated. The myth is that Asus said that they do not want the
> >   * users to be irritated by just another PCI Device in the Win98 device

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Helge Deller]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

On Monday 12 December 2005 15:45, James Bottomley wrote:
> On Mon, 2005-12-12 at 00:30 -0700, Grant Grundler wrote:
> > Before I propose the quirk to linux-pci, I need to know the scope of the
> > problem. Is this a problem only for that PCI slot on that box, for any
> > slot under dino, any PARISC PCI, or any PCI platform?
> 
> Actually, that's the problem.  This device is a built in PCI<->PCMCIA
> bridge in the tadpole.  I'm the one with the PCI<->PCMCIA card, and that
> doesn't need this quirk.  So, as far as we know (until someone tries
> other PCI<->PCMCIA cards) this is the only quirk needed.
> 
> So perhaps we should do it in dino_fixup_bus() instead.

I agree. As long as we don't know if this is a generic cirrus/parisc/dino problem I think it's not good to add code to the generic drivers/pci.c driver.
Furthermore, since I don't think there are many people out there who have the possibility to test cirrus pcmcia hw on parisc I would propose to put the (temporary) quirk in drivers/parisc/dino.c instead.
Attached is a patch for this parisc-specific quirk which works for me. 
Ok to commit to the local parisc CVS tree ?

Helge

BTW, I tested the orinoco_cs and ide_cs drivers. Both worked like a charm out of the box on my tadpole laptop (B160L) :-)

[-- Attachment #2: diff2 --]
[-- Type: text/plain, Size: 1007 bytes --]

Index: drivers/parisc/dino.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/parisc/dino.c,v
retrieving revision 1.36
diff -u -p -r1.36 dino.c
--- drivers/parisc/dino.c	11 Dec 2005 20:25:11 -0000	1.36
+++ drivers/parisc/dino.c	12 Dec 2005 21:10:14 -0000
@@ -436,6 +436,21 @@ static void dino_choose_irq(struct paris
 	dino_assign_irq(dino, irq, &dev->irq);
 }
 
+
+/*
+ * Cirrus 6832 Cardbus reports wrong irq on RDI Tadpole PARISC Laptop (deller@gmx.de)
+ * (the irqs are off-by-one, not sure yet if this is a cirrus, dino-hardware or dino-driver problem...)
+ */
+static void __devinit quirk_cirrus_cardbus(struct pci_dev *dev)
+{
+	u8 new_irq = dev->irq - 1;
+	printk(KERN_INFO "PCI: Cirrus Cardbus IRQ fixup for %s, from %d to %d\n",
+			pci_name(dev), dev->irq, new_irq);
+	dev->irq = new_irq;
+}
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_6832, quirk_cirrus_cardbus );
+
+
 static void __init
 dino_bios_init(void)
 {

[-- Attachment #3: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: [PATCH] PCMCIA: Disable probing on parisc

[Grant Grundler]

On Mon, Dec 12, 2005 at 10:17:16PM +0100, Helge Deller wrote:
> I agree. As long as we don't know if this is a generic cirrus/parisc/dino problem I think it's not good to add code to the generic drivers/pci.c driver.
> Furthermore, since I don't think there are many people out there who have the possibility to test cirrus pcmcia hw on parisc I would propose to put the (temporary) quirk in drivers/parisc/dino.c instead.
> Attached is a patch for this parisc-specific quirk which works for me. 
> Ok to commit to the local parisc CVS tree ?

yes - please do.

> Helge
> 
> BTW, I tested the orinoco_cs and ide_cs drivers. Both worked like a charm out of the box on my tadpole laptop (B160L) :-)

Very cool :)

thanks,
grant