From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] PCI IRQ Pins
Date: Thu, 21 May 2009 20:44:44 +0400 [thread overview]
Message-ID: <4A1584FC.1030709@ru.mvista.com> (raw)
In-Reply-To: <4A156A21.2060108@hiramoto.org>
Hello.
Karl Hiramoto wrote:
>>>>>>Normally you get a backtrace when a "nobody cared" message is
>>>>>>issued -
>>>>>>this should tell you which driver is probably the cause.
>>>>>Right - or that the other device is the cause (stuck IRQ line). So,
>>>>>Karl, please just post the backtrace.
>>>>Krzysztof, you mentioned clearing the IRQ in the platform code, is
>>>>there an example of this somewhere?
>>>>There is a Compact flash on hda connected the the HPT371N, looking
>>>>at the IDE code it looks like the drive my not be ready, or the
>>>>drive may raise the IRQ..
>>>>As soon as request_irq is called, the IRQ happens.
>>>>CCing linux-IDE now, as it may be an issue with this driver.
>>>>Backtrace below, sorry about some of the lines being wrapped.
>>>I think i see the problem:
>>>In the platform code, i should save the frequency of 33 Mhz in the
>>>correct register.
>>You mean the PCI frequency?
>>>>hpt366: HPT371N chipset detected
>>>>hpt366 0000:00:01.0: IDE controller (0x1103:0x0007 rev 0x02)
>>>>PCI: enabling device 0000:00:01.0 (0140 -> 0141)
>>>>hpt366 0000:00:01.0: IDE port disabled
>>>>hpt366 0000:00:01.0: no clock data saved by BIOS
>>>>hpt366 0000:00:01.0: DPLL base: 77 MHz, f_CNT: 120, assuming 50 MHz PCI
>>Hum, interesting... is your PCI indeed running at a frequency close to
>>50 MHz?
To be precise, the formula yields 48 MHz PCI clock for f_CNT of 120. It
then is clamped to 50 MHz (which I'm not quite sure is a good idea).
> No, it's being miscalculated by the hpt366 driver.
Hum... it's hard to miscalculate something when you average f_CNT value
over 128 register reads. :-)
> I think it should be 33 Mhz.
Probably. And there's a chance that your PCI is clocked incorrectly.
> At least i have not yet seen this IRQ "nobody cared" message
> when i set it to 33Mhz in the hpt366 driver.
Hum, interesting, interesting...
> Still doing more tests to see if it comes up again, but it's hard to
> reproduce.
Is it readily reproducible with unmodified driver?
MBR, Sergei
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Karl Hiramoto <karl@hiramoto.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
"ath9k-devel@lists.ath9k.org" <ath9k-devel@lists.ath9k.org>,
linux-arm-kernel <linux-arm-kernel@lists.arm.linux.org.uk>,
linux-ide@vger.kernel.org
Subject: Re: PCI IRQ Pins
Date: Thu, 21 May 2009 20:44:44 +0400 [thread overview]
Message-ID: <4A1584FC.1030709@ru.mvista.com> (raw)
In-Reply-To: <4A156A21.2060108@hiramoto.org>
Hello.
Karl Hiramoto wrote:
>>>>>>Normally you get a backtrace when a "nobody cared" message is
>>>>>>issued -
>>>>>>this should tell you which driver is probably the cause.
>>>>>Right - or that the other device is the cause (stuck IRQ line). So,
>>>>>Karl, please just post the backtrace.
>>>>Krzysztof, you mentioned clearing the IRQ in the platform code, is
>>>>there an example of this somewhere?
>>>>There is a Compact flash on hda connected the the HPT371N, looking
>>>>at the IDE code it looks like the drive my not be ready, or the
>>>>drive may raise the IRQ..
>>>>As soon as request_irq is called, the IRQ happens.
>>>>CCing linux-IDE now, as it may be an issue with this driver.
>>>>Backtrace below, sorry about some of the lines being wrapped.
>>>I think i see the problem:
>>>In the platform code, i should save the frequency of 33 Mhz in the
>>>correct register.
>>You mean the PCI frequency?
>>>>hpt366: HPT371N chipset detected
>>>>hpt366 0000:00:01.0: IDE controller (0x1103:0x0007 rev 0x02)
>>>>PCI: enabling device 0000:00:01.0 (0140 -> 0141)
>>>>hpt366 0000:00:01.0: IDE port disabled
>>>>hpt366 0000:00:01.0: no clock data saved by BIOS
>>>>hpt366 0000:00:01.0: DPLL base: 77 MHz, f_CNT: 120, assuming 50 MHz PCI
>>Hum, interesting... is your PCI indeed running at a frequency close to
>>50 MHz?
To be precise, the formula yields 48 MHz PCI clock for f_CNT of 120. It
then is clamped to 50 MHz (which I'm not quite sure is a good idea).
> No, it's being miscalculated by the hpt366 driver.
Hum... it's hard to miscalculate something when you average f_CNT value
over 128 register reads. :-)
> I think it should be 33 Mhz.
Probably. And there's a chance that your PCI is clocked incorrectly.
> At least i have not yet seen this IRQ "nobody cared" message
> when i set it to 33Mhz in the hpt366 driver.
Hum, interesting, interesting...
> Still doing more tests to see if it comes up again, but it's hard to
> reproduce.
Is it readily reproducible with unmodified driver?
MBR, Sergei
next prev parent reply other threads:[~2009-05-21 16:44 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-20 11:41 [ath9k-devel] PCI IRQ Pins Karl Hiramoto
2009-05-20 12:39 ` Krzysztof Halasa
2009-05-20 20:51 ` Russell King - ARM Linux
2009-05-20 21:43 ` Krzysztof Halasa
2009-05-21 6:14 ` Karl Hiramoto
2009-05-21 6:14 ` Karl Hiramoto
2009-05-21 8:06 ` [ath9k-devel] " Karl Hiramoto
2009-05-21 8:06 ` Karl Hiramoto
2009-05-21 14:45 ` [ath9k-devel] " Sergei Shtylyov
2009-05-21 14:45 ` Sergei Shtylyov
2009-05-21 14:50 ` [ath9k-devel] " Karl Hiramoto
2009-05-21 14:50 ` Karl Hiramoto
2009-05-21 15:07 ` [ath9k-devel] " Karl Hiramoto
2009-05-21 15:07 ` Karl Hiramoto
2009-05-21 16:43 ` [ath9k-devel] " Krzysztof Halasa
2009-05-21 16:43 ` Krzysztof Halasa
2009-05-21 19:12 ` [ath9k-devel] " Karl Hiramoto
2009-05-21 19:12 ` Karl Hiramoto
2009-05-21 16:44 ` Sergei Shtylyov [this message]
2009-05-21 16:44 ` Sergei Shtylyov
2009-05-21 11:04 ` [ath9k-devel] " Krzysztof Halasa
2009-05-21 11:04 ` Krzysztof Halasa
2009-05-21 16:19 ` [ath9k-devel] " Karl Hiramoto
2009-05-21 16:19 ` Karl Hiramoto
2009-05-20 12:40 ` [ath9k-devel] " Michael Schwingen
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=4A1584FC.1030709@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=ath9k-devel@lists.ath9k.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.