From: khc@pm.waw.pl (Krzysztof Halasa)
To: linux-arm-kernel@lists.infradead.org
Subject: IXP4xx: unneeded #include platform-specific include files?
Date: Wed, 18 Nov 2009 01:10:08 +0100 [thread overview]
Message-ID: <m3einw4rrz.fsf@intrepid.localdomain> (raw)
In-Reply-To: <op.u3kae7qg2s3iss@richese> (Imre Kaloz's message of "Wed, 18 Nov 2009 00:05:21 +0100")
"Imre Kaloz" <kaloz@openwrt.org> writes:
> This is far more tolerable, but SLOT1-3 would be better. Also, the
> _MAX thingie should be dropped, for example the LOFT is nothing more
> then an avila with an USB2 controller on the same IRQ as slot 3, where
> the USB1.1 subdevices will show up as well.
I'd prefer that patches like that, changing the actual behaviour of the
code, are done and especially are tested by people with access to the
actual hardware. I don't know if it's ok to assign an IRQ when there is
nothing to assign. If both have the same PCB, well, perhaps it's the way
to go, but I've never seen those boards.
> Those subdevices won't show
> up on a board without the USB controller, but all this will blow up when
> someone plugs a miniPCI USB controller into one of the slots, not to
> mention if he/she plugs in more ;)
Well... Why would it blow up?
A mini-PCI card should use the same IRQ routing, except that it can't
use more than two INT lines. If the INTA/B/C/D lines are rotated
correctly on board and set up in the PCI config space, it should work
fine.
I'm not sure about a mini-PCI card pretending to use more than two INTx
lines. Probably the "pin <= IRQ_LINES" should be changed to
"pin <= 2" for mini-PCI slots, or maybe % 2 should be used. Can't see
anything about that in the standard and personally I don't have such
card.
I didn't know Avila and Loft are based on mini-PCI, and which devices
exactly are mini-PCI slots.
> Now the best question: do those PCI subdevices need an IRQ?
Most probably.
> If there is only
> one IRQ connected to a PCI slot (probably), does it make sense to assign
> IRQs/GPIOs without any effect?
I don't know how are the lines connected to the slots. The mini-PCI slot
has physically 2 INTx lines. The code suggests that the lines are
rotated, that would mean a slot gets two INTx lines. Yes, that means we
shouldn't assign INTC and INTD (in slot's numbering) to such devices,
but I'm not going to make such changes blindly.
If both lines are connected together, both (or all four) "pins" should
get the same INTx.
--
Krzysztof Halasa
next prev parent reply other threads:[~2009-11-18 0:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-15 17:16 IXP4xx: unneeded #include platform-specific include files? Krzysztof Halasa
2009-11-15 18:27 ` Mikael Pettersson
2009-11-15 20:18 ` Imre Kaloz
2009-11-15 21:14 ` Krzysztof Halasa
2009-11-17 21:37 ` Imre Kaloz
2009-11-17 21:53 ` Krzysztof Halasa
2009-11-17 22:11 ` Imre Kaloz
2009-11-17 22:22 ` Krzysztof Halasa
2009-11-17 22:34 ` Imre Kaloz
2009-11-17 22:47 ` Krzysztof Halasa
2009-11-17 23:05 ` Imre Kaloz
2009-11-18 0:10 ` Krzysztof Halasa [this message]
2009-11-15 18:41 ` Mike Westerhof
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3einw4rrz.fsf@intrepid.localdomain \
--to=khc@pm.waw.pl \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).