Re: [PATCH v2] video: da8xx-fb: Interrupt configuration of revised LCDC IP
On Tue, Jul 05, 2011 at 03:51:20PM +0530, Manjunathappa, Prakash wrote: > An upcoming SoC of TI comes with an LCD controller which is an updated > version of that found on TI's DA850 SoC. The da8xx-fb driver can support > this LCD with some enhancements. > This patch adds support for updated interrupt configuration on the new > SoC. > 1) Registers for setting and clearing interrupts are different. > 2) Raw and masked status registers are different. > The updates have been tested on an emulation platform for new features > and the patch has been tested on DA850 platform to make sure nothing > existing breaks. > > Signed-off-by: Manjunathappa, Prakash Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] video: da8xx: Register IRQ as last thing in driver probing.
On Tue, Nov 30, 2010 at 10:04:14PM +0200, caglarak...@gmail.com wrote: > From: Caglar Akyuz > > Following commit exposed a bug in driver: > > "fbdev: da8xx/omap-l1xx: implement double buffering" > > Bug is, if interrupt handler is called before initialization is > finished, raster controller is enabled and following register > modifications causes hardware to stay in a broken state. > > By looking at this one may say that proper locking is missing in > this driver, and a more proper fix should be prepared. However, > aformentioned commit causes a regression in the driver and some > fix to current one should be applied first. > > Signed-off-by: Caglar Akyuz Barring any objections from the davinci folks, I've queued this up. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 2/4] da850-evm: add UI Expander pushbuttons
On Tue, Nov 23, 2010 at 07:48:21AM -0800, Kevin Hilman wrote: > "Nori, Sekhar" writes: > > On Mon, Nov 22, 2010 at 19:20:48, Ben Gardiner wrote: > >> Yes -- only gpio-keys is affected but enabling the option does > >> introduce an additional .o file: > >> > >> drivers/input/Makefile:obj-$(CONFIG_INPUT_POLLDEV) += input-polldev.o > >> > >> I agree that in its current state a user couls inadvertently disable > >> the gpio-keys support on da850-evm simply by disabling INPUT_POLLDEV > >> -- which is less than Ideal. How about I replace the current changes > >> to arch/arm/mach-davinci/Kconfig with: > >> > >> config KEYBOARD_GPIO > >> default MACH_DAVINCI_DA850_EVM > >> select INPUT_POLLDEV > >> > >> So 1) gpio-keys functionality is default for the da850evm and 2) > >> whenever gpio-keys is enabled so is INPUT_POLLDEV. > > > > This looks better than what was posted earlier, but I am not > > sure if platforms should influence driver configuration this > > way. > > Agreed. In general, we should not have machine/platform specific > conditionals in generic Kconfigs. Generally, this should be handled in > machine/platform specific Kconfigs. > The patch that I originally wrote for this had the select under the Kconfig option for the driver itself, with the decision to use it or not being dynamically determined based on the platform data. I maintain that this is the only sensible way to deal with things, but this was rejected by the input folks at the time who felt that it was adding in extra overhead for a corner case. The alternatives then are to either make an identical copy of the driver that uses a polled interface, come up with lame INPUT_POLLDEV wrapper shims, or simply accept the fact that drivers using optional interfaces are going to have to have those interfaces built in to the kernel. There has been zero progress on getting this functionality integrated for years now because of this issue, and I don't really see that changing until people accept that drivers will sometimes require additional functionality to be built-in, or provide a suitable alternative. Personally I don't care enough about this particular problem to put any more cycles in to it, and the hardware that I wrote this patch for initially will be end-of-lifed long before there's any coherent consensus in driver land. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/4] input: gpio_keys: polling mode support
On Mon, Nov 15, 2010 at 02:07:50PM -0500, Ben Gardiner wrote:
> diff --git a/drivers/input/keyboard/gpio_keys.c
> b/drivers/input/keyboard/gpio_keys.c
> index 6069abe..477802a 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -44,6 +48,26 @@ struct gpio_keys_drvdata {
> struct gpio_button_data data[0];
> };
>
> +#if !defined(CONFIG_INPUT_POLLDEV) && !defined(CONFIG_INPUT_POLLDEV_MODULE)
> +inline struct input_polled_dev *input_allocate_polled_device(void)
> +{
> + return NULL;
> +}
> +
> +inline void input_free_polled_device(struct input_polled_dev *poll_dev)
> +{
> +}
> +
> +inline int input_register_polled_device(struct input_polled_dev *dev)
> +{
> + return -ENXIO;
> +}
> +
> +inline void input_unregister_polled_device(struct input_polled_dev *poll_dev)
> +{
> +}
> +#endif
> +
Wouldn't these be better off in linux/input-polldev.h?
> +#if !defined(CONFIG_INPUT_POLLDEV) && !defined(CONFIG_INPUT_POLLDEV_MODULE)
> + if (pdata->poll_interval) {
> + dev_err(dev, "device needs polling (enable INPUT_POLLDEV)\n");
> + return -EINVAL;
> + }
> +#endif
> +
This you could probably just shove in to..
> ddata = kzalloc(sizeof(struct gpio_keys_drvdata) +
> pdata->nbuttons * sizeof(struct gpio_button_data),
> GFP_KERNEL);
> - input = input_allocate_device();
> + if (pdata->poll_interval) {
> + poll_dev = input_allocate_polled_device();
> + input = poll_dev ? poll_dev->input : 0;
> + } else
> + input = input_allocate_device();
> if (!ddata || !input) {
> dev_err(dev, "failed to allocate state\n");
> error = -ENOMEM;
> goto fail1;
this. Then just get rid of the ifdefs, as the
input_allocate_polled_device() case will have already NULL'ed out.
The rest is obviously fine with me!
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
