Re: [PATCH] i2c-davinci: Handle signals gracefully
On 03/10/2014 04:24 PM, Wolfram Sang wrote: Even more, you should complete the whole transfer. There are devices where things can really go wrong if you send a half-complete command and then start with the next one. So, not checking signals at all is the way to go for I2C drivers. There is some cruft left, so I am happy about patches fixing that, with testing on real HW. Like yours here. I agree. I know the Zynq (using a cadence controller) also lets signals interrupt I2C transfers, so I'll propose a patch to Xilinx and CC to you and linux-i2c to completely remove signal handling from that driver as well. Cool, thanks! Are you going to update the davinci patch as well? An amended patch is on its way now. I forgot to set the subject to PATCHv2 though. Mike. Met vriendelijke groet / kind regards, Mike Looijmans TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail ___ 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] media: davinci: vpbe: fix build warning
On 03/14/2014 06:25 AM, Lad, Prabhakar wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
this patch fixes following build warning
drivers/media/platform/davinci/vpbe_display.c: In function
'vpbe_start_streaming':
drivers/media/platform/davinci/vpbe_display.c:344: warning: unused variable
'vpbe_dev'
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Thanks!
Hans
---
drivers/media/platform/davinci/vpbe_display.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index 7a0e40e..b4f12d0 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -341,7 +341,6 @@ static int vpbe_start_streaming(struct vb2_queue *vq,
unsigned int count)
{
struct vpbe_fh *fh = vb2_get_drv_priv(vq);
struct vpbe_layer *layer = fh-layer;
- struct vpbe_device *vpbe_dev = fh-disp_dev-vpbe_dev;
int ret;
/* Get the next frame from the buffer queue */
___
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 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x
On 03/13/2014 03:46 PM, Mark Brown wrote: On Thu, Mar 13, 2014 at 11:18:22AM +0200, Peter Ujfalusi wrote: With this series AM335x and AM447x will use the dmaengine PCM for audio. The daVinci devices will keep using the davinci-pcm for now since I do not have means to test them but the code is written in a way that they can be switched to use the edma-pcm easily (DA850/OMAP-L138 has been tested and audio was working fine). Can you please not resend the ASoC portions of this series until the EDMA portion is stable (and ideally committed)? I'm not quite sure why but every EDMA patch series seems to go through lots of iterations which gets rather noisy - my initial reaction to seeing EDMA in a subject is to just delete the thread. Sure, I'm not planning to spam alsa-devel however the switch to dmaengine PCM for AM335x/AM447x needs the edma patches, otherwise it is not going to work. AFAIK I have not sent patch to edma as of now so I have no idea how long it takes to get stuff in (the good thing is that the edma part does not touch DT, which is alone can reduce the number of iterations). Anyway, what I can - and already did is: Reorder the ASoC patches and I can leave out the switch to dmaengine PCM patch for davinci-mcasp for now. The edma-pcm and the other patches for McASP can go in right away (I will not add the edma-pcm to the Makefile/Kconfig to avoid issues). I will detach the edma stuff and follow it up outside of alsa-devel. The only thing I'm afraid off is that it is going to take two release cycle to get this in: first cycle edma part, next cycle for the ASoC to switch to use the edma-pcm. -- Péter ___ 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] gpio: davinci: fix gpio selection for OF
Am 11.03.2014 11:15, schrieb Linus Walleij: On Wed, Mar 5, 2014 at 12:21 PM, Alexander Holler hol...@ahsoftware.de wrote: The driver missed an of_xlate function to translate gpio numbers as found in the DT to the correct chip and number. While there I've set #gpio_cells to a fixed value of 2. I've used gpio-pxa.c as template for those changes and tested my changes successfully on a da850 board using entries for gpio-leds in a DT. So I didn't reinvent the wheel but just copied and tested stuff. Thanks to Grygorii Strashko for the hint to the existing code in gpio-pxa. Signed-off-by: Alexander Holler hol...@ahsoftware.de Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com This v2 version applied, thanks! Thanks, but actually that should have been a fix for 3.14 with which the OF functionality for davinci gpio gets introduced. I assum with the patch in for-next, 3.14 will appear with that functionality broken and it will become a candidate for -stable. Regards, Alexander Holler ___ 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 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x
On Fri, Mar 14, 2014 at 11:38:58AM +0200, Peter Ujfalusi wrote: The only thing I'm afraid off is that it is going to take two release cycle to get this in: first cycle edma part, next cycle for the ASoC to switch to use the edma-pcm. We can do a cross tree merge, or the EDMA code can be applied to ASoC directly if that's what people want. signature.asc Description: Digital signature ___ 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] gpio: davinci: fix gpio selection for OF
On Fri, Mar 14, 2014 at 11:08 AM, Alexander Holler hol...@ahsoftware.de wrote: Am 11.03.2014 11:15, schrieb Linus Walleij: On Wed, Mar 5, 2014 at 12:21 PM, Alexander Holler hol...@ahsoftware.de wrote: The driver missed an of_xlate function to translate gpio numbers as found in the DT to the correct chip and number. While there I've set #gpio_cells to a fixed value of 2. I've used gpio-pxa.c as template for those changes and tested my changes successfully on a da850 board using entries for gpio-leds in a DT. So I didn't reinvent the wheel but just copied and tested stuff. Thanks to Grygorii Strashko for the hint to the existing code in gpio-pxa. Signed-off-by: Alexander Holler hol...@ahsoftware.de Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com This v2 version applied, thanks! Thanks, but actually that should have been a fix for 3.14 with which the OF functionality for davinci gpio gets introduced. I assum with the patch in for-next, 3.14 will appear with that functionality broken and it will become a candidate for -stable. I just get the impression that DT support for DaVinci in v3.14 is so risky and unstable that noone except those implementing it (i.e. you) is really using it, is that correct? In that case it is hardly a fix that we need to rush out to the entire world. But if you have bug reports from DaVinci developers doing advanced DT stuff and scratching their heads, then we can push this to fixes. Yours, Linus Walleij ___ 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] gpio: davinci: fix gpio selection for OF
On Fri, Mar 14, 2014 at 1:38 PM, Alexander Holler hol...@ahsoftware.de wrote: In that case it is hardly a fix that we need to rush out to the entire world. And I thought the reason for -rc is actually to fix bugs. But I never understood the magical ways and timings patches make their way into mainline. ;) OK so it works like this: early in the -rc cycle we fix any bugs, documentation or whatever. At this point it's *regressions* so the fix need to fix something that broke in the merge window (or an earlier merge window). If it is a new feature that never worked in the first place I would not call that a regression. There are no existing users out there that can experience regressions from a previously working system. So this is why I'm a bit conservative. Yours, Linus Walleij ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
