netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lennert Buytenhek <buytenh@wantstofly.org>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Michael-Luke Jones <mlj28@cam.ac.uk>,
	Jeff Garzik <jeff@garzik.org>,
	netdev@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
	Russell King <rmk@arm.linux.org.uk>,
	ARM Linux Mailing List <linux-arm-kernel@lists.arm.linux.org.uk>
Subject: Re: [PATCH] Intel IXP4xx network drivers v.3 - QMGR
Date: Tue, 8 May 2007 13:32:32 +0200	[thread overview]
Message-ID: <20070508113232.GA32055@xi.wantstofly.org> (raw)
In-Reply-To: <m31whs5ehn.fsf_-_@maximus.localdomain>

I'm not sure what the latest versions are, so I'm not sure which
patches to review and which patches are obsolete.


On Tue, May 08, 2007 at 02:46:28AM +0200, Krzysztof Halasa wrote:

> +struct qmgr_regs __iomem *qmgr_regs;
> +static struct resource *mem_res;
> +static spinlock_t qmgr_lock;
> +static u32 used_sram_bitmap[4]; /* 128 16-dword pages */
> +static void (*irq_handlers[HALF_QUEUES])(void *pdev);
> +static void *irq_pdevs[HALF_QUEUES];
> +
> +void qmgr_set_irq(unsigned int queue, int src,
> +		  void (*handler)(void *pdev), void *pdev)
> +{
> +	u32 __iomem *reg = &qmgr_regs->irqsrc[queue / 8]; /* 8 queues / u32 */
> +	int bit = (queue % 8) * 4; /* 3 bits + 1 reserved bit per queue */
> +	unsigned long flags;
> +
> +	src &= 7;
> +	spin_lock_irqsave(&qmgr_lock, flags);
> +	__raw_writel((__raw_readl(reg) & ~(7 << bit)) | (src << bit), reg);
> +	irq_handlers[queue] = handler;
> +	irq_pdevs[queue] = pdev;
> +	spin_unlock_irqrestore(&qmgr_lock, flags);
> +}

The queue manager interrupts should probably be implemented as an
irqchip, in the same way that GPIO interrupts are implemented.  (I.e.
allocate 'real' interrupt numbers for them, and use the interrupt
cascade mechanism.)  You probably want to have separate irqchips for
the upper and lower halves, too.  This way, drivers can just use
request_irq() instead of having to bother with platform-specific
qmgr_set_irq() methods.  I think I also made this review comment
with Christian's driver.


