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 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.