From: Michael Buesch <mb@bu3sch.de>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
mchehab@infradead.org,
linux-kernel <linux-kernel@vger.kernel.org>,
Marcel Holtmann <marcel@holtmann.org>,
David Brownell <david-b@pacbell.net>
Subject: Re: [PATCH v3] Add bt8xxgpio driver
Date: Thu, 10 Jul 2008 20:44:21 +0200 [thread overview]
Message-ID: <200807102044.21712.mb@bu3sch.de> (raw)
In-Reply-To: <487651CA.6030405@gmail.com>
On Thursday 10 July 2008 20:15:38 Jiri Slaby wrote:
> > +static int bt8xxgpio_gpio_direction_input(struct gpio_chip *gpio, unsigned nr)
> > +{
> > + struct bt8xxgpio *bg = container_of(gpio, struct bt8xxgpio, gpio);
> > + unsigned long flags;
> > + u32 outen, data;
> > +
> > + spin_lock_irqsave(&bg->lock, flags);
>
> Why all those irq variants? I can't see interrupts anywhere. May gpio call this
> from irq?
Yes. Call context is undefined.
> > +
> > + data = bgread(BT848_GPIO_DATA);
> > + data &= ~(1 << nr);
> > + bgwrite(data, BT848_GPIO_DATA);
> > +
> > + outen = bgread(BT848_GPIO_OUT_EN);
> > + outen &= ~(1 << nr);
> > + bgwrite(outen, BT848_GPIO_OUT_EN);
>
> some flushing of posted values here?
> > +static void bt8xxgpio_gpio_set(struct gpio_chip *gpio,
> > + unsigned nr, int val)
> > +{
> > + struct bt8xxgpio *bg = container_of(gpio, struct bt8xxgpio, gpio);
> > + unsigned long flags;
> > + u32 data;
> > +
> > + spin_lock_irqsave(&bg->lock, flags);
> > +
> > + data = bgread(BT848_GPIO_DATA);
> > + if (val)
> > + data |= (1 << nr);
> > + else
> > + data &= ~(1 << nr);
> > + bgwrite(data, BT848_GPIO_DATA);
>
> and here and further in the code
Well, I'm not sure. This is pretty damn hotpath code. It can be used
for bitbanging busdata, for example. I do actually consider optimizing
that bgread() in the function above away, by caching it in memory.
(First need to do measurements on whether it improves stuff).
So well. What about flushing. In theory it might be needed on some
hardware. But unless somebody can show me some hardware, where this
actually breaks without flushing, I won't consider adding flushes
for performance reasons.
However, an mmiowb() might be added here right before the
spinlock to make the locking safe.
> > + spin_unlock_irqrestore(&bg->lock, flags);
> > +}
> [...]
> > +static int bt8xxgpio_probe(struct pci_dev *dev,
> > + const struct pci_device_id *pci_id)
> > +{
> > + struct bt8xxgpio *bg;
> > + int err;
> > +
> > + bg = kzalloc(sizeof(*bg), GFP_KERNEL);
> > + if (!bg)
> > + return -ENOMEM;
> > +
> > + bg->pdev = dev;
> > + spin_lock_init(&bg->lock);
> > +
> > + err = pci_enable_device(dev);
> > + if (err) {
> > + printk(KERN_ERR "bt8xxgpio: Can't enable device.\n");
>
> dev_err() et al. all over here.
>
> > + goto err_freebg;
> > + }
> > + if (!request_mem_region(pci_resource_start(dev, 0),
> > + pci_resource_len(dev, 0),
> > + "bt8xxgpio")) {
>
> pci_request_region();?
Hell, I shouldn't have derived this from the bttv driver. Almost all
style comments origin from that. ;)
> > + printk(KERN_WARNING
> > + "bt8xxgpio: Can't request iomem (0x%llx).\n",
> > + (unsigned long long)pci_resource_start(dev, 0));
>
> You don't need to print the value out, we can see it in lspci.
Also from bttv...
--
Greetings Michael.
next prev parent reply other threads:[~2008-07-10 18:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-10 17:14 [PATCH v3] Add bt8xxgpio driver Michael Buesch
2008-07-10 18:15 ` Jiri Slaby
2008-07-10 18:44 ` Michael Buesch [this message]
2008-07-10 20:02 ` David Brownell
2008-07-11 12:53 ` Michael Buesch
2008-07-10 19:02 ` Mauro Carvalho Chehab
2008-07-10 19:12 ` Michael Buesch
2008-07-10 19:33 ` Mauro Carvalho Chehab
2008-07-11 13:00 ` Michael Buesch
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=200807102044.21712.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=akpm@linux-foundation.org \
--cc=david-b@pacbell.net \
--cc=jirislaby@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=mchehab@infradead.org \
--cc=sfr@canb.auug.org.au \
/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