> +int qmgr_request_queue(unsigned int queue, unsigned int len /* dwords */,
> +		       unsigned int nearly_empty_watermark,
> +		       unsigned int nearly_full_watermark)
> +{
> +	u32 cfg, addr = 0, mask[4]; /* in 16-dwords */
> +	int err;
> +
> +	if (queue >= HALF_QUEUES)
> +		return -ERANGE;
> +
> +	if ((nearly_empty_watermark | nearly_full_watermark) & ~7)
> +		return -EINVAL;
> +
> +	switch (len) {
> +	case  16:
> +		cfg = 0 << 24;
> +		mask[0] = 0x1;
> +		break;
> +	case  32:
> +		cfg = 1 << 24;
> +		mask[0] = 0x3;
> +		break;
> +	case  64:
> +		cfg = 2 << 24;
> +		mask[0] = 0xF;
> +		break;
> +	case 128:
> +		cfg = 3 << 24;
> +		mask[0] = 0xFF;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	cfg |= nearly_empty_watermark << 26;
> +	cfg |= nearly_full_watermark << 29;
> +	len /= 16;		/* in 16-dwords: 1, 2, 4 or 8 */
> +	mask[1] = mask[2] = mask[3] = 0;
> +
> +	if (!try_module_get(THIS_MODULE))
> +		return -ENODEV;
> +
> +	spin_lock_irq(&qmgr_lock);
> +	if (__raw_readl(&qmgr_regs->sram[queue])) {
> +		err = -EBUSY;
> +		goto err;
> +	}
> +
> +	while (1) {
> +		if (!(used_sram_bitmap[0] & mask[0]) &&
> +		    !(used_sram_bitmap[1] & mask[1]) &&
> +		    !(used_sram_bitmap[2] & mask[2]) &&
> +		    !(used_sram_bitmap[3] & mask[3]))
> +			break; /* found free space */
> +
> +		addr++;
> +		shift_mask(mask);
> +		if (addr + len > ARRAY_SIZE(qmgr_regs->sram)) {
> +			printk(KERN_ERR "qmgr: no free SRAM space for"
> +			       " queue %i\n", queue);
> +			err = -ENOMEM;
> +			goto err;
> +		}
> +	}
> +
> +	used_sram_bitmap[0] |= mask[0];
> +	used_sram_bitmap[1] |= mask[1];
> +	used_sram_bitmap[2] |= mask[2];
> +	used_sram_bitmap[3] |= mask[3];
> +	__raw_writel(cfg | (addr << 14), &qmgr_regs->sram[queue]);
> +	spin_unlock_irq(&qmgr_lock);
> +
> +#if DEBUG
> +	printk(KERN_DEBUG "qmgr: requested queue %i, addr = 0x%02X\n",
> +	       queue, addr);
> +#endif
> +	return 0;
> +
> +err:
> +	spin_unlock_irq(&qmgr_lock);
> +	module_put(THIS_MODULE);
> +	return err;
> +}

As with Christian's driver, I don't know whether an SRAM allocator
makes much sense.  We can just set up a static allocation map for the
in-tree drivers and leave out the allocator altogether.  I.e. I don't
think it's worth the complexity (and just because the butt-ugly Intel
code has an allocator isn't a very good reason. :-)

I.e. an API a la:

	ixp4xx_qmgr_config_queue(int queue_nr, int sram_base_address, int queue_size, ...);

might simply suffice.

  parent reply	other threads:[~2007-05-08 11:32 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-06 23:46 [PATCH 0/3] Intel IXP4xx network drivers Krzysztof Halasa
2007-05-07  0:06 ` [PATCH 1/3] WAN Kconfig: change "depends on HDLC" to "select" Krzysztof Halasa
2007-05-07  1:44   ` Roman Zippel
2007-05-07  9:35     ` Krzysztof Halasa
2007-05-07 11:22       ` Roman Zippel
2007-05-07 11:56         ` Krzysztof Halasa
2007-05-07 13:17           ` Roman Zippel
2007-05-07 13:21             ` Jeff Garzik
2007-05-07 13:46               ` Roman Zippel
2007-05-07 16:50                 ` Krzysztof Halasa
2007-05-07 17:07                   ` Roman Zippel
2007-05-07 18:15                     ` Satyam Sharma
2007-05-07 20:31                       ` Jeff Garzik
2007-05-07 20:49                         ` Satyam Sharma
2007-05-07 20:50                         ` Randy Dunlap
2007-05-07 22:39                           ` Satyam Sharma
2007-05-07 22:52                             ` Randy Dunlap
2007-05-07 20:57                         ` Roman Zippel
2007-05-07 20:54                     ` Krzysztof Halasa
2007-05-07 21:02                     ` [PATCH] Use menuconfig objects II - netdev/wan Krzysztof Halasa
2007-05-07 21:08                     ` [PATCH 1a/3] WAN Kconfig: change "depends on HDLC" to "select" Krzysztof Halasa
2007-05-07  0:07 ` [PATCH 2/3] ARM: include IXP4xx "fuses" support Krzysztof Halasa
2007-05-07  5:24   ` Alexey Zaytsev
2007-05-07 10:24     ` Krzysztof Halasa
2007-05-07  0:07 ` [PATCH 3/3] Intel IXP4xx network drivers Krzysztof Halasa
2007-05-07 12:59   ` Michael-Luke Jones
2007-05-07 17:12     ` Krzysztof Halasa
2007-05-07 17:52       ` Christian Hohnstaedt
2007-05-07 20:00         ` Krzysztof Halasa
2007-05-08 11:48           ` Lennert Buytenhek
2007-05-08 13:47             ` Krzysztof Halasa
2007-05-07 18:14       ` Michael-Luke Jones
2007-05-07 19:57         ` Krzysztof Halasa
2007-05-07 20:18           ` Michael-Luke Jones
2007-05-08 11:46             ` Lennert Buytenhek
2007-05-08  0:11           ` [PATCH] Intel IXP4xx network drivers v.2 Krzysztof Halasa
2007-05-08  0:36           ` [PATCH] Intel IXP4xx network drivers v.2 - NPE Krzysztof Halasa
2007-05-08  7:02             ` Michael-Luke Jones
2007-05-08 13:56               ` Krzysztof Halasa
2007-05-08  0:46           ` [PATCH] Intel IXP4xx network drivers v.3 - QMGR Krzysztof Halasa
2007-05-08  7:05             ` Michael-Luke Jones
2007-05-08 13:57               ` Krzysztof Halasa
2007-05-08 11:32             ` Lennert Buytenhek [this message]
2007-05-08 12:47               ` Alexey Zaytsev
2007-05-08 12:59                 ` Lennert Buytenhek
2007-05-08 14:12               ` Krzysztof Halasa
2007-05-08 14:40                 ` Lennert Buytenhek
2007-05-08 16:59                   ` Krzysztof Halasa
2007-05-09 10:21                     ` Lennert Buytenhek
2007-05-10 14:08                       ` Krzysztof Halasa
2007-05-08  1:19           ` [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS Krzysztof Halasa
2007-05-08  5:28             ` Jeff Garzik
2007-05-08  7:22             ` Michael-Luke Jones
2007-05-08 11:37             ` Lennert Buytenhek
2007-05-08 14:31               ` Krzysztof Halasa
2007-05-08 14:53                 ` Lennert Buytenhek
2007-05-08 17:17                   ` Krzysztof Halasa
2007-05-08 11:40   ` [PATCH 3/3] Intel IXP4xx network drivers Lennert Buytenhek
2007-05-07 10:27 ` [PATCH 2a/3] " Krzysztof Halasa
2007-05-08  1:40 ` [PATCH 0/3] " Krzysztof Halasa

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=20070508113232.GA32055@xi.wantstofly.org \
    --to=buytenh@wantstofly.org \
    --cc=jeff@garzik.org \
    --cc=khc@pm.waw.pl \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlj28@cam.ac.uk \
    --cc=netdev@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    /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).