From: Wolfgang Grandegger <wg@grandegger.com>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Austin Schuh <austin@peloton-tech.com>,
Pavel Pisa <pisa@cmp.felk.cvut.cz>,
linux-can@vger.kernel.org
Subject: Re: sja1000 interrupt problem
Date: Tue, 10 Dec 2013 22:12:18 +0100 [thread overview]
Message-ID: <52A783B2.5020002@grandegger.com> (raw)
In-Reply-To: <52A73BB1.7070701@hartkopp.net>
Hi Oliver,
On 12/10/2013 05:05 PM, Oliver Hartkopp wrote:
> On 10.12.2013 15:41, Wolfgang Grandegger wrote:
>> On Tue, 10 Dec 2013 14:47:24 +0100, Oliver Hartkopp
>
>>> + writew(0x00C3, chan->cfg_base + PITA_ICR);
>>
>> This may kill unhandled (shared) IRQs. You can do that only if all
>> handlers have been called in advance (with a global ISR).
>>
>
> So here's my patch for PITA access protection in peak_pci_post_irq().
>
> Note that we need a single lock for all (e.g. 4) channels of the PITA.
> So my idea was to create the lock in the per-channel structure of the first
> channel and then let the channels 1,2,3 refer to this lock.
Cool, this means that the hardware is not working as expected.
> Maybe there's a better solution for that. E.g. the driver cleanup at removal
> time may get into problems with this approach?!?
>
> So far the system is running. I'll take a look tomorrow morning if its still
> alive :-) Maybe Austin can do some tests with this patch too.
That would be nice... before I start digging through 1 GB of function
trace lines ;-).
One more comment inline...
Wolfgang.
> --- linux-source-3.10/drivers/net/can/sja1000/peak_pci.c 2013-09-08 07:10:14.000000000 +0200
> +++ linux-source-3.10-rt/drivers/net/can/sja1000/peak_pci.c 2013-12-10 16:58:16.381938240 +0100
> @@ -41,6 +41,8 @@
> struct peak_pciec_card;
> struct peak_pci_chan {
> void __iomem *cfg_base; /* Common for all channels */
> + spinlock_t pita_lock;
> + spinlock_t *pita_lock_ptr;
Well, that's ugly and waste space. Already cfg_base is a per card
property. Maybe it's time to introduce a "struct peak_pci_card" and
handle it ala ems_pci.
> struct net_device *prev_dev; /* Chain of network devices */
> u16 icr_mask; /* Interrupt mask for fast ack */
> struct peak_pciec_card *pciec_card; /* only for PCIeC LEDs */
> @@ -539,12 +541,17 @@
> static void peak_pci_post_irq(const struct sja1000_priv *priv)
> {
> struct peak_pci_chan *chan = priv->priv;
> + unsigned long flags;
> u16 icr;
>
> /* Select and clear in PITA stored interrupt */
> + spin_lock_irqsave(chan->pita_lock_ptr, flags);
> +
> icr = readw(chan->cfg_base + PITA_ICR);
> if (icr & chan->icr_mask)
> writew(chan->icr_mask, chan->cfg_base + PITA_ICR);
> +
> + spin_unlock_irqrestore(chan->pita_lock_ptr, flags);
> }
>
> static int peak_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> @@ -553,6 +560,7 @@
> struct peak_pci_chan *chan;
> struct net_device *dev;
> void __iomem *cfg_base, *reg_base;
> + spinlock_t *pita_lock_ptr0;
> u16 sub_sys_id, icr;
> int i, err, channels;
>
> @@ -611,6 +619,7 @@
> icr = readw(cfg_base + PITA_ICR + 2);
>
> for (i = 0; i < channels; i++) {
> +
Please do not add unrelated changes.
> dev = alloc_sja1000dev(sizeof(struct peak_pci_chan));
> if (!dev) {
> err = -ENOMEM;
> @@ -623,6 +632,13 @@
> chan->cfg_base = cfg_base;
> priv->reg_base = reg_base + i * PEAK_PCI_CHAN_SIZE;
>
> + if (i == 0) {
> + spin_lock_init(&chan->pita_lock);
> + pita_lock_ptr0 = &chan->pita_lock;
> + }
> +
> + chan->pita_lock_ptr = pita_lock_ptr0;
> +
> priv->read_reg = peak_pci_read_reg;
> priv->write_reg = peak_pci_write_reg;
> priv->post_irq = peak_pci_post_irq;
>
BTW: while browsing Austin's function trace I realized that we do access
also the inactive device if interrupts are shared. I think we should use
a shadow register variable for SJA1000_IR. Hope to find some time over
the weekend to provide a patch.
Wolfgang.
Wolfgang.
next prev parent reply other threads:[~2013-12-10 21:12 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 0:47 sja1000 interrupt problem Austin Schuh
2013-10-08 6:32 ` Wolfgang Grandegger
2013-10-08 6:58 ` Oliver Hartkopp
2013-10-08 18:48 ` Austin Schuh
2013-10-08 19:44 ` Wolfgang Grandegger
2013-10-08 20:47 ` Austin Schuh
2013-10-09 6:21 ` Wolfgang Grandegger
2013-10-09 6:31 ` Wolfgang Grandegger
2013-10-09 6:47 ` Wolfgang Grandegger
[not found] ` <CANGgnMZpPGctUWGcg7Lp-QFPc7d6A5GeL9KQYnpeYMR8WukgdA@mail.gmail.com>
2013-11-07 8:15 ` Wolfgang Grandegger
2013-11-07 23:43 ` Austin Schuh
2013-11-09 14:21 ` Oliver Hartkopp
2013-11-12 2:59 ` Austin Schuh
2013-11-12 21:26 ` Oliver Hartkopp
2013-11-12 23:22 ` Austin Schuh
2013-11-13 3:41 ` Austin Schuh
2013-11-13 6:58 ` Oliver Hartkopp
2013-11-13 9:48 ` Kurt Van Dijck
2013-11-13 6:44 ` Oliver Hartkopp
2013-11-13 8:11 ` Wolfgang Grandegger
2013-11-13 9:08 ` Pavel Pisa
2013-11-13 9:52 ` Wolfgang Grandegger
2013-11-13 18:41 ` Oliver Hartkopp
2013-11-13 19:29 ` Wolfgang Grandegger
2013-11-13 22:00 ` Oliver Hartkopp
2013-11-13 11:02 ` Kurt Van Dijck
2013-11-16 21:42 ` Oliver Hartkopp
2013-11-17 8:18 ` Wolfgang Grandegger
2013-11-17 14:27 ` Oliver Hartkopp
2013-11-17 17:23 ` Wolfgang Grandegger
2013-11-17 20:46 ` Wolfgang Grandegger
2013-11-18 17:08 ` Austin Schuh
2013-12-09 21:54 ` Austin Schuh
2013-12-09 21:54 ` Austin Schuh
2013-12-10 7:49 ` Wolfgang Grandegger
2013-12-10 8:05 ` Austin Schuh
2013-12-10 9:32 ` Wolfgang Grandegger
2013-12-10 13:47 ` Oliver Hartkopp
2013-12-10 14:23 ` Oliver Hartkopp
2013-12-10 14:41 ` Wolfgang Grandegger
2013-12-10 16:05 ` Oliver Hartkopp
2013-12-10 21:12 ` Wolfgang Grandegger [this message]
2013-12-11 16:59 ` Oliver Hartkopp
2013-12-11 19:27 ` Wolfgang Grandegger
2013-12-12 6:13 ` Oliver Hartkopp
2013-12-12 17:38 ` Oliver Hartkopp
2013-12-12 22:56 ` Wolfgang Grandegger
2013-12-13 0:07 ` Austin Schuh
2013-12-13 16:16 ` Oliver Hartkopp
2013-12-13 9:38 ` Oliver Hartkopp
2013-12-13 10:04 ` Wolfgang Grandegger
2013-12-13 10:09 ` Wolfgang Grandegger
2013-12-13 16:25 ` Oliver Hartkopp
2013-12-13 17:33 ` Wolfgang Grandegger
2013-12-13 10:07 ` Marc Kleine-Budde
2013-12-13 16:22 ` Oliver Hartkopp
2013-12-13 17:14 ` Oliver Hartkopp
2013-12-13 21:14 ` Oliver Hartkopp
2013-12-14 9:51 ` Oliver Hartkopp
2013-12-20 23:13 ` Austin Schuh
2013-12-21 8:29 ` Wolfgang Grandegger
2013-12-21 13:12 ` Oliver Hartkopp
2013-12-21 12:55 ` Oliver Hartkopp
2013-12-23 15:58 ` Oliver Hartkopp
2013-11-09 19:42 ` Wolfgang Grandegger
[not found] ` <CANGgnMbb+VResUC6h+cK6Hfe5PLJx9R9ao6bMdJM2e5BPaDamw@mail.gmail.com>
2013-11-12 22:15 ` Wolfgang Grandegger
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=52A783B2.5020002@grandegger.com \
--to=wg@grandegger.com \
--cc=austin@peloton-tech.com \
--cc=linux-can@vger.kernel.org \
--cc=pisa@cmp.felk.cvut.cz \
--cc=socketcan@hartkopp.net \
/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).