Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property
On 01/20/2015 06:40 PM, Pavel Machek wrote: On Tue 2015-01-20 11:29:16, Rob Herring wrote: On Tue, Jan 20, 2015 at 10:09 AM, Jacek Anaszewski wrote: On 01/16/2015 04:52 PM, Jacek Anaszewski wrote: On 01/16/2015 02:48 PM, Rob Herring wrote: [...] You may want to add something like led-output-cnt or led-driver-cnt in the parent so you know the max list size. Why should we need this? The number of current outputs exposed by the device is fixed and can be specified in a LED device bindings documentation. OK. The led-output-cnt property should be put in each sub-node, as the number of the current outputs each LED can be connected to is variable. Sorry, I meant this for the parent node meaning how many outputs the driver IC has. I did say maybe because you may always know this. It can make it easier to allocate memory for led-sources knowing the max size up front. Umm. Not sure if that kind of "help" should go to the device tree. Pavel I agree. I think that led-sources-cnt is redundant. A list property can be read using of_prop_next_u32 function. I missed that and thus proposed putting led-sources-cnt in each sub-node to be able to read led-sources list with of_property_read_u32_array. Effectively, I propose to avoid adding led-sources-cnt property. -- Best Regards, Jacek Anaszewski -- 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 05/15] media: blackfin: bfin_capture: improve queue_setup() callback
2014-12-20 18:47 GMT+08:00 Lad, Prabhakar :
> this patch improves the queue_setup() callback.
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/platform/blackfin/bfin_capture.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/blackfin/bfin_capture.c
> b/drivers/media/platform/blackfin/bfin_capture.c
> index 8bd94a1..76d42bb 100644
> --- a/drivers/media/platform/blackfin/bfin_capture.c
> +++ b/drivers/media/platform/blackfin/bfin_capture.c
> @@ -44,7 +44,6 @@
> #include
>
> #define CAPTURE_DRV_NAME"bfin_capture"
> -#define BCAP_MIN_NUM_BUF2
>
> struct bcap_format {
> char *desc;
> @@ -292,11 +291,14 @@ static int bcap_queue_setup(struct vb2_queue *vq,
> {
> struct bcap_device *bcap_dev = vb2_get_drv_priv(vq);
>
> - if (*nbuffers < BCAP_MIN_NUM_BUF)
> - *nbuffers = BCAP_MIN_NUM_BUF;
> + if (fmt && fmt->fmt.pix.sizeimage < bcap_dev->fmt.sizeimage)
> + return -EINVAL;
> +
> + if (vq->num_buffers + *nbuffers < 3)
> + *nbuffers = 3 - vq->num_buffers;
It seems it changes the minimum buffers from 2 to 3?
>
> *nplanes = 1;
> - sizes[0] = bcap_dev->fmt.sizeimage;
> + sizes[0] = fmt ? fmt->fmt.pix.sizeimage : bcap_dev->fmt.sizeimage;
> alloc_ctxs[0] = bcap_dev->alloc_ctx;
>
--
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 08/15] media: blackfin: bfin_capture: use vb2_ioctl_* helpers
2014-12-20 18:47 GMT+08:00 Lad, Prabhakar :
> this patch adds support to vb2_ioctl_* helpers.
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/platform/blackfin/bfin_capture.c | 107
> +
> 1 file changed, 22 insertions(+), 85 deletions(-)
>
> diff --git a/drivers/media/platform/blackfin/bfin_capture.c
> b/drivers/media/platform/blackfin/bfin_capture.c
> index 30f1fe0..80a0efc 100644
> --- a/drivers/media/platform/blackfin/bfin_capture.c
> +++ b/drivers/media/platform/blackfin/bfin_capture.c
> @@ -272,15 +272,28 @@ static int bcap_start_streaming(struct vb2_queue *vq,
> unsigned int count)
> struct ppi_if *ppi = bcap_dev->ppi;
> struct bcap_buffer *buf, *tmp;
> struct ppi_params params;
> + dma_addr_t addr;
> int ret;
>
> /* enable streamon on the sub device */
> ret = v4l2_subdev_call(bcap_dev->sd, video, s_stream, 1);
> if (ret && (ret != -ENOIOCTLCMD)) {
> v4l2_err(&bcap_dev->v4l2_dev, "stream on failed in subdev\n");
> + bcap_dev->cur_frm = NULL;
> goto err;
> }
>
> + /* get the next frame from the dma queue */
> + bcap_dev->cur_frm = list_entry(bcap_dev->dma_queue.next,
> + struct bcap_buffer, list);
> + /* remove buffer from the dma queue */
> + list_del_init(&bcap_dev->cur_frm->list);
> + addr = vb2_dma_contig_plane_dma_addr(&bcap_dev->cur_frm->vb, 0);
> + /* update DMA address */
> + ppi->ops->update_addr(ppi, (unsigned long)addr);
> + /* enable ppi */
> + ppi->ops->start(ppi);
> +
Absolutely wrong here. You can't start ppi before you set ppi params.
In fact vb2_streamon() is called before this in bcap_streamon().
--
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 08/15] media: blackfin: bfin_capture: use vb2_ioctl_* helpers
On Wed, Jan 21, 2015 at 10:55 AM, Scott Jiang
wrote:
> 2014-12-20 18:47 GMT+08:00 Lad, Prabhakar :
>> this patch adds support to vb2_ioctl_* helpers.
>>
>> Signed-off-by: Lad, Prabhakar
>> ---
>> drivers/media/platform/blackfin/bfin_capture.c | 107
>> +
>> 1 file changed, 22 insertions(+), 85 deletions(-)
>>
>> diff --git a/drivers/media/platform/blackfin/bfin_capture.c
>> b/drivers/media/platform/blackfin/bfin_capture.c
>> index 30f1fe0..80a0efc 100644
>> --- a/drivers/media/platform/blackfin/bfin_capture.c
>> +++ b/drivers/media/platform/blackfin/bfin_capture.c
>> @@ -272,15 +272,28 @@ static int bcap_start_streaming(struct vb2_queue *vq,
>> unsigned int count)
>> struct ppi_if *ppi = bcap_dev->ppi;
>> struct bcap_buffer *buf, *tmp;
>> struct ppi_params params;
>> + dma_addr_t addr;
>> int ret;
>>
>> /* enable streamon on the sub device */
>> ret = v4l2_subdev_call(bcap_dev->sd, video, s_stream, 1);
>> if (ret && (ret != -ENOIOCTLCMD)) {
>> v4l2_err(&bcap_dev->v4l2_dev, "stream on failed in
>> subdev\n");
>> + bcap_dev->cur_frm = NULL;
>> goto err;
>> }
>>
>> + /* get the next frame from the dma queue */
>> + bcap_dev->cur_frm = list_entry(bcap_dev->dma_queue.next,
>> + struct bcap_buffer, list);
>> + /* remove buffer from the dma queue */
>> + list_del_init(&bcap_dev->cur_frm->list);
>> + addr = vb2_dma_contig_plane_dma_addr(&bcap_dev->cur_frm->vb, 0);
>> + /* update DMA address */
>> + ppi->ops->update_addr(ppi, (unsigned long)addr);
>> + /* enable ppi */
>> + ppi->ops->start(ppi);
>> +
>
> Absolutely wrong here. You can't start ppi before you set ppi params.
> In fact vb2_streamon() is called before this in bcap_streamon().
Agreed need to move the ppi->ops->start(ppi); call after
ret = ppi->ops->set_params(ppi, ¶ms); that should fix it.
Thanks,
--Prabhakar Lad
--
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 05/15] media: blackfin: bfin_capture: improve queue_setup() callback
On Wed, Jan 21, 2015 at 10:01 AM, Scott Jiang
wrote:
> 2014-12-20 18:47 GMT+08:00 Lad, Prabhakar :
>> this patch improves the queue_setup() callback.
>>
>> Signed-off-by: Lad, Prabhakar
>> ---
>> drivers/media/platform/blackfin/bfin_capture.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/media/platform/blackfin/bfin_capture.c
>> b/drivers/media/platform/blackfin/bfin_capture.c
>> index 8bd94a1..76d42bb 100644
>> --- a/drivers/media/platform/blackfin/bfin_capture.c
>> +++ b/drivers/media/platform/blackfin/bfin_capture.c
>> @@ -44,7 +44,6 @@
>> #include
>>
>> #define CAPTURE_DRV_NAME"bfin_capture"
>> -#define BCAP_MIN_NUM_BUF2
>>
>> struct bcap_format {
>> char *desc;
>> @@ -292,11 +291,14 @@ static int bcap_queue_setup(struct vb2_queue *vq,
>> {
>> struct bcap_device *bcap_dev = vb2_get_drv_priv(vq);
>>
>> - if (*nbuffers < BCAP_MIN_NUM_BUF)
>> - *nbuffers = BCAP_MIN_NUM_BUF;
>> + if (fmt && fmt->fmt.pix.sizeimage < bcap_dev->fmt.sizeimage)
>> + return -EINVAL;
>> +
>> + if (vq->num_buffers + *nbuffers < 3)
>> + *nbuffers = 3 - vq->num_buffers;
>
> It seems it changes the minimum buffers from 2 to 3?
>
will replace it with,
if (vq->num_buffers + *nbuffers < 2)
*nbuffers = 2;
Thanks,
--Prabhakar Lad
--
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 00/15] media: blackfin: bfin_capture enhancements
Hi Scott, On Sat, Dec 20, 2014 at 10:47 AM, Lad, Prabhakar wrote: > Hi Scott, > > Although I was on holiday but couldn't resist myself from working, > since I was away from my hardware I had to choose a different one, > blackfin driver was lucky one. Since I don't have the blackfin > board I haven't tested them on the actual board, but just compile > tested, Can you please test it & ACK. > > Lad, Prabhakar (15): > media: blackfin: bfin_capture: drop buf_init() callback > media: blackfin: bfin_capture: release buffers in case > start_streaming() call back fails > media: blackfin: bfin_capture: set min_buffers_needed > media: blackfin: bfin_capture: improve buf_prepare() callback > media: blackfin: bfin_capture: improve queue_setup() callback > media: blackfin: bfin_capture: use vb2_fop_mmap/poll > media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release > media: blackfin: bfin_capture: use vb2_ioctl_* helpers > media: blackfin: bfin_capture: make sure all buffers are returned on > stop_streaming() callback > media: blackfin: bfin_capture: return -ENODATA for *std calls > media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls > media: blackfin: bfin_capture: add support for vidioc_create_bufs > media: blackfin: bfin_capture: add support for VB2_DMABUF > media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF > media: blackfin: bfin_capture: set v4l2 buffer sequence > > drivers/media/platform/blackfin/bfin_capture.c | 310 > - > 1 file changed, 98 insertions(+), 212 deletions(-) > If you are done with the review of all the patches,should I go ahead and post a v2 fixing the two issues which you pointed out ? Thanks, --Prabhakar Lad -- 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] add raw video support for Samsung SUR40 touchscreen
Hello everyone,
On 20.01.2015 14:06, Laurent Pinchart wrote:
> On Tuesday 20 January 2015 14:03:00 Hans Verkuil wrote:
>> On 01/20/15 13:59, Laurent Pinchart wrote:
>>> On Tuesday 20 January 2015 10:30:07 Hans Verkuil wrote:
I've CC-ed Laurent, I think he knows a lot more about this than I do.
Laurent, when does the USB core use DMA? What do you need to do on the
driver side to have USB use DMA when doing bulk transfers?
>>>
>>> How USB HCD drivers map buffers for DMA is HCD-specific, but all drivers
>>> exepct ehci-tegra, max3421-hcd and musb use the default implementation
>>> usb_hcd_map_urb_for_dma() (in drivers/usb/core/hcd.c).
>>>
>>> Unless the buffer has already been mapped by the USB driver (in which case
>>> the driver will have set the URB_NO_TRANSFER_DMA_MAP flag in
>>> urb->transfer_flags and initialized the urb->transfer_dma field), the
>>> function will use dma_map_sg(), dma_map_page() or dma_map_single()
>>> depending on the buffer type (controlled through urb->sg and
>>> urb->num_sgs). DMA will thus always be used *expect* if the platform uses
>>> bounce buffers when the buffer can't be mapped directly for DMA.
>>
>> So we can safely use videobuf2-vmalloc, right?
>
> That depends on the platform and whether it can DMA to vmalloc'ed memory :-)
> To be totally safe I think vb2-dma-sg would be better, but I'm not sure it's
> worth the trouble. uvcvideo uses vb2-vmalloc as it performs a memcpy anyway.
The SUR40 sends raw video data without any headers over the bulk
endpoint in blocks of 16k, so I'm assuming that in this specific case,
vb2-dma-sg would be the most efficient choice?
On that note, I've seen that vb2_dma_sg_{init|cleanup}_ctx will appear
only in 3.19. If I want to maintain a backwards-compatible version for
older kernels, what do I use in that case?
Best, Florian
--
SENT FROM MY DEC VT50 TERMINAL
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
On 01/21/15 14:28, Florian Echtler wrote:
> Hello everyone,
>
> On 20.01.2015 14:06, Laurent Pinchart wrote:
>> On Tuesday 20 January 2015 14:03:00 Hans Verkuil wrote:
>>> On 01/20/15 13:59, Laurent Pinchart wrote:
On Tuesday 20 January 2015 10:30:07 Hans Verkuil wrote:
> I've CC-ed Laurent, I think he knows a lot more about this than I do.
>
> Laurent, when does the USB core use DMA? What do you need to do on the
> driver side to have USB use DMA when doing bulk transfers?
How USB HCD drivers map buffers for DMA is HCD-specific, but all drivers
exepct ehci-tegra, max3421-hcd and musb use the default implementation
usb_hcd_map_urb_for_dma() (in drivers/usb/core/hcd.c).
Unless the buffer has already been mapped by the USB driver (in which case
the driver will have set the URB_NO_TRANSFER_DMA_MAP flag in
urb->transfer_flags and initialized the urb->transfer_dma field), the
function will use dma_map_sg(), dma_map_page() or dma_map_single()
depending on the buffer type (controlled through urb->sg and
urb->num_sgs). DMA will thus always be used *expect* if the platform uses
bounce buffers when the buffer can't be mapped directly for DMA.
>>>
>>> So we can safely use videobuf2-vmalloc, right?
>>
>> That depends on the platform and whether it can DMA to vmalloc'ed memory :-)
>> To be totally safe I think vb2-dma-sg would be better, but I'm not sure it's
>> worth the trouble. uvcvideo uses vb2-vmalloc as it performs a memcpy anyway.
>
> The SUR40 sends raw video data without any headers over the bulk
> endpoint in blocks of 16k, so I'm assuming that in this specific case,
> vb2-dma-sg would be the most efficient choice?
>
> On that note, I've seen that vb2_dma_sg_{init|cleanup}_ctx will appear
> only in 3.19. If I want to maintain a backwards-compatible version for
> older kernels, what do I use in that case?
Easiest would actually be to copy all the videobuf2 sources and headers
to that older kernel.
Obviously, for upstreaming you should always use the latest APIs and
never use backwards-compatible constructs.
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: [PATCH/RFC v10 17/19] DT: Add documentation for exynos4-is 'flashes' property
Hi, On 09/01/15 16:23, Jacek Anaszewski wrote: > This patch adds a description of 'flashes' property > to the samsung-fimc.txt. > > Signed-off-by: Jacek Anaszewski > Acked-by: Kyungmin Park > --- > .../devicetree/bindings/media/samsung-fimc.txt |7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt > b/Documentation/devicetree/bindings/media/samsung-fimc.txt > index 922d6f8..22a6b2f 100644 > --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt > +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt > @@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera > port A must be activated > and the port B deactivated and for the state "active-b" it should be the > other > way around. > > +Optional properties: > + > +- flashes - Array of phandles to flash LED devices, or their sub-nodes > + representing sub-leds. > + (see Documentation/devicetree/bindings/leds/common.txt) How about renaming this to "illuminators" or something else more generic? The "torch" LED (for video recording illumination?) is not really a flash. > + > The 'camera' node must include at least one 'fimc' child node. > > > @@ -166,6 +172,7 @@ Example: > clock-output-names = "cam_a_clkout", "cam_b_clkout"; > pinctrl-names = "default"; > pinctrl-0 = <&cam_port_a_clk_active>; > + flashes = <&camera_flash>, <&system_torch>; > status = "okay"; > #address-cells = <1>; > #size-cells = <1>; -- Thanks, Sylwester -- 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: [RFCv2 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On Wed, Jan 21, 2015 at 09:46:47AM +0530, Sumit Semwal wrote:
> +static int calc_constraints(struct device *dev,
> + struct dma_buf_constraints *calc_cons)
> +{
> + struct dma_buf_constraints cons = *calc_cons;
> +
> + cons.dma_mask &= dma_get_mask(dev);
I don't think this makes much sense when you consider that the DMA
infrastructure supports buses with offsets. The DMA mask is th
upper limit of the _bus_ specific address, it is not a mask per-se.
What this means is that &= is not the right operation. Moreover,
simply comparing masks which could be from devices on unrelated
buses doesn't make sense either.
However, that said, I don't have an answer for what you want to
achieve here.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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: [RFCv2 1/2] device: add dma_params->max_segment_count
Hi Sumit,
On 21/01/15 04:16, Sumit Semwal wrote:
From: Rob Clark
For devices which have constraints about maximum number of segments in
an sglist. For example, a device which could only deal with contiguous
buffers would set max_segment_count to 1.
The initial motivation is for devices sharing buffers via dma-buf,
to allow the buffer exporter to know the constraints of other
devices which have attached to the buffer. The dma_mask and fields
in 'struct device_dma_parameters' tell the exporter everything else
that is needed, except whether the importer has constraints about
maximum number of segments.
Signed-off-by: Rob Clark
[sumits: Minor updates wrt comments on the first version]
Signed-off-by: Sumit Semwal
---
include/linux/device.h | 1 +
include/linux/dma-mapping.h | 19 +++
2 files changed, 20 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index fb50673..a32f9b6 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -647,6 +647,7 @@ struct device_dma_parameters {
* sg limitations.
*/
unsigned int max_segment_size;
+ unsigned int max_segment_count;/* INT_MAX for unlimited */
unsigned long segment_boundary_mask;
};
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index c3007cb..38e2835 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -154,6 +154,25 @@ static inline unsigned int dma_set_max_seg_size(struct
device *dev,
return -EIO;
}
+#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
+
+static inline unsigned int dma_get_max_seg_count(struct device *dev)
+{
+ return dev->dma_parms ?
+ dev->dma_parms->max_segment_count :
+ DMA_SEGMENTS_MAX_SEG_COUNT;
+}
I know this copies the style of the existing code, but unfortunately it
also copies the subtle brokenness. Plenty of drivers seem to set up a
dma_parms struct just for max_segment_size, thus chances are you'll come
across a max_segment_count of 0 sooner or later. How badly is that going
to break things? I posted a fix recently[1] having hit this problem with
segment_boundary_mask in IOMMU code.
+
+static inline int dma_set_max_seg_count(struct device *dev,
+ unsigned int count)
+{
+ if (dev->dma_parms) {
+ dev->dma_parms->max_segment_count = count;
+ return 0;
+ } else
This "else" is just as unnecessary as the other two I've taken out ;)
Robin.
[1]:http://article.gmane.org/gmane.linux.kernel.iommu/8175/
+ return -EIO;
+}
+
static inline unsigned long dma_get_seg_boundary(struct device *dev)
{
return dev->dma_parms ?
--
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: [GIT FIXES FOR v3.19] Fixes for 3.19
Em Fri, 16 Jan 2015 13:23:35 +0100 Hans Verkuil escreveu: > The following changes since commit 99f3cd52aee21091ce62442285a68873e3be833f: > > [media] vb2-vmalloc: Protect DMA-specific code by #ifdef CONFIG_HAS_DMA > (2014-12-23 16:28:09 -0200) > > are available in the git repository at: > > git://linuxtv.org/hverkuil/media_tree.git for-v3.19a > > for you to fetch changes up to f490fe1a4b4cd0a6454db02e8459d30a2ff02c49: > > Fix Mygica T230 support (2015-01-16 13:07:28 +0100) > > > Jim Davis (1): > media: tlg2300: disable building the driver This one is superseded by: https://patchwork.linuxtv.org/patch/27671/ Instead of marking as Broken, the right fix is to preserve the media USB dependency, so I'm replacing this patch by 27671. > > Jonathan McDowell (1): > Fix Mygica T230 support > > Matthias Schwarzott (1): > cx23885: Split Hauppauge WinTV Starburst from HVR4400 card entry The other two patches are ok. > > drivers/media/pci/cx23885/cx23885-cards.c | 23 +-- > drivers/media/pci/cx23885/cx23885-dvb.c | 11 +++ > drivers/media/pci/cx23885/cx23885.h | 1 + > drivers/media/usb/dvb-usb/cxusb.c | 2 +- > drivers/staging/media/tlg2300/Kconfig | 1 + > 5 files changed, 31 insertions(+), 7 deletions(-) > -- > 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 -- 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] v4l: vsp1: bru: Fix minimum input pixel size
According to the spec, the minimum input pixel size for BRU is 1px, not 4px. Signed-off-by: Takanari Hayama --- drivers/media/platform/vsp1/vsp1_bru.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/vsp1/vsp1_bru.c b/drivers/media/platform/vsp1/vsp1_bru.c index b21f381..401e2b7 100644 --- a/drivers/media/platform/vsp1/vsp1_bru.c +++ b/drivers/media/platform/vsp1/vsp1_bru.c @@ -20,7 +20,7 @@ #include "vsp1_bru.h" #include "vsp1_rwpf.h" -#define BRU_MIN_SIZE 4U +#define BRU_MIN_SIZE 1U #define BRU_MAX_SIZE 8190U /* - -- 1.8.0 -- 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] [media] v4l: vsp1: bru: Fix minimum input pixel size
Hi Hayama-san, Thank you for the patch. On Thursday 22 January 2015 09:14:23 Takanari Hayama wrote: > According to the spec, the minimum input pixel size for BRU is 1px, > not 4px. > > Signed-off-by: Takanari Hayama Acked-by: Laurent Pinchart > --- > drivers/media/platform/vsp1/vsp1_bru.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/platform/vsp1/vsp1_bru.c > b/drivers/media/platform/vsp1/vsp1_bru.c index b21f381..401e2b7 100644 > --- a/drivers/media/platform/vsp1/vsp1_bru.c > +++ b/drivers/media/platform/vsp1/vsp1_bru.c > @@ -20,7 +20,7 @@ > #include "vsp1_bru.h" > #include "vsp1_rwpf.h" > > -#define BRU_MIN_SIZE 4U > +#define BRU_MIN_SIZE 1U > #define BRU_MAX_SIZE 8190U > > /* -- Regards, Laurent Pinchart -- 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
Hauppauge WinTV HVR-2255 dvb tuner support?
Hi all I have a hvr-2255 dvb tuner, but to my knowledge there is no support for this newer hardware available on linux. If anyone is interested, I've posted bug reports to my distribution's BTS as well as the upstream linux kernel bug tracker. The links below contain some additional information. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775712 https://bugzilla.kernel.org/show_bug.cgi?id=91671 -- 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: Working on Avermedia Duet A188 (saa716x and lgdt3304)
Tim hotmail.com> writes: > > I'd like to try this again, as my last working tuner died this week. I've had > this card sitting around for over > > a year hoping for support, but it doesn't look like anyone else is working > > on > it. > > > > What kind of information is needed to make the card work? Will I need to > > find > firmware somewhere? It looks > > like the basics are there with Manu's work on the SAA716x and Jared and > Michael's work on the LGDT3304, but > > how do I customize these to work with the A188? > > > > Any help would be appreciated, thanks! > > > > Oblib > > > > > > > > I have been playing with this aswell.. I haven't done C since college. > I hope someone could help us with this.. > > I have done some leg work here.. > > 1) I have contacted Avermedia to see if they will release the source to the > windows drivers.. Can't hurt to ask.. waiting their response.. it had to be > referred to R&D department. So it Wasnt No.. > > 2) The actual components on the board are > 2x TDA18271hdc2 in what appears to be a master slave setup(maybe.. Only one > coax > input) > 2x LGDT3304 > 1x 60E > > 3) I have pulled this repository and worked from there.. > http://linuxtv.org/hg/~endriss/mirror-saa716x/ > I have edited the SAA71x budget Driver so that it recognizes the card and > the cards rom tells us this.. Hey Tim, Had you made any more progress on this driver? Did you ever get anything more working? -Nate -- 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 v4 08/10] v4l: xilinx: Add Xilinx Video IP core
Hi Hans and Chris, On Monday 01 December 2014 22:13:38 Laurent Pinchart wrote: > Xilinx platforms have no hardwired video capture or video processing > interface. Users create capture and memory to memory processing > pipelines in the FPGA fabric to suit their particular needs, by > instantiating video IP cores from a large library. > > The Xilinx Video IP core is a framework that models a video pipeline > described in the device tree and expose the pipeline to userspace > through the media controller and V4L2 APIs. > > Signed-off-by: Laurent Pinchart > Signed-off-by: Hyun Kwon > Signed-off-by: Radhey Shyam Pandey > Signed-off-by: Michal Simek [snip] > diff --git a/Documentation/devicetree/bindings/media/xilinx/video.txt > b/Documentation/devicetree/bindings/media/xilinx/video.txt new file mode > 100644 > index 000..15720e4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/xilinx/video.txt > @@ -0,0 +1,52 @@ > +DT bindings for Xilinx video IP cores > +- > + > +Xilinx video IP cores process video streams by acting as video sinks and/or > +sources. They are connected by links through their input and output ports, > +creating a video pipeline. > + > +Each video IP core is represented by an AMBA bus child node in the device > +tree using bindings documented in this directory. Connections between the > IP > +cores are represented as defined in ../video-interfaces.txt. > + > +The whole pipeline is represented by an AMBA bus child node in the device > +tree using bindings documented in ./xlnx,video.txt. > + > +Common properties > +- > + > +The following properties are common to all Xilinx video IP cores. > + > +- xlnx,video-format: This property represents a video format transmitted on > an > + AXI bus between video IP cores. How the format relates to the IP core is > + decribed in the IP core bindings documentation. The following formats are > + supported. > + > + rbg > + xrgb > + yuv422 > + yuv444 > + rggb > + grbg > + gbrg > + bggr > + > +- xlnx,video-width: This property qualifies the video format with the > sample > + width expressed as a number of bits per pixel component. All components > must > + use the same width. Hans, last time we've discussed this on IRC you were not happy with the format description used in these DT bindings. Your argument was, if I remember correctly, that as the formats map directly to media bus codes, it would be better to use the media bus codes (or a string representation of them) in the bindings instead of creating a new format description. Is that correct ? Chris, what's your opinion on that ? The RGB and YUV formats in the table below describe the hardware and come from table 1-4 on page 8 of http://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/v1_0/ug934_axi_videoIP.pdf. The Bayer formats are not standardized in the document, and I don't think we need them at the moment. > +The following table lists the supported formats and widths combinations, > along > +with the corresponding media bus pixel code. > + > ++---+-- > +Format | Width | Media bus code > ++---+-- > +rbg | 8 | V4L2_MBUS_FMT_RBG888_1X24 > +xrgb | 8 | V4L2_MBUS_FMT_RGB888_1X32_PADHI > +yuv422 | 8 | V4L2_MBUS_FMT_UYVY8_1X16 > +yuv444 | 8 | V4L2_MBUS_FMT_VUY888_1X24 > +rggb | 8 | V4L2_MBUS_FMT_SRGGB8_1X8 > +grbg | 8 | V4L2_MBUS_FMT_SGRBG8_1X8 > +gbrg | 8 | V4L2_MBUS_FMT_SGBRG8_1X8 > +bggr | 8 | V4L2_MBUS_FMT_SBGGR8_1X8 > ++---+-- > diff --git > a/Documentation/devicetree/bindings/media/xilinx/xlnx,video.txt > b/Documentation/devicetree/bindings/media/xilinx/xlnx,video.txt new file > mode 100644 > index 000..5a02270 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,video.txt > @@ -0,0 +1,55 @@ > +Xilinx Video IP Pipeline (VIPP) > +--- > + > +General concept > +--- > + > +Xilinx video IP pipeline processes video streams through one or more Xilinx > +video IP cores. Each video IP core is represented as documented in > video.txt > +and IP core specific documentation, xlnx,v-*.txt, in this directory. The DT > +node of the VIPP represents as a top level node of the pipeline and defines > +mappings between DMAs and the video IP cores. > + > +Required properties: > + > +- compatible: Must be "xlnx,video". > + > +- dmas, dma-names: List of one DMA specifier and identifier string (as > defined > + in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port > + requires a DMA channel with the identifier string set to "port" followed > by > + the port index. > + > +- ports: Vide
cron job: media_tree daily build: ERRORS
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: Thu Jan 22 04:00:18 CET 2015 git branch: test git hash: 1fc77d013ba85a29e2edfaba02fd21e8c8187fae gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-1.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.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK 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.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17.8-i686: OK linux-3.18-i686: OK linux-3.19-rc4-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK 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.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18-x86_64: OK linux-3.19-rc4-x86_64: OK apps: OK spec-git: OK sparse: ERRORS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
Re: [RFCv2 1/2] device: add dma_params->max_segment_count
Hi Robin!
On 22 January 2015 at 00:26, Robin Murphy wrote:
> Hi Sumit,
>
>
> On 21/01/15 04:16, Sumit Semwal wrote:
>>
>> From: Rob Clark
>>
>> For devices which have constraints about maximum number of segments in
>> an sglist. For example, a device which could only deal with contiguous
>> buffers would set max_segment_count to 1.
>>
>> The initial motivation is for devices sharing buffers via dma-buf,
>> to allow the buffer exporter to know the constraints of other
>> devices which have attached to the buffer. The dma_mask and fields
>> in 'struct device_dma_parameters' tell the exporter everything else
>> that is needed, except whether the importer has constraints about
>> maximum number of segments.
>>
>> Signed-off-by: Rob Clark
>> [sumits: Minor updates wrt comments on the first version]
>> Signed-off-by: Sumit Semwal
>> ---
>> include/linux/device.h | 1 +
>> include/linux/dma-mapping.h | 19 +++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/include/linux/device.h b/include/linux/device.h
>> index fb50673..a32f9b6 100644
>> --- a/include/linux/device.h
>> +++ b/include/linux/device.h
>> @@ -647,6 +647,7 @@ struct device_dma_parameters {
>> * sg limitations.
>> */
>> unsigned int max_segment_size;
>> + unsigned int max_segment_count;/* INT_MAX for unlimited */
>> unsigned long segment_boundary_mask;
>> };
>>
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index c3007cb..38e2835 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -154,6 +154,25 @@ static inline unsigned int
>> dma_set_max_seg_size(struct device *dev,
>> return -EIO;
>> }
>>
>> +#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
>> +
>> +static inline unsigned int dma_get_max_seg_count(struct device *dev)
>> +{
>> + return dev->dma_parms ?
>> + dev->dma_parms->max_segment_count :
>> + DMA_SEGMENTS_MAX_SEG_COUNT;
>> +}
>
>
> I know this copies the style of the existing code, but unfortunately it also
> copies the subtle brokenness. Plenty of drivers seem to set up a dma_parms
> struct just for max_segment_size, thus chances are you'll come across a
> max_segment_count of 0 sooner or later. How badly is that going to break
> things? I posted a fix recently[1] having hit this problem with
> segment_boundary_mask in IOMMU code.
>
Thanks very much for reviewing this code; and apologies for missing
your patch that you mentioned here; sure, I will update my patch
accordingly as well.
>> +
>> +static inline int dma_set_max_seg_count(struct device *dev,
>> + unsigned int count)
>> +{
>> + if (dev->dma_parms) {
>> + dev->dma_parms->max_segment_count = count;
>> + return 0;
>> + } else
>
>
> This "else" is just as unnecessary as the other two I've taken out ;)
>
>
> Robin.
>
> [1]:http://article.gmane.org/gmane.linux.kernel.iommu/8175/
>
>
>> + return -EIO;
>> +}
>> +
>> static inline unsigned long dma_get_seg_boundary(struct device *dev)
>> {
>> return dev->dma_parms ?
>>
>
>
BR,
Sumit.
--
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 00/15] media: blackfin: bfin_capture enhancements
Hi Lad, >> >> Although I was on holiday but couldn't resist myself from working, >> since I was away from my hardware I had to choose a different one, >> blackfin driver was lucky one. Since I don't have the blackfin >> board I haven't tested them on the actual board, but just compile >> tested, Can you please test it & ACK. >> >> Lad, Prabhakar (15): >> media: blackfin: bfin_capture: drop buf_init() callback >> media: blackfin: bfin_capture: release buffers in case >> start_streaming() call back fails >> media: blackfin: bfin_capture: set min_buffers_needed >> media: blackfin: bfin_capture: improve buf_prepare() callback >> media: blackfin: bfin_capture: improve queue_setup() callback >> media: blackfin: bfin_capture: use vb2_fop_mmap/poll >> media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release >> media: blackfin: bfin_capture: use vb2_ioctl_* helpers >> media: blackfin: bfin_capture: make sure all buffers are returned on >> stop_streaming() callback >> media: blackfin: bfin_capture: return -ENODATA for *std calls >> media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls >> media: blackfin: bfin_capture: add support for vidioc_create_bufs >> media: blackfin: bfin_capture: add support for VB2_DMABUF >> media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF >> media: blackfin: bfin_capture: set v4l2 buffer sequence >> >> drivers/media/platform/blackfin/bfin_capture.c | 310 >> - >> 1 file changed, 98 insertions(+), 212 deletions(-) >> > If you are done with the review of all the patches,should I go ahead > and post a v2 fixing the two issues which you pointed out ? > Yes, I have reviewed and tested other patches. Thanks, Scott -- 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] reservation: Remove shadowing local variable 'ret'
From: Michel Dänzer
It was causing the return value of fence_is_signaled to be ignored, making
reservation objects signal too early.
Cc: sta...@vger.kernel.org
Reviewed-by: Maarten Lankhorst
Reviewed-by: Alex Deucher
Signed-off-by: Michel Dänzer
---
drivers/dma-buf/reservation.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 3c97c8f..8a37af9 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -402,8 +402,6 @@ reservation_object_test_signaled_single(struct fence
*passed_fence)
int ret = 1;
if (!test_bit(FENCE_FLAG_SIGNALED_BIT, &lfence->flags)) {
- int ret;
-
fence = fence_get_rcu(lfence);
if (!fence)
return -1;
--
2.1.4
--
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
