From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Justin Waters <justin.waters@timesys.com>
Cc: linux-input@vger.kernel.org,
linux-arm-kernel@lists.arm.linux.org.uk,
dmitry.torokhov@gmail.com, linux@maxim.org.za
Subject: Re: [PATCH 1/2] atmel_tsadcc: Device driver for AT91SAM9RL Touchscreen
Date: Fri, 25 Apr 2008 22:10:41 +0100 [thread overview]
Message-ID: <20080425211041.GC28497@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1209149798-20418-2-git-send-email-justin.waters@timesys.com>
On Fri, Apr 25, 2008 at 02:56:37PM -0400, Justin Waters wrote:
> The atmel tsadcc is a touchscreen/adc controller found on the AT91SAM9RL
> SoC. This driver provides basic support for this controller for use as a
> touchscreen. Some future improvements include suspend/resume capabilities
> and debugfs support.
>...
> +config TOUCHSCREEN_ATMEL_TSADCC
> + tristate "Atmel Touchscreen Interface"
No dependencies. So does this mean this'll build and link on an
x86 platform?
> +/* These values are dependent upon the performance of the ADC. Ideally,
> + * These should be as close to the startup time and debounce time as
> + * possible (without going over). These assume an optimally setup ADC as
> + * per the electrical characteristics of the AT91SAM9RL tsadcc module
> + */
> +#define TS_POLL_DELAY (1 * 1000000) /* ns delay before the first sample */
> +#define TS_POLL_PERIOD (5 * 1000000) /* ns delay between samples */
So 1ms and 5ms... Not particularly high resolution...
> +static enum hrtimer_restart atmel_tsadcc_timer(struct hrtimer *handle)
So this uses the highres timer infrastructure. Does this build if
CONFIG_HIGH_RES_TIMERS is not set?
> +static int __devinit atmel_tsadcc_probe(struct platform_device *pdev)
> +{
> + struct atmel_tsadcc *ts;
> + struct input_dev *input_dev;
> + struct atmel_tsadcc_platform_data *pdata = pdev->dev.platform_data;
> + int err;
> + struct resource *res;
> + unsigned int regbuf;
This looks haphazard.
> + /* Touchscreen Information */
> + ts->pdev = pdev;
> + ts->input = input_dev;
Weird indentation.
> + /* Remap Register Memory */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + ts->reg_start = res->start;
> + ts->reg_length = res->end - res->start +1;
So if no memory resources were passed, this oopses.
> + /* Setup Clock */
> + ts->tsc_clk = clk_get(&pdev->dev,"tsc_clk");
> + if (IS_ERR(ts->tsc_clk)) {
Great, nice to see a driver using the clock API properly.
> + dev_err(&pdev->dev, "unable to get clock\n");
> + err = PTR_ERR(ts->tsc_clk);
> + goto err_iounmap;
> + }
Odd indentation on the last line above.
> + clk_enable(ts->tsc_clk);
> +
> + regbuf = clk_get_rate(ts->tsc_clk);
> + dev_dbg (&pdev->dev,"Master clock is set at: %d Hz\n",regbuf);
> +
> + /* Setup IRQ */
> + ts->irq = platform_get_irq(pdev, 0);
> + if (ts->irq < 0) {
> + dev_err(&pdev->dev, "unable to get IRQ\n");
> + err = -EBUSY;
> + goto err_clk_put;
> + }
Ditto.
> +
> + /* Fill in initial Register Data */
> + ATMEL_TSADCC_RESET;
> + regbuf = (0x01 & 0x3) | /* TSAMOD */
> + ((0x0 & 0x1) << 5) | /* SLEEP */
(0 & 1) << 5 ? How about using a #define for bit 5 and simply
omitting it?
> + ((0x1 & 0x1) << 6) | /* PENDET */
And a #define for bit 6 as well?
> + ((pdata->prescaler & 0x3F) << 8) | /* PRESCAL */
> + ((pdata->startup & 0x7F) << 16) | /* STARTUP */
> + ((pdata->debounce & 0x0F) << 28); /* PENDBC */
> + atmel_tsadcc_writereg(ATMEL_TSADCC_MR,regbuf);
> +
> + regbuf = (0x4 & 0x7) | /* TRGMOD */
> + ((0xFFFF & 0xFFFF) << 16); /* TRGPER */
> + atmel_tsadcc_writereg(ATMEL_TSADCC_TRGR,regbuf);
> +
> + regbuf = ((pdata->tsshtim & 0xF) << 24); /* TSSHTIM */
> + atmel_tsadcc_writereg(ATMEL_TSADCC_TSR,regbuf);
> +
> + regbuf = atmel_tsadcc_readreg(ATMEL_TSADCC_IMR);
> + dev_dbg (&pdev->dev, "Initial IMR = %X\n", regbuf);
> +
> + /* Register and enable IRQ */
> + if (request_irq(ts->irq, atmel_tsadcc_irq, IRQF_TRIGGER_LOW,
> + pdev->dev.driver->name, ts)) {
> + dev_dbg(&pdev->dev, "IRQ %d busy!\n", ts->irq);
> + err = -EBUSY;
> + goto err_iounmap;
> + }
Ditto.
> + regbuf = ((0x1 & 0x1) << 20) | /* PENCNT */
> + ((0x1 & 0x1) << 21); /* NOCNT */
#defines... even more so then the comments become entirely unnecessary.
next prev parent reply other threads:[~2008-04-25 21:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-25 18:56 [PATCH 0/2] Atmel AT91SAM9RL Touchscreen Driver Justin Waters
2008-04-25 18:56 ` [PATCH 1/2] atmel_tsadcc: Device driver for AT91SAM9RL Touchscreen Justin Waters
2008-04-25 18:56 ` [PATCH 2/2] atmel_tsadcc: Add board specific information for touchscreen driver Justin Waters
2008-04-25 22:29 ` Andrew Victor
2008-04-25 20:34 ` [PATCH 1/2] atmel_tsadcc: Device driver for AT91SAM9RL Touchscreen Dmitry Torokhov
2008-04-25 21:10 ` Russell King - ARM Linux [this message]
2008-04-25 21:37 ` Justin Waters
2008-04-25 22:52 ` David Brownell
2008-06-05 13:49 ` Haavard Skinnemoen
2008-04-25 22:16 ` Andrew Victor
2008-04-28 5:55 ` Uwe Kleine-König
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=20080425211041.GC28497@flint.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=dmitry.torokhov@gmail.com \
--cc=justin.waters@timesys.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-input@vger.kernel.org \
--cc=linux@maxim.org.za \
/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).