Re: [PATCHv4 1/3] vb2: stop_streaming should return void
Hi Hans,
Thanks for the patch.
On Thu, Apr 17, 2014 at 2:51 PM, Hans Verkuil hverk...@xs4all.nl wrote:
From: Hans Verkuil hans.verk...@cisco.com
The vb2 core ignores any return code from the stop_streaming op.
And there really isn't anything it can do anyway in case of an error.
So change the return type to void and update any drivers that implement it.
The int return gave drivers the idea that this operation could actually
fail, but that's really not the case.
The pwc amd sdr-msi3101 drivers both had this construction:
if (mutex_lock_interruptible(s-v4l2_lock))
return -ERESTARTSYS;
This has been updated to just call mutex_lock(). The stop_streaming op
expects this to really stop streaming and I very much doubt this will
work reliably if stop_streaming just returns without really stopping the
DMA.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Pawel Osciak pa...@osciak.com
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
---
[snip]
drivers/media/platform/davinci/vpbe_display.c | 5 ++---
drivers/media/platform/davinci/vpif_capture.c | 6 ++
drivers/media/platform/davinci/vpif_display.c | 6 ++
[snip]
drivers/staging/media/davinci_vpfe/vpfe_video.c| 3 +--
For the above all,
Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Thanks,
--Prabhakar Lad
drivers/staging/media/dt3155v4l/dt3155v4l.c| 3 +--
drivers/staging/media/go7007/go7007-v4l2.c | 3 +--
drivers/staging/media/msi3101/sdr-msi3101.c| 24
--
drivers/staging/media/rtl2832u_sdr/rtl2832_sdr.c | 7 ++-
drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 3 +--
drivers/staging/media/solo6x10/solo6x10-v4l2.c | 3 +--
include/media/videobuf2-core.h | 2 +-
41 files changed, 69 insertions(+), 128 deletions(-)
diff --git a/Documentation/video4linux/v4l2-pci-skeleton.c
b/Documentation/video4linux/v4l2-pci-skeleton.c
index 80251dc..53dd346 100644
--- a/Documentation/video4linux/v4l2-pci-skeleton.c
+++ b/Documentation/video4linux/v4l2-pci-skeleton.c
@@ -269,7 +269,7 @@ static int start_streaming(struct vb2_queue *vq, unsigned
int count)
* Stop the DMA engine. Any remaining buffers in the DMA queue are dequeued
* and passed on to the vb2 framework marked as STATE_ERROR.
*/
-static int stop_streaming(struct vb2_queue *vq)
+static void stop_streaming(struct vb2_queue *vq)
{
struct skeleton *skel = vb2_get_drv_priv(vq);
@@ -277,7 +277,6 @@ static int stop_streaming(struct vb2_queue *vq)
/* Release all active buffers */
return_all_buffers(skel, VB2_BUF_STATE_ERROR);
- return 0;
}
/*
diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c
b/drivers/media/pci/sta2x11/sta2x11_vip.c
index bb11443..7559951 100644
--- a/drivers/media/pci/sta2x11/sta2x11_vip.c
+++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
@@ -357,7 +357,7 @@ static int start_streaming(struct vb2_queue *vq, unsigned
int count)
}
/* abort streaming and wait for last buffer */
-static int stop_streaming(struct vb2_queue *vq)
+static void stop_streaming(struct vb2_queue *vq)
{
struct sta2x11_vip *vip = vb2_get_drv_priv(vq);
struct vip_buffer *vip_buf, *node;
@@ -374,7 +374,6 @@ static int stop_streaming(struct vb2_queue *vq)
list_del(vip_buf-list);
}
spin_unlock(vip-lock);
- return 0;
}
static struct vb2_ops vip_video_qops = {
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index 200bec9..dfb09d4 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -427,7 +427,7 @@ static int bcap_start_streaming(struct vb2_queue *vq,
unsigned int count)
return 0;
}
-static int bcap_stop_streaming(struct vb2_queue *vq)
+static void bcap_stop_streaming(struct vb2_queue *vq)
{
struct bcap_device *bcap_dev = vb2_get_drv_priv(vq);
struct ppi_if *ppi = bcap_dev-ppi;
@@ -452,7 +452,6 @@ static int bcap_stop_streaming(struct vb2_queue *vq)
list_del(bcap_dev-cur_frm-list);
vb2_buffer_done(bcap_dev-cur_frm-vb, VB2_BUF_STATE_ERROR);
}
- return 0;
}
static struct vb2_ops bcap_video_qops = {
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 3e5199e..d9b1a04 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -2269,7 +2269,7 @@ out:
return ret;
}
-static int coda_stop_streaming(struct vb2_queue *q)
+static void coda_stop_streaming(struct vb2_queue *q)
{
struct coda_ctx *ctx = vb2_get_drv_priv(q);
struct coda_dev *dev = ctx-dev;
@@ -2295,8 +2295,6 @@ static int coda_stop_streaming(struct vb2_queue *q)
ctx-bitstream.vaddr, ctx-bitstream.size);
Re: [PATCH 1/1] media:gspca:dtcs033 Clean sparse check warnings on endianess
Hi,
On 04/16/2014 08:46 PM, Robert Butora wrote:
Warnings due to __le16 / u16 conversions.
Replace offending struct and so stay on cpu domain.
Signed-off-by: Robert Butora robert.butora...@gmail.com
Thanks, I'll include this in my next pull-req to Mauro.
Regards,
Hans
---
drivers/media/usb/gspca/dtcs033.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/gspca/dtcs033.c
b/drivers/media/usb/gspca/dtcs033.c
index 5e42c71..96bfd4e 100644
--- a/drivers/media/usb/gspca/dtcs033.c
+++ b/drivers/media/usb/gspca/dtcs033.c
@@ -22,6 +22,13 @@ MODULE_AUTHOR(Robert Butora
robert.butora...@gmail.com);
MODULE_DESCRIPTION(Scopium DTCS033 astro-cam USB Camera Driver);
MODULE_LICENSE(GPL);
+struct dtcs033_usb_requests {
+ u8 bRequestType;
+ u8 bRequest;
+ u16 wValue;
+ u16 wIndex;
+ u16 wLength;
+};
/* send a usb request */
static void reg_rw(struct gspca_dev *gspca_dev,
@@ -50,10 +57,10 @@ static void reg_rw(struct gspca_dev *gspca_dev,
}
/* send several usb in/out requests */
static int reg_reqs(struct gspca_dev *gspca_dev,
- const struct usb_ctrlrequest *preqs, int n_reqs)
+ const struct dtcs033_usb_requests *preqs, int n_reqs)
{
int i = 0;
- const struct usb_ctrlrequest *preq;
+ const struct dtcs033_usb_requests *preq;
while ((i n_reqs) (gspca_dev-usb_err = 0)) {
@@ -290,7 +297,7 @@ module_usb_driver(sd_driver);
0x40 = USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0xC0 = USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
*/
-static const struct usb_ctrlrequest dtcs033_start_reqs[] = {
+static const struct dtcs033_usb_requests dtcs033_start_reqs[] = {
/* -- bRequest,wValue,wIndex,wLength */
{ 0x40, 0x01, 0x0001, 0x000F, 0x },
{ 0x40, 0x01, 0x, 0x000F, 0x },
@@ -414,7 +421,7 @@ static const struct usb_ctrlrequest dtcs033_start_reqs[]
= {
{ 0x40, 0x01, 0x0003, 0x000F, 0x }
};
-static const struct usb_ctrlrequest dtcs033_stop_reqs[] = {
+static const struct dtcs033_usb_requests dtcs033_stop_reqs[] = {
/* -- bRequest,wValue,wIndex,wLength */
{ 0x40, 0x01, 0x0001, 0x000F, 0x },
{ 0x40, 0x01, 0x, 0x000F, 0x },
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 3/3] saa7134: convert to vb2
On 04/17/2014 03:13 PM, Mauro Carvalho Chehab wrote: Em Thu, 17 Apr 2014 11:49:51 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 04/17/2014 04:17 AM, Mauro Carvalho Chehab wrote: Em Thu, 17 Apr 2014 00:33:55 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 04/17/2014 12:23 AM, Mauro Carvalho Chehab wrote: Em Mon, 10 Mar 2014 13:20:49 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: From: Hans Verkuil hans.verk...@cisco.com Convert the saa7134 driver to vb2. Note that while this uses the vb2-dma-sg version, the VB2_USERPTR mode is disabled. The DMA hardware only supports DMAing full pages, and in the USERPTR memory model the first and last scatter-gather buffer is almost never a full page. In practice this means that we can't use the VB2_USERPTR mode. Why not? Provided that the buffer is equal or bigger than the number of pages required by saa7134, that should be OK. All the driver needs to do is to check if the USERPTR buffer condition is met, returning an error otherwise (and likely printing a msg at dmesg). Yuck. Well, I'll take a look at this. It has in my view the same problem as abusing USERPTR to pass pointers to physically contiguous memory: yes, it 'supports' USERPTR, but it has additional requirements which userspace has no way of knowing or detecting. It's really not USERPTR at all, it is PAGE_ALIGNED_USERPTR. This was a bit confusing following the previous paragraph. I meant to say that the *saa7134* userptr implementation is not USERPTR at all but PAGE_ALIGNED_USERPTR. A proper USERPTR implementation (like in bttv) can use any malloc()ed pointer as it should, but saa7134 can't as it requires the application to align the pointer to a page boundary, which is non-standard. Regards, Hans Quite different. Hmm... If I remember well, mmapped memory (being userptr or not) are always page aligned, at least on systems with MMU. Not malloc()ed memory. That's what userptr is about. Take a look at videobuf_dma_init_user_locked at drivers/media/v4l2-core/videobuf-dma-sg.c: first = (data PAGE_MASK) PAGE_SHIFT; last = ((data+size-1) PAGE_MASK) PAGE_SHIFT; dma-offset = data ~PAGE_MASK; dma-size = size; dma-nr_pages = last-first+1; dma-pages = kmalloc(dma-nr_pages * sizeof(struct page *), GFP_KERNEL); The physical memory is always page aligned, even if VM memory isn't. The offset there is actually used just to subtract the size, at videobuf_pages_to_sg(). So, with VB1, USERPTR works fine, and no special care is needed on userspace to align the offset. Btw, it seems that VB2 also does the same. Take a look at vb2_dma_sg_get_userptr(). -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 3/3] saa7134: convert to vb2
This was a bit confusing following the previous paragraph. I meant to say that the *saa7134* userptr implementation is not USERPTR at all but PAGE_ALIGNED_USERPTR. A proper USERPTR implementation (like in bttv) can use any malloc()ed pointer as it should, but saa7134 can't as it requires the application to align the pointer to a page boundary, which is non-standard. It's probably worth mentioning at this point that there's a bug in videobuf2_vmalloc() where it forces the buffer provided by userptr mode to be page aligned. This causes issues if you hand it a buffer that isn't actually page aligned, as it writes to an arbitrary offset into the buffer instead of the start of the buffer you provided. I've had the following patch in my private tree for months, but had been hesitant to submit it since I didn't know if it would effect other implementations. I wasn't sure if USERPTR mode required the buffers to be page aligned and I was violating the spec. Devin From: Devin Heitmueller dheitmuel...@kernellabs.com Date: Fri, 17 May 2013 19:53:02 + (-0400) Subject: Fix alignment bug when using VB2 with userptr mode Fix alignment bug when using VB2 with userptr mode If we pass in a USERPTR buffer that isn't page aligned, the driver will align it (and not tell userland). The result is that the driver thinks the video starts in one place while userland thinks it starts in another. This manifests itself as the video being horizontally shifted and there being garbage from the start of the field up to that point. This problem was seen with both the em28xx and uvc drivers when testing on the Davinci platform (where the buffers allocated are not necessarily page aligned). --- diff --git a/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c b/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c index 94efa04..ad7ce7c 100644 --- a/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c +++ b/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c @@ -82,7 +82,7 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx, unsigned long vaddr, return NULL; buf-write = write; - offset = vaddr ~PAGE_MASK; + offset = 0; buf-size = size; -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 3/3] saa7134: convert to vb2
Hi Devin, On 04/18/2014 03:49 PM, Devin Heitmueller wrote: This was a bit confusing following the previous paragraph. I meant to say that the *saa7134* userptr implementation is not USERPTR at all but PAGE_ALIGNED_USERPTR. A proper USERPTR implementation (like in bttv) can use any malloc()ed pointer as it should, but saa7134 can't as it requires the application to align the pointer to a page boundary, which is non-standard. It's probably worth mentioning at this point that there's a bug in videobuf2_vmalloc() where it forces the buffer provided by userptr mode to be page aligned. This causes issues if you hand it a buffer that isn't actually page aligned, as it writes to an arbitrary offset into the buffer instead of the start of the buffer you provided. I've had the following patch in my private tree for months, but had been hesitant to submit it since I didn't know if it would effect other implementations. I wasn't sure if USERPTR mode required the buffers to be page aligned and I was violating the spec. Devin From: Devin Heitmueller dheitmuel...@kernellabs.com Date: Fri, 17 May 2013 19:53:02 + (-0400) Subject: Fix alignment bug when using VB2 with userptr mode Fix alignment bug when using VB2 with userptr mode If we pass in a USERPTR buffer that isn't page aligned, the driver will align it (and not tell userland). The result is that the driver thinks the video starts in one place while userland thinks it starts in another. This manifests itself as the video being horizontally shifted and there being garbage from the start of the field up to that point. This problem was seen with both the em28xx and uvc drivers when testing on the Davinci platform (where the buffers allocated are not necessarily page aligned). --- diff --git a/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c b/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c index 94efa04..ad7ce7c 100644 --- a/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c +++ b/linux/drivers/media/v4l2-core/videobuf2-vmalloc.c @@ -82,7 +82,7 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx, unsigned long vaddr, return NULL; buf-write = write; - offset = vaddr ~PAGE_MASK; + offset = 0; buf-size = size; This makes no sense. The vivi driver uses vb2-vmalloc as well, and that works perfectly fine in userptr mode. Applying this patch breaks vivi userptr mode, so this is a NACK for this patch. I wonder though if this is related to this thread: http://www.spinics.net/lists/linux-media/msg75815.html I suspect that in your case the vb2_get_contig_userptr() function is called which as far as I can tell is the wrong function to call for the vmalloc case since there is absolutely no requirement that user pointers should be physically contiguous for vmalloc drivers. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 3/3] saa7134: convert to vb2
Hi Hans, This makes no sense. The vivi driver uses vb2-vmalloc as well, and that works perfectly fine in userptr mode. Applying this patch breaks vivi userptr mode, so this is a NACK for this patch. Don't misunderstand, I acknowledge the very real possibility that I don't fully understand the underlying problem. And to be clear I wasn't intending to send the patch to this mailing list expecting it to be merged. That said, I reproduced it on the ti81xx platform on both em28xx and uvcvideo, so I was comfortable it wasn't an issue with my em28xx VB2 conversion. I wonder though if this is related to this thread: http://www.spinics.net/lists/linux-media/msg75815.html I suspect that in your case the vb2_get_contig_userptr() function is called which as far as I can tell is the wrong function to call for the vmalloc case since there is absolutely no requirement that user pointers should be physically contiguous for vmalloc drivers. Entirely possible. I hadn't followed that thread previously but will take a look. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] az6027: Added the PID for a new revision of the Elgato EyeTV Sat DVB-S Tuner.
There is another clone of AZ6027. This patch adds the relevant PID.
Signed-off-by: Manuel Schönlaub manuel.schoenl...@gmail.com
---
drivers/media/dvb-core/dvb-usb-ids.h | 1 +
drivers/media/usb/dvb-usb/az6027.c | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 1bdc0e7..a2530fe 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -356,6 +356,7 @@
#define USB_PID_ELGATO_EYETV_DTT_2 0x003f
#define USB_PID_ELGATO_EYETV_DTT_Dlx 0x0020
#define USB_PID_ELGATO_EYETV_SAT 0x002a
+#define USB_PID_ELGATO_EYETV_SAT_V20x0025
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_COLD0x5000
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_WARM0x5001
#define USB_PID_FRIIO_WHITE0x0001
diff --git a/drivers/media/usb/dvb-usb/az6027.c
b/drivers/media/usb/dvb-usb/az6027.c
index c11138e..0df52ab 100644
--- a/drivers/media/usb/dvb-usb/az6027.c
+++ b/drivers/media/usb/dvb-usb/az6027.c
@@ -1088,6 +1088,7 @@ static struct usb_device_id az6027_usb_table[] = {
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V1) },
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V2) },
{ USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_SAT) },
+ { USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_SAT_V2) },
{ },
};
@@ -1136,7 +1137,7 @@ static struct dvb_usb_device_properties az6027_properties
= {
.i2c_algo = az6027_i2c_algo,
- .num_device_descs = 6,
+ .num_device_descs = 7,
.devices = {
{
.name = AZUREWAVE DVB-S/S2 USB2.0 (AZ6027),
@@ -1162,6 +1163,10 @@ static struct dvb_usb_device_properties
az6027_properties = {
.name = Elgato EyeTV Sat,
.cold_ids = { az6027_usb_table[5], NULL },
.warm_ids = { NULL },
+ }, {
+ .name = Elgato EyeTV Sat,
+ .cold_ids = { az6027_usb_table[6], NULL },
+ .warm_ids = { NULL },
},
{ NULL },
}
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] az6027: Added the PID for a new revision of the Elgato EyeTV Sat DVB-S Tuner.
There is another clone of AZ6027. This patch adds the relevant PID.
Signed-off-by: Manuel Schönlaub manuel.schoenl...@gmail.com
---
drivers/media/dvb-core/dvb-usb-ids.h | 1 +
drivers/media/usb/dvb-usb/az6027.c | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 1bdc0e7..a2530fe 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -356,6 +356,7 @@
#define USB_PID_ELGATO_EYETV_DTT_2 0x003f
#define USB_PID_ELGATO_EYETV_DTT_Dlx 0x0020
#define USB_PID_ELGATO_EYETV_SAT 0x002a
+#define USB_PID_ELGATO_EYETV_SAT_V20x0025
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_COLD0x5000
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_WARM0x5001
#define USB_PID_FRIIO_WHITE0x0001
diff --git a/drivers/media/usb/dvb-usb/az6027.c
b/drivers/media/usb/dvb-usb/az6027.c
index c11138e..0df52ab 100644
--- a/drivers/media/usb/dvb-usb/az6027.c
+++ b/drivers/media/usb/dvb-usb/az6027.c
@@ -1088,6 +1088,7 @@ static struct usb_device_id az6027_usb_table[] = {
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V1) },
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V2) },
{ USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_SAT) },
+ { USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_SAT_V2) },
{ },
};
@@ -1136,7 +1137,7 @@ static struct dvb_usb_device_properties az6027_properties
= {
.i2c_algo = az6027_i2c_algo,
- .num_device_descs = 6,
+ .num_device_descs = 7,
.devices = {
{
.name = AZUREWAVE DVB-S/S2 USB2.0 (AZ6027),
@@ -1162,6 +1163,10 @@ static struct dvb_usb_device_properties
az6027_properties = {
.name = Elgato EyeTV Sat,
.cold_ids = { az6027_usb_table[5], NULL },
.warm_ids = { NULL },
+ }, {
+ .name = Elgato EyeTV Sat,
+ .cold_ids = { az6027_usb_table[6], NULL },
+ .warm_ids = { NULL },
},
{ NULL },
}
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v3 0/5] LED / flash API integration
On Fri, Apr 11, 2014 at 7:56 AM, Jacek Anaszewski j.anaszew...@samsung.com wrote: This is is the third version of the patch series being a follow up of the discussion on Media summit 2013-10-23, related to the LED / flash API integration (the notes from the discussion were enclosed in the message [1], paragraph 5). The series is based on linux-next next-20140328 Description of the proposed modifications according to the kernel components they are relevant to: - LED subsystem modifications * added led_flash module which, when enabled in the config, registers flash specific sysfs attributes: - flash_brightness - max_flash_brightness - indicator_brightness - max_indicator_brightness - flash_timeout - max_flash_timeout - flash_strobe - flash_fault - external_strobe and exposes kernel internal API - led_set_flash_strobe - led_get_flash_strobe - led_set_indicator_brightness - led_update_indicator_brightness - led_set_flash_timeout - led_get_flash_fault - led_set_external_strobe - led_sysfs_lock - led_sysfs_unlock - Addition of a V4L2 Flash sub-device registration helpers * added v4l2-flash.c and v4l2-flash.h files with helper functions that facilitate registration/unregistration of a subdevice, which wrapps a LED subsystem device and exposes V4L2 Flash control interface - Addition of a driver for the flash cell of the MAX77693 mfd * the driver exploits the newly introduced mechanism - Update of the max77693.txt DT bindings documentation Changes since v2 - refactored the code so that it is possible to build led-core without led-flash module - added v4l2-flash ops which slackens dependency from the led-flash module - implemented led_clamp_align_val function and led_ctrl structure which allows to align led control values in the manner compatible with V4L2 Flash controls; the flash brightness and timeout units have been defined as microamperes and microseconds respectively to properly support devices which define current and time levels as fractions of 1/1000. - added support for the flash privacy leds - modified LED sysfs locking mechanism - now it locks/unlocks the interface on V4L2 Flash sub-device file open/close - changed hw_triggered attribute name to external_strobe, which maps on the V4L2_FLASH_STROBE_SOURCE_EXTERNAL name more intuitively - made external_strobe and indicator related sysfs attributes created optionally only if related features are declared by the led device driver - removed from the series patches modifying exynos4-is media controller - a proposal for flash manager which will take care of flash devices registration is due to be submitted - removed modifications to the LED class devices documentation, it will be covered after the whole functionality is accepted Thanks a lot for pushing this, I'm trapping in some other urgent tasks and will review it soon when I'm free. -Bryan Thanks, Jacek Anaszewski [1] http://www.spinics.net/lists/linux-media/msg69253.html Jacek Anaszewski (5): leds: Add sysfs and kernel internal API for flash LEDs leds: Improve and export led_update_brightness function leds: Add support for max77693 mfd flash cell DT: Add documentation for the mfd Maxim max77693 flash cell media: Add registration helpers for V4L2 flash sub-devices Documentation/devicetree/bindings/mfd/max77693.txt | 57 ++ drivers/leds/Kconfig | 18 + drivers/leds/Makefile |2 + drivers/leds/led-class.c | 42 +- drivers/leds/led-core.c| 16 + drivers/leds/led-flash.c | 627 drivers/leds/led-triggers.c| 16 +- drivers/leds/leds-max77693.c | 794 drivers/leds/leds.h|6 + drivers/media/v4l2-core/Kconfig| 10 + drivers/media/v4l2-core/Makefile |2 + drivers/media/v4l2-core/v4l2-flash.c | 393 ++ drivers/mfd/max77693.c |2 +- include/linux/leds.h | 60 +- include/linux/leds_flash.h | 252 +++ include/linux/mfd/max77693.h | 38 + include/media/v4l2-flash.h | 119 +++ 17 files changed, 2433 insertions(+), 21 deletions(-) create mode 100644
Business Proposal From Tokyo
April 19, 2014 Konnichiwa! It is with respect to directly write this proposal letter to you, informing you of a potential business proposal project that can be established from your country with your help, which will mutually be profitable to us having no risk involved. If you are agreeable to this business proposal, please indicate your interest by giving me a direct response email. Feel free to contact me via electronic mail or telephone for further discussion. I look forward to hearing from you positively on this proposal. Domo arigato ! Suki -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Apr 19 04:00:20 CEST 2014 git branch: test git hash: 701b57ee3387b8e3749845b02310b5625fbd8da0 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-11-g38d1124 host hardware: x86_64 host os:3.13-7.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0-11-g38d1124 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
