[PATCH 1/3] media: rc: nuvoton: remove usage of b_idx in nvt_get_rx_ir_data
The call to nvt_get_rx_ir_data and nvt_process_rx_ir_data from
the ISR is protected with spinlock nvt->lock. Therefore it's
guaranteed that nvt->pkts is 0 when entering nvt_get_rx_ir_data
(as nvt->pkts is set to 0 at the end of nvt_process_rx_ir_data).
Having said that we can remove b_idx.
Signed-off-by: Heiner Kallweit
---
drivers/media/rc/nuvoton-cir.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index 0c69536..e4158a9 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -802,7 +802,6 @@ static void nvt_handle_rx_fifo_overrun(struct nvt_dev *nvt)
static void nvt_get_rx_ir_data(struct nvt_dev *nvt)
{
u8 fifocount, val;
- unsigned int b_idx;
int i;
/* Get count of how many bytes to read from RX FIFO */
@@ -810,21 +809,13 @@ static void nvt_get_rx_ir_data(struct nvt_dev *nvt)
nvt_dbg("attempting to fetch %u bytes from hw rx fifo", fifocount);
- b_idx = nvt->pkts;
-
- /* This should never happen, but lets check anyway... */
- if (b_idx + fifocount > RX_BUF_LEN) {
- nvt_process_rx_ir_data(nvt);
- b_idx = 0;
- }
-
/* Read fifocount bytes from CIR Sample RX FIFO register */
for (i = 0; i < fifocount; i++) {
val = nvt_cir_reg_read(nvt, CIR_SRXFIFO);
- nvt->buf[b_idx + i] = val;
+ nvt->buf[i] = val;
}
- nvt->pkts += fifocount;
+ nvt->pkts = fifocount;
nvt_dbg("%s: pkts now %d", __func__, nvt->pkts);
nvt_process_rx_ir_data(nvt);
--
2.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 v7 1/2] [media] atmel-isc: add the Image Sensor Controller code
On 8/1/2016 17:47, Hans Verkuil wrote:
Hi Songjun,
Some more comments below. Except for one in the open/release functions
it's all small things.
On 07/29/2016 09:54 AM, Songjun Wu wrote:
Add driver for the Image Sensor Controller. It manages
incoming data from a parallel based CMOS/CCD sensor.
It has an internal image processor, also integrates a
triple channel direct memory access controller master
interface.
Signed-off-by: Songjun Wu
---
Changes in v7:
- Add enum_framesizes and enum_frameintervals.
- Call s_stream(0) when stream start fail.
- Fill the device_caps field of struct video_device
with V4L2_CAP_STREAMING and V4L2_CAP_VIDEO_CAPTURE.
- Initialize the dev of struct vb2_queue.
- Set field to FIELD_NONE if the pix field is not supported.
- Return the result directly when call g/s_parm of subdev.
Changes in v6: None
Changes in v5:
- Modify the macro definition and the related code.
Changes in v4:
- Modify the isc clock code since the dt is changed.
Changes in v3:
- Add pm runtime feature.
- Modify the isc clock code since the dt is changed.
Changes in v2:
- Add "depends on COMMON_CLK" and "VIDEO_V4L2_SUBDEV_API"
in Kconfig file.
- Correct typos and coding style according to Laurent's remarks
- Delete the loop while in 'isc_clk_enable' function.
- Replace 'hsync_active', 'vsync_active' and 'pclk_sample'
with 'pfe_cfg0' in struct isc_subdev_entity.
- Add the code to support VIDIOC_CREATE_BUFS in
'isc_queue_setup' function.
- Invoke isc_config to configure register in
'isc_start_streaming' function.
- Add the struct completion 'comp' to synchronize with
the frame end interrupt in 'isc_stop_streaming' function.
- Check the return value of the clk_prepare_enable
in 'isc_open' function.
- Set the default format in 'isc_open' function.
- Add an exit condition in the loop while in 'isc_config'.
- Delete the hardware setup operation in 'isc_set_format'.
- Refuse format modification during streaming
in 'isc_s_fmt_vid_cap' function.
- Invoke v4l2_subdev_alloc_pad_config to allocate and
initialize the pad config in 'isc_async_complete' function.
- Remove the '.owner = THIS_MODULE,' in atmel_isc_driver.
- Replace the module_platform_driver_probe() with
module_platform_driver().
drivers/media/platform/Kconfig|1 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/atmel/Kconfig |9 +
drivers/media/platform/atmel/Makefile |1 +
drivers/media/platform/atmel/atmel-isc-regs.h | 165 +++
drivers/media/platform/atmel/atmel-isc.c | 1611 +
6 files changed, 1789 insertions(+)
create mode 100644 drivers/media/platform/atmel/Kconfig
create mode 100644 drivers/media/platform/atmel/Makefile
create mode 100644 drivers/media/platform/atmel/atmel-isc-regs.h
create mode 100644 drivers/media/platform/atmel/atmel-isc.c
diff --git a/drivers/media/platform/atmel/atmel-isc.c
b/drivers/media/platform/atmel/atmel-isc.c
new file mode 100644
index 000..f2ef664
--- /dev/null
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -0,0 +1,1611 @@
+static unsigned int sensor_preferred = 1;
+module_param(sensor_preferred, uint, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(sensor_preferred,
+"Sensor is preferred to output the specified format (1-on 0-off)
default 1");
I have no idea what this means. Can you elaborate? Why would you want to set
this to 0?
ISC can convert the raw format to the other format, e.g. YUYV.
If we want to output YUYV format, there are two choices, one is the
sensor output YUYV format, ISC bypass the data to the memory, the other
is the sensor output raw format, ISC convert raw format to YUYV.
So I provide a module parameter to user to select.
I prefer to select the sensor to output the specified format, then I set
this parameter to '1', not '0'.
+static inline bool sensor_is_preferred(const struct isc_format *isc_fmt)
+{
+ if ((sensor_preferred && isc_fmt->sd_support) ||
+ !isc_fmt->isc_support)
I'd just do:
return (sensor_preferred && isc_fmt->sd_support) ||
!isc_fmt->isc_support;
Accept, thank you.
+ return true;
+ else
+ return false;
+}
+
+static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
+ struct isc_format **current_fmt, u32 *code)
+{
+ struct isc_format *isc_fmt;
+ struct v4l2_pix_format *pixfmt = &f->fmt.pix;
+ struct v4l2_subdev_format format = {
+ .which = V4L2_SUBDEV_FORMAT_TRY,
+ };
+ u32 mbus_code;
+ int ret;
+
+ if (f->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ isc_fmt = find_format_by_fourcc(isc, pixfmt->pixelformat);
+ if (!isc_fmt) {
+ v4l2_warn(&isc->v4l2_dev, "Format 0x%x not found\n",
+ pixfmt->pixelformat);
+ isc_fmt = isc->user_formats[isc->num_user_
Re: [PATCH v2 2/4] dt-bindings: Add a binding for Mediatek MDP
On Thu, 2016-07-28 at 10:55 -0500, Rob Herring wrote:
> On Tue, Jul 26, 2016 at 8:44 PM, Minghsiu Tsai
> wrote:
> > On Tue, 2016-07-26 at 13:54 -0500, Rob Herring wrote:
> >> On Fri, Jul 22, 2016 at 04:33:01PM +0800, Minghsiu Tsai wrote:
> >> > Add a DT binding documentation of MDP for the MT8173 SoC
> >> > from Mediatek
> >> >
> >> > Signed-off-by: Minghsiu Tsai
> >> > ---
> >> > .../devicetree/bindings/media/mediatek-mdp.txt | 96
> >> >
> >> > 1 file changed, 96 insertions(+)
> >> > create mode 100644
> >> > Documentation/devicetree/bindings/media/mediatek-mdp.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> >> > b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> >> > new file mode 100644
> >> > index 000..2dad031
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> >> > @@ -0,0 +1,96 @@
> >> > +* Mediatek Media Data Path
> >> > +
> >> > +Media Data Path is used for scaling and color space conversion.
> >> > +
> >> > +Required properties (all function blocks):
> >> > +- compatible: "mediatek,-mdp"
> >>
> >> What is this, ...
> >>
> >
> > It is used to match platform driver.
>
> Would structuring things like this work instead:
>
> {
> compatible = "mediatek,-mdp";
> ranges = ...;
> {
> compatible = "mediatek,-mdp-rdma";
> ...
> };
> {
> compatible = "mediatek,-mdp-wdma";
> ...
> };
> ...
> };
>
I am trying to modify it as structured node. But mdp failed to convert
image. Under debugging.
> >
> >
> >> > +"mediatek,-mdp-", one of
> >>
> >> and this?
> >>
> >
> > It is string format of HW block. could be "mt8173", and
> > are "rdma", "rsz", "wdma", and "wrot".
> >
> >
> >> > +"mediatek,-mdp-rdma" - read DMA
> >> > +"mediatek,-mdp-rsz" - resizer
> >> > +"mediatek,-mdp-wdma" - write DMA
> >> > +"mediatek,-mdp-wrot" - write DMA with rotation
> >>
> >> List what are valid values of .
> >>
> >
> > - mt8173. There should be other chip added in future.
> > I will change the property as blow:
> >
> > - compatible: "mediatek,-mdp"
> > Should be one of
> > "mediatek,-mdp-rdma" - read DMA
> > "mediatek,-mdp-rsz" - resizer
> > "mediatek,-mdp-wdma" - write DMA
> > "mediatek,-mdp-wrot" - write DMA with rotation
> > - could be 8173
> >
> >
> > If don't need , I also can change it as below. It is more clear.
>
> Up to you. Depends on how many different chips you will have.
>
I will replace "" with "mt8173"
> > - compatible: "mediatek,mt8173-mdp"
> > Should be one of
> > "mediatek,mt8173-mdp-rdma" - read DMA
> > "mediatek,mt8173-mdp-rsz" - resizer
> > "mediatek,mt8173-mdp-wdma" - write DMA
> > "mediatek,mt8173-mdp-wrot" - write DMA with rotation
> >
> >
> >> > +- reg: Physical base address and length of the function block register
> >> > space
> >> > +- clocks: device clocks
> >> > +- power-domains: a phandle to the power domain.
> >> > +- mediatek,vpu: the node of video processor unit
> >> > +
> >> > +Required properties (DMA function blocks):
> >> > +- compatible: Should be one of
> >> > +"mediatek,-mdp-rdma"
> >> > +"mediatek,-mdp-wdma"
> >> > +"mediatek,-mdp-wrot"
> >> > +- iommus: should point to the respective IOMMU block with master port as
> >> > + argument, see
> >> > Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> >> > + for details.
> >> > +- mediatek,larb: must contain the local arbiters in the current Socs.
> >>
> >> It is still not clear which properties apply to which compatible
> >> strings.
> >>
> >
> > I found out the document for larb.
> > I will change the property as below:
> >
> > - mediatek,larb: must contain the local arbiters in the current Socs,
> > see
> > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> > for details.
>
> That's good, but not what I meant. You still have properties which
> only apply to certain blocks, but are listed for all blocks like
> mediatek,vpu for example.
>
> Rob
I find out other properties' document.
- clocks: device clocks, see
Documentation/devicetree/bindings/clock/clock-bindings.txt for
details.
- power-domains: a phandle to the power domain, see
Documentation/devicetree/bindings/power/power_domain.txt for details.
- mediatek,vpu: the node of video processor unit, see
Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
--
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 2/3] media: rc: nuvoton: remove unneeded call to ir_raw_event_handle
ir_raw_event_handle is called anyway after the hw fifo content stored
in nvt->buf[] has been written to the kfifo. There is not really a
benefit in the potential additional call to ir_raw_event_handle
whilst nvt->buf[] is being processed.
Getting rid of this additional call allows to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/media/rc/nuvoton-cir.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index e4158a9..fc462f6 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -769,21 +769,11 @@ static void nvt_process_rx_ir_data(struct nvt_dev *nvt)
rawir.pulse ? "pulse" : "space", rawir.duration);
ir_raw_event_store_with_filter(nvt->rdev, &rawir);
-
- /*
-* BUF_PULSE_BIT indicates end of IR data, BUF_REPEAT_BYTE
-* indicates end of IR signal, but new data incoming. In both
-* cases, it means we're ready to call ir_raw_event_handle
-*/
- if ((sample == BUF_PULSE_BIT) && (i + 1 < nvt->pkts)) {
- nvt_dbg("Calling ir_raw_event_handle (signal end)\n");
- ir_raw_event_handle(nvt->rdev);
- }
}
nvt->pkts = 0;
- nvt_dbg("Calling ir_raw_event_handle (buffer empty)\n");
+ nvt_dbg("Calling ir_raw_event_handle\n");
ir_raw_event_handle(nvt->rdev);
nvt_dbg_verbose("%s done", __func__);
--
2.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: rc: refactor raw handler kthread
I think we can get rid of the spinlock protecting the kthread from being
interrupted by a wakeup in certain parts.
Even with the current implementation of the kthread the only lost wakeup
scenario could happen if the wakeup occurs between the kfifo_len check
and setting the state to TASK_INTERRUPTIBLE.
In the changed version we could lose a wakeup if it occurs between
processing the fifo content and setting the state to TASK_INTERRUPTIBLE.
This scenario is covered by an additional check for available events in
the fifo and setting the state to TASK_RUNNING in this case.
In addition the changed version flushes the kfifo before ending
when the kthread is stopped.
With this patch we gain:
- Get rid of the spinlock
- Simplify code
- Don't grep / release the mutex for each individual event but just once
for the complete fifo content. This reduces overhead if a driver e.g.
triggers processing after writing the content of a hw fifo to the kfifo.
Signed-off-by: Heiner Kallweit
---
drivers/media/rc/rc-core-priv.h | 2 --
drivers/media/rc/rc-ir-raw.c| 46 +++--
2 files changed, 17 insertions(+), 31 deletions(-)
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index 585d5e5..577128a 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -20,7 +20,6 @@
#defineMAX_IR_EVENT_SIZE 512
#include
-#include
#include
struct ir_raw_handler {
@@ -37,7 +36,6 @@ struct ir_raw_handler {
struct ir_raw_event_ctrl {
struct list_headlist; /* to keep track of raw
clients */
struct task_struct *thread;
- spinlock_t lock;
/* fifo for the pulse/space durations */
DECLARE_KFIFO(kfifo, struct ir_raw_event, MAX_IR_EVENT_SIZE);
ktime_t last_event; /* when last event
occurred */
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 205ecc6..71a3e17 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include "rc-core-priv.h"
/* Used to keep track of IR raw clients, protected by ir_raw_handler_lock */
@@ -35,32 +34,26 @@ static int ir_raw_event_thread(void *data)
struct ir_raw_handler *handler;
struct ir_raw_event_ctrl *raw = (struct ir_raw_event_ctrl *)data;
- while (!kthread_should_stop()) {
-
- spin_lock_irq(&raw->lock);
-
- if (!kfifo_len(&raw->kfifo)) {
- set_current_state(TASK_INTERRUPTIBLE);
-
- if (kthread_should_stop())
- set_current_state(TASK_RUNNING);
-
- spin_unlock_irq(&raw->lock);
- schedule();
- continue;
+ while (1) {
+ mutex_lock(&ir_raw_handler_lock);
+ while (kfifo_out(&raw->kfifo, &ev, 1)) {
+ list_for_each_entry(handler, &ir_raw_handler_list, list)
+ if (raw->dev->enabled_protocols &
+ handler->protocols || !handler->protocols)
+ handler->decode(raw->dev, ev);
+ raw->prev_ev = ev;
}
+ mutex_unlock(&ir_raw_handler_lock);
- if(!kfifo_out(&raw->kfifo, &ev, 1))
- dev_err(&raw->dev->dev, "IR event FIFO is empty!\n");
- spin_unlock_irq(&raw->lock);
+ set_current_state(TASK_INTERRUPTIBLE);
- mutex_lock(&ir_raw_handler_lock);
- list_for_each_entry(handler, &ir_raw_handler_list, list)
- if (raw->dev->enabled_protocols & handler->protocols ||
- !handler->protocols)
- handler->decode(raw->dev, ev);
- raw->prev_ev = ev;
- mutex_unlock(&ir_raw_handler_lock);
+ if (kthread_should_stop()) {
+ __set_current_state(TASK_RUNNING);
+ break;
+ } else if (!kfifo_is_empty(&raw->kfifo))
+ set_current_state(TASK_RUNNING);
+
+ schedule();
}
return 0;
@@ -219,14 +212,10 @@ EXPORT_SYMBOL_GPL(ir_raw_event_set_idle);
*/
void ir_raw_event_handle(struct rc_dev *dev)
{
- unsigned long flags;
-
if (!dev->raw)
return;
- spin_lock_irqsave(&dev->raw->lock, flags);
wake_up_process(dev->raw->thread);
- spin_unlock_irqrestore(&dev->raw->lock, flags);
}
EXPORT_SYMBOL_GPL(ir_raw_event_handle);
@@ -274,7 +263,6 @@ int ir_raw_event_register(struct rc_dev *dev)
dev->change_protocol = change_protocol;
INIT_KFIFO(dev->raw->kfifo);
- spin_lock_init(&dev->raw->lock);
dev->raw->threa
[PATCH 3/3] media: rc: nuvoton: simplify nvt_get_rx_ir_data a little
Simplify the code a little.
Signed-off-by: Heiner Kallweit
---
drivers/media/rc/nuvoton-cir.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index fc462f6..04fedaa 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -791,7 +791,7 @@ static void nvt_handle_rx_fifo_overrun(struct nvt_dev *nvt)
/* copy data from hardware rx fifo into driver buffer */
static void nvt_get_rx_ir_data(struct nvt_dev *nvt)
{
- u8 fifocount, val;
+ u8 fifocount;
int i;
/* Get count of how many bytes to read from RX FIFO */
@@ -800,10 +800,8 @@ static void nvt_get_rx_ir_data(struct nvt_dev *nvt)
nvt_dbg("attempting to fetch %u bytes from hw rx fifo", fifocount);
/* Read fifocount bytes from CIR Sample RX FIFO register */
- for (i = 0; i < fifocount; i++) {
- val = nvt_cir_reg_read(nvt, CIR_SRXFIFO);
- nvt->buf[i] = val;
- }
+ for (i = 0; i < fifocount; i++)
+ nvt->buf[i] = nvt_cir_reg_read(nvt, CIR_SRXFIFO);
nvt->pkts = fifocount;
nvt_dbg("%s: pkts now %d", __func__, nvt->pkts);
--
2.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
cron job: media_tree daily build: OK
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: Tue Aug 2 04:00:23 CEST 2016 git branch: test git hash: 292eaf50c7df4ae2ae8aaa9e1ce3f1240a353ee8 gcc version:i686-linux-gcc (GCC) 5.4.0 sparse version: v0.5.0-56-g7647c77 smatch version: v0.5.0-3428-gdfe27cf host hardware: x86_64 host os:4.6.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-blackfin-bf561: 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.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.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-i686: OK linux-4.3-i686: OK linux-4.4-i686: OK linux-4.5-i686: OK linux-4.6-i686: OK linux-4.7-i686: 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.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-x86_64: OK linux-4.3-x86_64: OK linux-4.4-x86_64: OK linux-4.5-x86_64: OK linux-4.6-x86_64: OK linux-4.7-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.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 TRY 3] Support for EVOLVEO XtraTV stick
Hello Antti,
since I see that nobody fixed my patch, here is fixed version which
works for me and is made against latest git version
diff -urN media_build.old/linux/drivers/media/dvb-core/dvb-usb-ids.h
media_build/linux/drivers/media/dvb-core/dvb-usb-ids.h
--- media_build.old/linux/drivers/media/dvb-core/dvb-usb-ids.h
2016-05-07 07:45:09.0 +0200
+++ media_build/linux/drivers/media/dvb-core/dvb-usb-ids.h
2016-08-01 23:18:18.660938910 +0200
@@ -411,4 +411,5 @@
#define USB_PID_SVEON_STV27 0xd3af
#define USB_PID_TURBOX_DTT_2000 0xd3a4
#define USB_PID_WINTV_SOLOHD0x0264
+#define USB_PID_EVOLVEO_XTRATV_STICK 0xa115
#endif
diff -urN media_build.old/linux/drivers/media/usb/dvb-usb-v2/af9035.c
media_build/linux/drivers/media/usb/dvb-usb-v2/af9035.c
--- media_build.old/linux/drivers/media/usb/dvb-usb-v2/af9035.c
2016-07-16 07:45:08.0 +0200
+++ media_build/linux/drivers/media/usb/dvb-usb-v2/af9035.c
2016-08-01 23:19:43.853325151 +0200
@@ -2090,6 +2090,8 @@
&af9035_props, "TerraTec Cinergy T Stick (rev. 2)", NULL) },
{ DVB_USB_DEVICE(USB_VID_AVERMEDIA, 0x0337,
&af9035_props, "AVerMedia HD Volar (A867)", NULL) },
+ { DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_EVOLVEO_XTRATV_STICK,
+ &af9035_props, "EVOLVEO XtraTV stick", NULL) },
/* IT9135 devices */
{ DVB_USB_DEVICE(USB_VID_ITETECH, USB_PID_ITETECH_IT9135,
diff -urN media_build.old/v4l/af9035.c media_build/v4l/af9035.c
--- media_build.old/v4l/af9035.c2016-07-16 07:45:08.0 +0200
+++ media_build/v4l/af9035.c2016-08-01 23:19:43.853325151 +0200
@@ -2090,6 +2090,8 @@
&af9035_props, "TerraTec Cinergy T Stick (rev. 2)", NULL) },
{ DVB_USB_DEVICE(USB_VID_AVERMEDIA, 0x0337,
&af9035_props, "AVerMedia HD Volar (A867)", NULL) },
+ { DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_EVOLVEO_XTRATV_STICK,
+ &af9035_props, "EVOLVEO XtraTV stick", NULL) },
/* IT9135 devices */
{ DVB_USB_DEVICE(USB_VID_ITETECH, USB_PID_ITETECH_IT9135,
Please apply
Best regards
Michal
2016-08-01 22:35 GMT+02:00 CIJOML CIJOMLovic :
> Hello Antti,
>
> where/how can I remove the key mapping? I am not familiar with this source.
>
> Thank you for help
>
> Regards
>
> Michal
>
> 2015-08-31 20:35 GMT+02:00 Antti Palosaari :
>> On 08/31/2015 09:04 PM, CIJOML CIJOMLovic wrote:
>>>
>>> Hello guys,
>>>
>>> please find out down this email patch to support EVOLVEO XtraTV stick.
>>> This tuner is for android phones with microusb connecter, however with
>>> reduction it works perfectly with linux kernel:
>>> The device identify itself at USB bus as Bus 002 Device 004: ID
>>> 1f4d:a115 G-Tek Electronics Group
>>> so I have created new vendor group but device named as its commercial
>>> name.
>>>
>>> Thank you for merging this patch to upstream
>>
>>
>> VID for GTEK is already defined there.
>>
>> Could you remove also remote controller default keymap as I think there is
>> no remote controller at all.
>>
>> regards
>> Antti
>>
>>>
>>> Best regards
>>>
>>> Michal
>>>
>>>
>>> diff -urN media_build/linux/drivers/media/dvb-core/dvb-usb-ids.h
>>> media_build.new/linux/drivers/media/dvb-core/dvb-usb-ids.h
>>> --- media_build/linux/drivers/media/dvb-core/dvb-usb-ids.h
>>> 2015-05-11 13:20:08.0 +0200
>>> +++ media_build.new/linux/drivers/media/dvb-core/dvb-usb-ids.h
>>> 2015-06-16 22:26:01.917990493 +0200
>>> @@ -70,6 +70,8 @@
>>> #define USB_VID_EVOLUTEPC0x1e59
>>> #define USB_VID_AZUREWAVE0x13d3
>>> #define USB_VID_TECHNISAT0x14f7
>>> +#define USB_VID_GTEK0x1f4d
>>> +
>>>
>>> /* Product IDs */
>>> #define USB_PID_ADSTECH_USB2_COLD0xa333
>>> @@ -388,4 +390,5 @@
>>> #define USB_PID_PCTV_2002E_SE 0x025d
>>> #define USB_PID_SVEON_STV27 0xd3af
>>> #define USB_PID_TURBOX_DTT_2000 0xd3a4
>>> +#define USB_PID_EVOLVEO_XTRATV_STICK0xa115
>>> #endif
>>> diff -urN media_build/linux/drivers/media/usb/dvb-usb-v2/af9035.c
>>> media_build.new/linux/drivers/media/usb/dvb-usb-v2/af9035.c
>>> --- media_build/linux/drivers/media/usb/dvb-usb-v2/af9035.c
>>> 2015-05-30 17:32:46.0 +0200
>>> +++ media_build.new/linux/drivers/media/usb/dvb-usb-v2/af9035.c
>>> 2015-06-16 22:26:14.561990868 +0200
>>> @@ -2075,6 +2075,8 @@
>>> &af9035_props, "PCTV AndroiDTV (78e)", RC_MAP_IT913X_V1) },
>>> { DVB_USB_DEVICE(USB_VID_PCTV, USB_PID_PCTV_79E,
>>> &af9035_props, "PCTV microStick (79e)", RC_MAP_IT913X_V2) },
>>> +{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_EVOLVEO_XTRATV_STICK,
>>> +&af9035_props, "EVOLVEO XtraTV stick", RC_MAP_IT913X_V2) },
>>>
>>> /* IT930x devices */
>>> { DVB_USB_DEVICE(USB_VID_ITETECH, USB_PID_ITETECH_IT9303,
>>> r
>>> --
>>> To unsu
Re: [PATCH TRY 2] Support for EVOLVEO XtraTV stick
Hello Antti,
where/how can I remove the key mapping? I am not familiar with this source.
Thank you for help
Regards
Michal
2015-08-31 20:35 GMT+02:00 Antti Palosaari :
> On 08/31/2015 09:04 PM, CIJOML CIJOMLovic wrote:
>>
>> Hello guys,
>>
>> please find out down this email patch to support EVOLVEO XtraTV stick.
>> This tuner is for android phones with microusb connecter, however with
>> reduction it works perfectly with linux kernel:
>> The device identify itself at USB bus as Bus 002 Device 004: ID
>> 1f4d:a115 G-Tek Electronics Group
>> so I have created new vendor group but device named as its commercial
>> name.
>>
>> Thank you for merging this patch to upstream
>
>
> VID for GTEK is already defined there.
>
> Could you remove also remote controller default keymap as I think there is
> no remote controller at all.
>
> regards
> Antti
>
>>
>> Best regards
>>
>> Michal
>>
>>
>> diff -urN media_build/linux/drivers/media/dvb-core/dvb-usb-ids.h
>> media_build.new/linux/drivers/media/dvb-core/dvb-usb-ids.h
>> --- media_build/linux/drivers/media/dvb-core/dvb-usb-ids.h
>> 2015-05-11 13:20:08.0 +0200
>> +++ media_build.new/linux/drivers/media/dvb-core/dvb-usb-ids.h
>> 2015-06-16 22:26:01.917990493 +0200
>> @@ -70,6 +70,8 @@
>> #define USB_VID_EVOLUTEPC0x1e59
>> #define USB_VID_AZUREWAVE0x13d3
>> #define USB_VID_TECHNISAT0x14f7
>> +#define USB_VID_GTEK0x1f4d
>> +
>>
>> /* Product IDs */
>> #define USB_PID_ADSTECH_USB2_COLD0xa333
>> @@ -388,4 +390,5 @@
>> #define USB_PID_PCTV_2002E_SE 0x025d
>> #define USB_PID_SVEON_STV27 0xd3af
>> #define USB_PID_TURBOX_DTT_2000 0xd3a4
>> +#define USB_PID_EVOLVEO_XTRATV_STICK0xa115
>> #endif
>> diff -urN media_build/linux/drivers/media/usb/dvb-usb-v2/af9035.c
>> media_build.new/linux/drivers/media/usb/dvb-usb-v2/af9035.c
>> --- media_build/linux/drivers/media/usb/dvb-usb-v2/af9035.c
>> 2015-05-30 17:32:46.0 +0200
>> +++ media_build.new/linux/drivers/media/usb/dvb-usb-v2/af9035.c
>> 2015-06-16 22:26:14.561990868 +0200
>> @@ -2075,6 +2075,8 @@
>> &af9035_props, "PCTV AndroiDTV (78e)", RC_MAP_IT913X_V1) },
>> { DVB_USB_DEVICE(USB_VID_PCTV, USB_PID_PCTV_79E,
>> &af9035_props, "PCTV microStick (79e)", RC_MAP_IT913X_V2) },
>> +{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_EVOLVEO_XTRATV_STICK,
>> +&af9035_props, "EVOLVEO XtraTV stick", RC_MAP_IT913X_V2) },
>>
>> /* IT930x devices */
>> { DVB_USB_DEVICE(USB_VID_ITETECH, USB_PID_ITETECH_IT9303,
>> r
>> --
>> 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
>>
>
> --
> http://palosaari.fi/
--
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 2/3] soc-camera/rcar-vin: remove obsolete driver
On 2016-08-01 11:31:11 +0300, Laurent Pinchart wrote: > Hi Hans, > > Thank you for the patch. > > On Monday 01 Aug 2016 09:54:24 Hans Verkuil wrote: > > From: Hans Verkuil > > > > This driver has been replaced by the non-soc-camera rcar-vin driver. > > The soc-camera framework is being deprecated, so drop this older > > rcar-vin driver in favor of the newer version that does not rely on > > this deprecated framework. > > > > Signed-off-by: Hans Verkuil > > Cc: Laurent Pinchart > > Cc: Guennadi Liakhovetski > > Cc: Niklas Söderlund > > I'm all for removal of dead code :-) > > Acked-by: Laurent Pinchart > > But please get Niklas' ack to confirm that the new driver supports all the > feature available in the old one. I'm all for removing this code. And I do believe the new driver supports (almost, see 1) all features this one do. There are however two known issues with the new driver which maybe should be resolved before the old one is removed. 1. The soc-camera driver call g_std to determine video standard if field is V4L2_FIELD_INTERLACED. The new driver dose not. I'm preparing a patch which restores this functionality and hope to post it soon. 2. There is a error in the DT parsing code where of_node_put() is called twice resulting in a nice backtrace while booting if the debug config options are enabled. There is a fix for this in the Gen3 enablement series but maybe I should break it out from there and post it separately? I would like to solve issue no 1 before we remove the soc-camera driver, hopefully we can do so shortly. > > > --- > > drivers/media/platform/soc_camera/Kconfig| 10 - > > drivers/media/platform/soc_camera/Makefile |1 - > > drivers/media/platform/soc_camera/rcar_vin.c | 1970 --- > > 3 files changed, 1981 deletions(-) > > delete mode 100644 drivers/media/platform/soc_camera/rcar_vin.c > > -- > Regards, > > Laurent Pinchart > -- Regards, Niklas Söderlund -- 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: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-08-01 20:06 GMT+03:00 Viresh Kumar : > On 01-08-16, 20:01, Matwey V. Kornilov wrote: >> With this patch, there is no cpufreq directory here. >> >> Without this patch, the output is the following: >> >> nohostname:~ # uname -a >> Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15 >> 08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux >> nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver >> cpufreq-dt > > I hope that the below patch fixes it for you? > Yes, it is. Thank you. > [PATCH] cpufreq: am33xx: Use generic platdev driver > > -- > viresh > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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: pwc over musb: 100% frame drop (lost) on high resolution stream
pwc module output with trace=511 is the following: [ 24.793109] usbcore: registered new interface driver Philips webcam [ 29.276979] pwc: Unsupported pixel format [ 29.277055] pwc: pwc_vidioc_fill_fmt() width=640, height=480, bytesperline=640, sizeimage=460800, pixelformat=YU12 [ 29.277090] pwc: Trying to set format to: width=640 height=480 fps=15 format=YU12 [ 29.277123] pwc: set_video_mode(640x480 @ 30, pixfmt 32315559). [ 29.277145] pwc: decode_size = 5. [ 29.277180] pwc: frame_size=63120, vframes=15, vsize=5, vbandlength=526 [ 29.277204] pwc: Set resolution to 640x480 [ 29.277225] pwc: pwc_set_video_mode(), return=0 [ 29.277256] pwc: pwc_vidioc_fill_fmt() width=640, height=480, bytesperline=640, sizeimage=460800, pixelformat=YU12 [ 29.277306] pwc: ioctl(VIDIOC_G_FMT) return size 640x480 [ 29.277337] pwc: pwc_vidioc_fill_fmt() width=640, height=480, bytesperline=640, sizeimage=460800, pixelformat=YU12 [ 29.277449] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559). [ 29.277475] pwc: decode_size = 5. [ 29.278726] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788 [ 29.278750] pwc: Set resolution to 640x480 [ 29.300374] pwc: set_video_mode(640x480 @ 10, pixfmt 32315559). [ 29.300420] pwc: decode_size = 5. [ 29.441759] pwc: frame_size=94560, vframes=10, vsize=5, vbandlength=788 [ 29.441792] pwc: Set resolution to 640x480 [ 29.441824] pwc: Setting alternate interface 9 [ 29.455061] pwc: Allocated URB at 0xc9b83600 [ 29.455850] pwc: Allocated URB at 0xc9b83400 [ 29.456040] pwc: Allocated URB at 0xc9b83200 [ 29.456271] pwc: URB 0xc9b83600 submitted. [ 29.456310] pwc: URB 0xc9b83400 submitted. [ 29.456341] pwc: URB 0xc9b83200 submitted. [ 29.456362] pwc: << pwc_isoc_init() [ 30.078550] pwc: Frame buffer underflow (20076 bytes); discarded. [ 30.170543] pwc: Frame buffer underflow (12428 bytes); discarded. [ 30.272538] pwc: Frame buffer underflow (14340 bytes); discarded. [ 30.374541] pwc: Frame buffer underflow (16252 bytes); discarded. [ 30.476535] pwc: Frame buffer underflow (18164 bytes); discarded. [ 30.578532] pwc: Frame buffer underflow (20076 bytes); discarded. [ 30.670538] pwc: Frame buffer underflow (12428 bytes); discarded. [ 30.772544] pwc: Frame buffer underflow (14340 bytes); discarded. [ 30.874547] pwc: Frame buffer underflow (16252 bytes); discarded. [ 30.976552] pwc: Frame buffer underflow (18164 bytes); discarded. [ 31.078536] pwc: Frame buffer underflow (20076 bytes); discarded. [ 31.170533] pwc: Frame buffer underflow (12428 bytes); discarded. [ 31.272549] pwc: Frame buffer underflow (14340 bytes); discarded. [ 31.374545] pwc: Frame buffer underflow (16252 bytes); discarded. [ 31.476537] pwc: Frame buffer underflow (18164 bytes); discarded. [ 31.578536] pwc: Frame buffer underflow (20076 bytes); discarded. [ 31.660895] pwc: Frame buffer underflow (11472 bytes); discarded. [ 31.772554] pwc: Frame buffer underflow (14340 bytes); discarded. [ 31.874548] pwc: Frame buffer underflow (16252 bytes); discarded. [ 31.976533] pwc: Frame buffer underflow (18164 bytes); discarded. 2016-07-31 23:31 GMT+03:00 Matwey V. Kornilov : > Hello, > > I've also just found that the same commit breaks cpufreq on BeagleBone Black > :) > > So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU > frequency, which is unlisted and being set to 720Mhz by cpufreq driver > (as it did whet there was cpufreq driver). > > 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov : >> Hello, >> >> I've found that the following commit fixes the issue: >> >> commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063 >> Author: Viresh Kumar >> Date: Fri Apr 22 16:58:42 2016 +0530 >> >> cpufreq: omap: Use generic platdev driver >> >> The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform >> device now, reuse that and remove similar code from platform code. >> >> >> 2016-07-28 19:16 GMT+03:00 Matwey V. Kornilov : >>> Hello, >>> >>> I've just bisected commit, which fixed the issue in v4.7 >>> >>> commit 9fa64d6424adabf0e3a546ae24d01a62a927b342 >>> Merge: f55532a febce40 >>> Author: Rafael J. Wysocki >>> Date: Sat Apr 2 01:07:17 2016 +0200 >>> >>> Merge back intel_pstate fixes for v4.6. >>> >>> * pm-cpufreq: >>> intel_pstate: Avoid extra invocation of intel_pstate_sample() >>> intel_pstate: Do not set utilization update hook too early >>> >>> Unfortunately, intel_pstate branch doesn't have >>> f551e13529833e052f75ec628a8af7b034af20f9 applied. >>> I'll try to bisect this branch with the patch manually applied. >>> >>> 2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov : Hello, I've just biseced commit, which introduced this issue commit f551e13529833e052f75ec628a8af7b034af20f9 Author: Bin Liu Date: Mon Apr 25 15:53:30 2016 -0500 Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb return in bottom half" I have no
Re: [PATCH 1/6] media: rcar-vin: allow field to be changed
On 08/01/2016 06:52 PM, Niklas Söderlund wrote: > Hi Sergei, > > Thanks for testing! > > On 2016-07-30 00:04:33 +0300, Sergei Shtylyov wrote: >> On 07/29/2016 08:40 PM, Niklas Söderlund wrote: >> >>> The driver forced whatever field was set by the source subdevice to be >>> used. This patch allows the user to change from the default field. >>> >>> Signed-off-by: Niklas Söderlund >> >>I didn't apply this patch at first (thinking it was unnecessary), and the >> capture worked fine. The field order appeared swapped again after I did >> import this patch as well. :-( > > I had a look at the test tool you told me you use > (https://linuxtv.org/downloads/v4l-dvb-apis/capture-example.html) and > the reason the field order is swapped is a combination of that tool and > how the rcar-vin driver interprets V4L2_FIELD_INTERLACED. > > 1. The tool you use asks for V4L2_FIELD_INTERLACED if the -f switch is >used. You told me #v4l that you do use that switch, but have modified >the tool to use a different pixelformat than used in the link above, >correct? > > 2. The rcar-vin driver interprets V4L2_FIELD_INTERLACED as >V4L2_FIELD_INTERLACED_TB. If this is correct or not I do not know, That's wrong. FIELD_INTERLACED is standard dependent: it is effectively equal to INTERLACED_TB for 50 Hz formats and equal to INTERLACED_BT for 60 Hz formats. For non-SDTV timings (e.g. 720i) it is equal to INTERLACED_TB. Stick to FIELD_INTERLACED, that's what you normally want to use. >the old soc-camera version of the driver do it this way so I have >kept that logic. > > This is the reason why the field order is wrong when you apply this > patch. Without it the field order would be locked to whatever the > subdevice reports, V4L2_FIELD_ALTERNATE in this case. > > I don't know if it's correct to treat V4L2_FIELD_INTERLACED as > V4L2_FIELD_INTERLACED_TB or if I should try and use G_STD if > V4L2_FIELD_INTERLACED is requested and change the field to _TB or _BT > according to the result of that. I feel this will only push the problem > further down. What if G_STD is not implemented by the subdevice? Then a > default fallback interpretation to ether _TB or _BT would still be > needed. I'm open to suggestion on how to handle this case. > > There is also a feature missing in this patch. The field order was set > to V4L2_FIELD_NONE if the requested format asks for V4L2_FIELD_ANY. > This have no effect for how you test but i did run into it while trying > to figure this out. I will send out a v2 which solves this by retaining > the current field mode if V4L2_FIELD_ANY is asked for. > >> >> MBR, Sergei >> > I plan on reviewing all these field-related patches tomorrow. 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] doc-rst: Remove the media docbook
On Mon, 1 Aug 2016 08:19:14 -0300 Mauro Carvalho Chehab wrote: > My general impression is that it is now a way easier to maintain the > media documentation and make it more consistent than with DocBook. Music to my ears - maybe this whole thing was worth it :) Seriously, though, this whole thing was kind of dropped on you, many thanks for how you've run with it and helped to push it forward - much appreciated. jon -- 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: pwc over musb: 100% frame drop (lost) on high resolution stream
On 01-08-16, 20:01, Matwey V. Kornilov wrote: > With this patch, there is no cpufreq directory here. > > Without this patch, the output is the following: > > nohostname:~ # uname -a > Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15 > 08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux > nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver > cpufreq-dt I hope that the below patch fixes it for you? [PATCH] cpufreq: am33xx: Use generic platdev driver -- viresh -- 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: Memory freeing when dmabuf fds are exported with VIDIOC_EXPBUF
> That's a good question. On one extreme an application trying to allocate 32 > 50MB buffers would seem suspicious to me, but on the other hand it would be > difficult to answer the question in a way that can be translated into code. 8k video in the ARGB 8bit 4:4:4 colorspace, would need a 126MB per frame buffer. -- Steven Toth - 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: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-08-01 19:50 GMT+03:00 Viresh Kumar :
> On 31-07-16, 23:31, Matwey V. Kornilov wrote:
>> Hello,
>>
>> I've also just found that the same commit breaks cpufreq on BeagleBone Black
>> :)
>>
>> So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU
>> frequency, which is unlisted and being set to 720Mhz by cpufreq driver
>> (as it did whet there was cpufreq driver).
>>
>> 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov :
>> > Hello,
>> >
>> > I've found that the following commit fixes the issue:
>> >
>> > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063
>> > Author: Viresh Kumar
>> > Date: Fri Apr 22 16:58:42 2016 +0530
>> >
>> > cpufreq: omap: Use generic platdev driver
>> >
>> > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform
>> > device now, reuse that and remove similar code from platform code.
>
> Sorry for this commit and the man hours wasted to get to this :(
>
> I am trying to figure out why things break though, as this patch shouldn't
> have
> had any functional impacts. So, some of the assumptions I had are surely
> incorrect..
Actually, nothing to sorry about.
I suppose, that with this patch my BeagleBone run at 1Ghz after boot,
because usually cpufreq limits it to 720Mhz saying
[ 14.255646] cpu cpu0: dev_pm_opp_set_rate: failed to find current
OPP for freq 10 (-34)
And actually musb is still broken after f551e13529833e052f75ec628a8af7
(" Revert "usb: musb: musb_host")
>
> The defconfig linked in the original thread [1] has this:
>
> CONFIG_CPUFREQ_DT=m
>
> So, the cpufreq-dt module needs to get inserted to make it work.
>
It has been inserted automatically by alias `platform:cpufreq-dt'
Issue here that 4.7 stopped to provide `platfrom:cpufreq-dt' on BeagleBone.
Have you received my patch fixing it yet?
> Can someone provide the output of:
>
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
>
> with and without this patch ?
With this patch, there is no cpufreq directory here.
Without this patch, the output is the following:
nohostname:~ # uname -a
Linux nohostname 4.6.4-3.gecd9058-default #1 SMP PREEMPT Fri Jul 15
08:08:50 UTC 2016 (ecd9058) armv7l armv7l armv7l GNU/Linux
nohostname:~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
cpufreq-dt
>
> It looks like we wanted to select "omap-cpufreq" for beaglebone and selected
> "cpufreq-dt" by mistake.
No, I am not sure, cpufreq-dt worked well until v4.7 where it is disappeared.
>
> [Note]: I am not subscribed to USB lists and so please include me for any
> emails
> you want my response on.
>
> --
> viresh
>
> [1] http://www.spinics.net/lists/linux-usb/msg143956.html
>
> --
> viresh
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: Memory freeing when dmabuf fds are exported with VIDIOC_EXPBUF
On Monday 01 Aug 2016 12:16:25 Steven Toth wrote: > > That's a good question. On one extreme an application trying to allocate > > 32 50MB buffers would seem suspicious to me, but on the other hand it > > would be difficult to answer the question in a way that can be translated > > into code. > > 8k video in the ARGB 8bit 4:4:4 colorspace, would need a 126MB per frame > buffer. Hopefully not 32 of them though. There's no easy way to compute an accurate limit, but maybe we could do improve the current situation with some heuristics based on the maximum resolution a device can capture. -- 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
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
On 31-07-16, 23:31, Matwey V. Kornilov wrote: > Hello, > > I've also just found that the same commit breaks cpufreq on BeagleBone Black > :) > > So, probably without HCD_BH flag musb works correctly only at 1Ghz CPU > frequency, which is unlisted and being set to 720Mhz by cpufreq driver > (as it did whet there was cpufreq driver). > > 2016-07-29 21:01 GMT+03:00 Matwey V. Kornilov : > > Hello, > > > > I've found that the following commit fixes the issue: > > > > commit 7694ca6e1d6f01122f05039b81f70f64b1ec4063 > > Author: Viresh Kumar > > Date: Fri Apr 22 16:58:42 2016 +0530 > > > > cpufreq: omap: Use generic platdev driver > > > > The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform > > device now, reuse that and remove similar code from platform code. Sorry for this commit and the man hours wasted to get to this :( I am trying to figure out why things break though, as this patch shouldn't have had any functional impacts. So, some of the assumptions I had are surely incorrect.. The defconfig linked in the original thread [1] has this: CONFIG_CPUFREQ_DT=m So, the cpufreq-dt module needs to get inserted to make it work. Can someone provide the output of: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver with and without this patch ? It looks like we wanted to select "omap-cpufreq" for beaglebone and selected "cpufreq-dt" by mistake. [Note]: I am not subscribed to USB lists and so please include me for any emails you want my response on. -- viresh [1] http://www.spinics.net/lists/linux-usb/msg143956.html -- viresh -- 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 4/6] media: rcar-vin: add support for V4L2_FIELD_ALTERNATE
Hi Sergei, On 2016-07-31 00:55:04 +0300, Sergei Shtylyov wrote: > Hello. > > On 07/29/2016 08:40 PM, Niklas Söderlund wrote: > > > The HW can capture both ODD and EVEN fields in separate buffers so it's > > possible to support this field mode. > > > > Signed-off-by: Niklas Söderlund >It's probably worth adding that if the subdevice presents the video data > in this mode, we prefer to use the hardware de-interlacing. Will include this in v2, thanks for pointing it out. > > MBR, Sergei > > PS: I think I have a patch adding support for this mode to the old driver, > so that it doesn't get borked with the patch #6 in this series. > -- Regards, Niklas Söderlund -- 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 1/6] media: rcar-vin: allow field to be changed
Hi Sergei, Thanks for testing! On 2016-07-30 00:04:33 +0300, Sergei Shtylyov wrote: > On 07/29/2016 08:40 PM, Niklas Söderlund wrote: > > > The driver forced whatever field was set by the source subdevice to be > > used. This patch allows the user to change from the default field. > > > > Signed-off-by: Niklas Söderlund > >I didn't apply this patch at first (thinking it was unnecessary), and the > capture worked fine. The field order appeared swapped again after I did > import this patch as well. :-( I had a look at the test tool you told me you use (https://linuxtv.org/downloads/v4l-dvb-apis/capture-example.html) and the reason the field order is swapped is a combination of that tool and how the rcar-vin driver interprets V4L2_FIELD_INTERLACED. 1. The tool you use asks for V4L2_FIELD_INTERLACED if the -f switch is used. You told me #v4l that you do use that switch, but have modified the tool to use a different pixelformat than used in the link above, correct? 2. The rcar-vin driver interprets V4L2_FIELD_INTERLACED as V4L2_FIELD_INTERLACED_TB. If this is correct or not I do not know, the old soc-camera version of the driver do it this way so I have kept that logic. This is the reason why the field order is wrong when you apply this patch. Without it the field order would be locked to whatever the subdevice reports, V4L2_FIELD_ALTERNATE in this case. I don't know if it's correct to treat V4L2_FIELD_INTERLACED as V4L2_FIELD_INTERLACED_TB or if I should try and use G_STD if V4L2_FIELD_INTERLACED is requested and change the field to _TB or _BT according to the result of that. I feel this will only push the problem further down. What if G_STD is not implemented by the subdevice? Then a default fallback interpretation to ether _TB or _BT would still be needed. I'm open to suggestion on how to handle this case. There is also a feature missing in this patch. The field order was set to V4L2_FIELD_NONE if the requested format asks for V4L2_FIELD_ANY. This have no effect for how you test but i did run into it while trying to figure this out. I will send out a v2 which solves this by retaining the current field mode if V4L2_FIELD_ANY is asked for. > > MBR, Sergei > -- Regards, Niklas Söderlund -- 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: Memory freeing when dmabuf fds are exported with VIDIOC_EXPBUF
Hi Hans, On Monday 01 Aug 2016 15:59:54 Hans Verkuil wrote: > On 08/01/2016 03:49 PM, Laurent Pinchart wrote: > > On Monday 01 Aug 2016 14:27:48 Hans Verkuil wrote: > >> On 08/01/2016 02:17 PM, Laurent Pinchart wrote: > >>> On Monday 01 Aug 2016 12:56:55 Hans Verkuil wrote: > On 07/27/2016 02:57 PM, Laurent Pinchart wrote: > > On Wednesday 27 Jul 2016 16:51:47 Kazunori Kobayashi wrote: > >> Hi, > >> > >> I have a question about memory freeing by calling REQBUF(0) before > >> all the dmabuf fds exported with VIDIOC_EXPBUF are closed. > >> > >> In calling REQBUF(0), videobuf2-core returns -EBUSY when the > >> reference count of a vb2 buffer is more than 1. When dmabuf fds are > >> not exported (usual V4L2_MEMORY_MMAP case), the check is no problem, > >> but when dmabuf fds are exported and some of them are not closed (in > >> other words the references to that memory are left), we cannot > >> succeed in calling REQBUF(0) despite being able to free the memory > >> after all the references are dropped. > >> > >> Actually REQBUF(0) does not force a vb2 buffer to be freed but > >> decreases the refcount of it. Also all the vb2 memory allocators that > >> support dmabuf exporting (dma-contig, dma-sg, vmalloc) implements > >> memory freeing by release() of dma_buf_ops, so I think there is no > >> need to return -EBUSY when exporting dmabuf fds. > >> > >> Could you please tell me what you think? > > > > I think you're right. vb2 allocates the vb2_buffer and the > > memops-specific structure separately. videobuf2-core.c will free the > > vb2_buffer instance, but won't touch the memops-specific structure or > > the buffer memory. Both of these are reference-counted in the memops > > allocators. We could thus allow REQBUFS(0) to proceed even when > > buffers have been exported (or at least after fixing the small issues > > we'll run into, I have a feeling that this is too easy to be true). > > > > Hans, Marek, any opinion on this ? > > What is the use-case for this? What you are doing here is to either > free all existing buffers or reallocate buffers. We can decide to rely > on refcounting, but then you would create a second set of buffers (when > re-allocating) or leave a lot of unfreed memory behind. That's pretty > hard on the memory usage. > >>> > >>> Speaking of which, we have no way today to really limit memory usage. I > >>> wonder whether we should try to integrate support for resource limits in > >>> V4L2. > >> > >> I'm opposed to that. We had drivers in the past that did that (perhaps > >> there are still a few old ones left), but I removed those checks. In > >> practice this all depends on the use-case. And if you try to allocate > >> more buffers than there is memory, you just get ENOMEM. Which is what it > >> is there for. > >> > >> After all, how to decide what limit to use? If someone wants to use all > >> 32 buffers for some reason, or allocate larger buffers than strictly > >> needed, then they should be able to do so. Perhaps you want to be able to > >> capture a burst of high quality snapshots without having to process them > >> immediately. Or other video streams are going to be composed into the > >> buffers so you need to make them larger. > >> > >> The only real limits are the amount of physical (DMAable) memory and the > >> artificial 32 buffer limit which we already know is insufficient in > >> certain use-cases. > > > > When the user running V4L2 applications has full control over the system, > > perhaps, but how about shared systems where the system administrator wants > > to control resource usage per user ? Containers also come to mind, > > per-cgroup memory limits should be honoured. > > If an administrator explicitly restricts memory usage, then it would make > sense to honor that. Are those checks perhaps already done deep in the mm > code? I've no idea what would be involved. To be honest, I haven't checked. > > And even for single-user systems, having the system start trashing because > > a random 3rd party video application decided to allocate a large number > > of buffers for no good reason provides a pretty bad user experience. > > How would you know it is 'for no good reason'? That's a good question. On one extreme an application trying to allocate 32 50MB buffers would seem suspicious to me, but on the other hand it would be difficult to answer the question in a way that can be translated into code. One thing we should perhaps do, though, is make sure that drivers limit the size of the buffers being allocated. If a device resolution is limited to VGA images, it makes little sense to allow VIDIOC_CREATE_BUF to allocate 20MB buffers. There could perhaps be use cases though, when sharing a buffer between devices. > Like any other application if it uses too much memory either don't use it or > fix it.
Re: Memory freeing when dmabuf fds are exported with VIDIOC_EXPBUF
Hi Hans, On Monday 01 Aug 2016 14:27:48 Hans Verkuil wrote: > On 08/01/2016 02:17 PM, Laurent Pinchart wrote: > > On Monday 01 Aug 2016 12:56:55 Hans Verkuil wrote: > >> On 07/27/2016 02:57 PM, Laurent Pinchart wrote: > >>> On Wednesday 27 Jul 2016 16:51:47 Kazunori Kobayashi wrote: > Hi, > > I have a question about memory freeing by calling REQBUF(0) before all > the dmabuf fds exported with VIDIOC_EXPBUF are closed. > > In calling REQBUF(0), videobuf2-core returns -EBUSY when the reference > count of a vb2 buffer is more than 1. When dmabuf fds are not exported > (usual V4L2_MEMORY_MMAP case), the check is no problem, but when dmabuf > fds are exported and some of them are not closed (in other words the > references to that memory are left), we cannot succeed in calling > REQBUF(0) despite being able to free the memory after all the > references are dropped. > > Actually REQBUF(0) does not force a vb2 buffer to be freed but > decreases the refcount of it. Also all the vb2 memory allocators that > support dmabuf exporting (dma-contig, dma-sg, vmalloc) implements > memory freeing by release() of dma_buf_ops, so I think there is no need > to return -EBUSY when exporting dmabuf fds. > > Could you please tell me what you think? > >>> > >>> I think you're right. vb2 allocates the vb2_buffer and the > >>> memops-specific structure separately. videobuf2-core.c will free the > >>> vb2_buffer instance, but won't touch the memops-specific structure or > >>> the buffer memory. Both of these are reference-counted in the memops > >>> allocators. We could thus allow REQBUFS(0) to proceed even when buffers > >>> have been exported (or at least after fixing the small issues we'll run > >>> into, I have a feeling that this is too easy to be true). > >>> > >>> Hans, Marek, any opinion on this ? > >> > >> What is the use-case for this? What you are doing here is to either free > >> all existing buffers or reallocate buffers. We can decide to rely on > >> refcounting, but then you would create a second set of buffers (when > >> re-allocating) or leave a lot of unfreed memory behind. That's pretty > >> hard > >> on the memory usage. > > > > Speaking of which, we have no way today to really limit memory usage. I > > wonder whether we should try to integrate support for resource limits in > > V4L2. > > I'm opposed to that. We had drivers in the past that did that (perhaps there > are still a few old ones left), but I removed those checks. In practice > this all depends on the use-case. And if you try to allocate more buffers > than there is memory, you just get ENOMEM. Which is what it is there for. > > After all, how to decide what limit to use? If someone wants to use all 32 > buffers for some reason, or allocate larger buffers than strictly needed, > then they should be able to do so. Perhaps you want to be able to capture a > burst of high quality snapshots without having to process them immediately. > Or other video streams are going to be composed into the buffers so you > need to make them larger. > > The only real limits are the amount of physical (DMAable) memory and the > artificial 32 buffer limit which we already know is insufficient in > certain use-cases. When the user running V4L2 applications has full control over the system, perhaps, but how about shared systems where the system administrator wants to control resource usage per user ? Containers also come to mind, per-cgroup memory limits should be honoured. And even for single-user systems, having the system start trashing because a random 3rd party video application decided to allocate a large number of buffers for no good reason provides a pretty bad user experience. -- 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
Re: Memory freeing when dmabuf fds are exported with VIDIOC_EXPBUF
On 08/01/2016 03:49 PM, Laurent Pinchart wrote: > Hi Hans, > > On Monday 01 Aug 2016 14:27:48 Hans Verkuil wrote: >> On 08/01/2016 02:17 PM, Laurent Pinchart wrote: >>> On Monday 01 Aug 2016 12:56:55 Hans Verkuil wrote: On 07/27/2016 02:57 PM, Laurent Pinchart wrote: > On Wednesday 27 Jul 2016 16:51:47 Kazunori Kobayashi wrote: >> Hi, >> >> I have a question about memory freeing by calling REQBUF(0) before all >> the dmabuf fds exported with VIDIOC_EXPBUF are closed. >> >> In calling REQBUF(0), videobuf2-core returns -EBUSY when the reference >> count of a vb2 buffer is more than 1. When dmabuf fds are not exported >> (usual V4L2_MEMORY_MMAP case), the check is no problem, but when dmabuf >> fds are exported and some of them are not closed (in other words the >> references to that memory are left), we cannot succeed in calling >> REQBUF(0) despite being able to free the memory after all the >> references are dropped. >> >> Actually REQBUF(0) does not force a vb2 buffer to be freed but >> decreases the refcount of it. Also all the vb2 memory allocators that >> support dmabuf exporting (dma-contig, dma-sg, vmalloc) implements >> memory freeing by release() of dma_buf_ops, so I think there is no need >> to return -EBUSY when exporting dmabuf fds. >> >> Could you please tell me what you think? > > I think you're right. vb2 allocates the vb2_buffer and the > memops-specific structure separately. videobuf2-core.c will free the > vb2_buffer instance, but won't touch the memops-specific structure or > the buffer memory. Both of these are reference-counted in the memops > allocators. We could thus allow REQBUFS(0) to proceed even when buffers > have been exported (or at least after fixing the small issues we'll run > into, I have a feeling that this is too easy to be true). > > Hans, Marek, any opinion on this ? What is the use-case for this? What you are doing here is to either free all existing buffers or reallocate buffers. We can decide to rely on refcounting, but then you would create a second set of buffers (when re-allocating) or leave a lot of unfreed memory behind. That's pretty hard on the memory usage. >>> >>> Speaking of which, we have no way today to really limit memory usage. I >>> wonder whether we should try to integrate support for resource limits in >>> V4L2. >> >> I'm opposed to that. We had drivers in the past that did that (perhaps there >> are still a few old ones left), but I removed those checks. In practice >> this all depends on the use-case. And if you try to allocate more buffers >> than there is memory, you just get ENOMEM. Which is what it is there for. >> >> After all, how to decide what limit to use? If someone wants to use all 32 >> buffers for some reason, or allocate larger buffers than strictly needed, >> then they should be able to do so. Perhaps you want to be able to capture a >> burst of high quality snapshots without having to process them immediately. >> Or other video streams are going to be composed into the buffers so you >> need to make them larger. >> >> The only real limits are the amount of physical (DMAable) memory and the >> artificial 32 buffer limit which we already know is insufficient in >> certain use-cases. > > When the user running V4L2 applications has full control over the system, > perhaps, but how about shared systems where the system administrator wants to > control resource usage per user ? Containers also come to mind, per-cgroup > memory limits should be honoured. If an administrator explicitly restricts memory usage, then it would make sense to honor that. Are those checks perhaps already done deep in the mm code? I've no idea what would be involved. > And even for single-user systems, having the system start trashing because a > random 3rd party video application decided to allocate a large number of > buffers for no good reason provides a pretty bad user experience. > How would you know it is 'for no good reason'? Like any other application if it uses too much memory either don't use it or fix it. It's not up to the kernel to limit this arbitrarily. My opinion, of course. 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: [RFC PATCH] serio: add hangup support
On 07/15/2016 06:31 PM, Dmitry Torokhov wrote:
> Hi Hans,
>
> On Fri, Jul 15, 2016 at 01:27:21PM +0200, Hans Verkuil wrote:
>> For the upcoming 4.8 kernel I made a driver for the Pulse-Eight USB CEC
>> adapter.
>> This is a usb device that shows up as a ttyACM0 device. It requires that you
>> run
>> inputattach in order to communicate with it via serio.
>>
>> This all works well, but it would be nice to have a udev rule to
>> automatically
>> start inputattach. That too works OK, but the problem comes when the USB
>> device
>> is unplugged: the tty hangup is never handled by the serio framework so the
>> inputattach utility never exits and you have to kill it manually.
>>
>> By adding this hangup callback the inputattach utility now exists as soon as
>> I
>> unplug the USB device.
>>
>> Is this the correct approach?
>>
>> BTW, the new driver is found here:
>>
>> https://git.linuxtv.org/media_tree.git/tree/drivers/staging/media/pulse8-cec
>>
>> Regards,
>>
>> Hans
>>
>> Signed-off-by: Hans Verkuil
>>
>> ---
>> diff --git a/drivers/input/serio/serport.c b/drivers/input/serio/serport.c
>> index 9c927d3..a615846 100644
>> --- a/drivers/input/serio/serport.c
>> +++ b/drivers/input/serio/serport.c
>> @@ -248,6 +248,14 @@ static long serport_ldisc_compat_ioctl(struct
>> tty_struct *tty,
>> }
>> #endif
>>
>> +static int serport_ldisc_hangup(struct tty_struct * tty)
>> +{
>> +struct serport *serport = (struct serport *) tty->disc_data;
>> +
>> +serport_serio_close(serport->serio);
>
> I see what you mean, but this is not quite correct. I think we should
> make serport_serio_close() only reset the SERPORT_ACTIVE flag and have
> serport_ldisc_hangup() actually do:
>
> spin_lock_irqsave(&serport->lock, flags);
> set_bit(SERPORT_DEAD, &serport->flags);
> spin_unlock_irqrestore(&serport->lock, flags);
>
> wake_up_interruptible(&serport->wait);
I'm preparing a v2 of this patch, but I wonder if in this hangup code
I also need to clear the SERPORT_ACTIVE flag. Or is it guaranteed that
close() always precedes hangup()? In which case close() always clears that
flag.
Regards,
Hans
>
> i.e. if user (via device-driver - input core - evdev - userspace chain)
> stops using serio port we should not kill inputattach instance right
> then and there, but wait for the serial port device disconnect or
> something else killing inputattach.
>
> Vojtech, do you recall any of this code?
>
> Thanks.
>
--
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: Sony tuner chip driver questions
Dear Mauro Thanks for your replying. I am checking your comments and linux/media codes. I need to discuss with our members about our driver's structure. Especially, 1. SPI > There aren't many DVB drivers that aren't either PCI or USB. > There's one at drivers/media/mmc/siano/smssdio.c, but I guess this is not the > best example. ST is working on upstreaming drivers for some of their SoCs. > They're > placing their drivers under drivers/media/platform/sti. Maybe this could help > you more on that. 2.Tuner & Demodulator > At the DVB frontend, the tuner and demodulators should be implemented on > different > drivers, even when both are encapsulated on the same silicon. > By using two drivers, it makes easier to review the code. It also helps to > better > encapsulate the functions on each part of the chip. Our codes for tuner and demodulator driver of user-space are encapsulated in order to optimize tuner control sequence. I will send comments and additional questions after we have internal discussion. Thanks, Takiguchi -- 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: Memory freeing when dmabuf fds are exported with VIDIOC_EXPBUF
On 08/01/2016 02:17 PM, Laurent Pinchart wrote: > Hi Hans, > > On Monday 01 Aug 2016 12:56:55 Hans Verkuil wrote: >> On 07/27/2016 02:57 PM, Laurent Pinchart wrote: >>> On Wednesday 27 Jul 2016 16:51:47 Kazunori Kobayashi wrote: Hi, I have a question about memory freeing by calling REQBUF(0) before all the dmabuf fds exported with VIDIOC_EXPBUF are closed. In calling REQBUF(0), videobuf2-core returns -EBUSY when the reference count of a vb2 buffer is more than 1. When dmabuf fds are not exported (usual V4L2_MEMORY_MMAP case), the check is no problem, but when dmabuf fds are exported and some of them are not closed (in other words the references to that memory are left), we cannot succeed in calling REQBUF(0) despite being able to free the memory after all the references are dropped. Actually REQBUF(0) does not force a vb2 buffer to be freed but decreases the refcount of it. Also all the vb2 memory allocators that support dmabuf exporting (dma-contig, dma-sg, vmalloc) implements memory freeing by release() of dma_buf_ops, so I think there is no need to return -EBUSY when exporting dmabuf fds. Could you please tell me what you think? >>> >>> I think you're right. vb2 allocates the vb2_buffer and the memops-specific >>> structure separately. videobuf2-core.c will free the vb2_buffer instance, >>> but won't touch the memops-specific structure or the buffer memory. Both >>> of these are reference-counted in the memops allocators. We could thus >>> allow REQBUFS(0) to proceed even when buffers have been exported (or at >>> least after fixing the small issues we'll run into, I have a feeling that >>> this is too easy to be true). >>> >>> Hans, Marek, any opinion on this ? >> >> What is the use-case for this? What you are doing here is to either free all >> existing buffers or reallocate buffers. We can decide to rely on >> refcounting, but then you would create a second set of buffers (when >> re-allocating) or leave a lot of unfreed memory behind. That's pretty hard >> on the memory usage. > > Speaking of which, we have no way today to really limit memory usage. I > wonder > whether we should try to integrate support for resource limits in V4L2. I'm opposed to that. We had drivers in the past that did that (perhaps there are still a few old ones left), but I removed those checks. In practice this all depends on the use-case. And if you try to allocate more buffers than there is memory, you just get ENOMEM. Which is what it is there for. After all, how to decide what limit to use? If someone wants to use all 32 buffers for some reason, or allocate larger buffers than strictly needed, then they should be able to do so. Perhaps you want to be able to capture a burst of high quality snapshots without having to process them immediately. Or other video streams are going to be composed into the buffers so you need to make them larger. The only real limits are the amount of physical (DMAable) memory and the artificial 32 buffer limit which we already know is insufficient in certain use-cases. 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: Memory freeing when dmabuf fds are exported with VIDIOC_EXPBUF
Hi Hans,
On Monday 01 Aug 2016 12:56:55 Hans Verkuil wrote:
> On 07/27/2016 02:57 PM, Laurent Pinchart wrote:
> > On Wednesday 27 Jul 2016 16:51:47 Kazunori Kobayashi wrote:
> >> Hi,
> >>
> >> I have a question about memory freeing by calling REQBUF(0) before all
> >> the dmabuf fds exported with VIDIOC_EXPBUF are closed.
> >>
> >> In calling REQBUF(0), videobuf2-core returns -EBUSY when the reference
> >> count of a vb2 buffer is more than 1. When dmabuf fds are not exported
> >> (usual V4L2_MEMORY_MMAP case), the check is no problem, but when dmabuf
> >> fds are exported and some of them are not closed (in other words the
> >> references to that memory are left), we cannot succeed in calling
> >> REQBUF(0) despite being able to free the memory after all the references
> >> are dropped.
> >>
> >> Actually REQBUF(0) does not force a vb2 buffer to be freed but decreases
> >> the refcount of it. Also all the vb2 memory allocators that support
> >> dmabuf exporting (dma-contig, dma-sg, vmalloc) implements memory freeing
> >> by release() of dma_buf_ops, so I think there is no need to return -EBUSY
> >> when exporting dmabuf fds.
> >>
> >> Could you please tell me what you think?
> >
> > I think you're right. vb2 allocates the vb2_buffer and the memops-specific
> > structure separately. videobuf2-core.c will free the vb2_buffer instance,
> > but won't touch the memops-specific structure or the buffer memory. Both
> > of these are reference-counted in the memops allocators. We could thus
> > allow REQBUFS(0) to proceed even when buffers have been exported (or at
> > least after fixing the small issues we'll run into, I have a feeling that
> > this is too easy to be true).
> >
> > Hans, Marek, any opinion on this ?
>
> What is the use-case for this? What you are doing here is to either free all
> existing buffers or reallocate buffers. We can decide to rely on
> refcounting, but then you would create a second set of buffers (when
> re-allocating) or leave a lot of unfreed memory behind. That's pretty hard
> on the memory usage.
Speaking of which, we have no way today to really limit memory usage. I wonder
whether we should try to integrate support for resource limits in V4L2.
> I think the EBUSY is there to protect the user against him/herself: i.e.
> don't call this unless you know all refs are closed.
>
> Given the typical large buffersizes we're talking about, I think that EBUSY
> makes sense.
>
> >> The code that I am talking about is in
> >>
> >> drivers/media/v4l2-core/videobuf2-core.c:
> >>if (*count == 0 || q->num_buffers != 0 || q->memory != memory) {
> >> /*
> >>* We already have buffers allocated, so first check if they
> >>* are not in use and can be freed.
> >>*/
> >> mutex_lock(&q->mmap_lock);
> >> if (q->memory == VB2_MEMORY_MMAP && __buffers_in_use(q)) {
> >> mutex_unlock(&q->mmap_lock);
> >> dprintk(1, "memory in use, cannot free\n");
> >> return -EBUSY;
> >> }
--
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
Re: [PATCH] Partly revert "[media] rc-core: allow calling rc_open with device not initialized"
On Sat, Jul 30, 2016 at 03:19:27PM +0200, Ole Ernst wrote: > This partly reverts commit 078600f514a12fd763ac84c86af68ef5b5267563. > > Due to the relocation of input_register_device() call, holding down a > button on an IR remote no longer resulted in repeated key down events. > > Signed-off-by: Ole Ernst Tested-by: Matthias Reichl I tested on Raspberry Pi model B with kernel 4.7.0, gpio-rc-recv, rc-hauppauge keymap and with this patch key repeat is working fine again. Thanks a lot for the quick fix! Hias > --- > drivers/media/rc/rc-main.c | 9 - > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c > index 8e7f292..26fd63b 100644 > --- a/drivers/media/rc/rc-main.c > +++ b/drivers/media/rc/rc-main.c > @@ -1460,6 +1460,10 @@ int rc_register_device(struct rc_dev *dev) > dev->input_dev->phys = dev->input_phys; > dev->input_dev->name = dev->input_name; > > + rc = input_register_device(dev->input_dev); > + if (rc) > + goto out_table; > + > /* >* Default delay of 250ms is too short for some protocols, especially >* since the timeout is currently set to 250ms. Increase it to 500ms, > @@ -1475,11 +1479,6 @@ int rc_register_device(struct rc_dev *dev) >*/ > dev->input_dev->rep[REP_PERIOD] = 125; > > - /* rc_open will be called here */ > - rc = input_register_device(dev->input_dev); > - if (rc) > - goto out_table; > - > path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL); > dev_info(&dev->dev, "%s as %s\n", > dev->input_name ?: "Unspecified device", path ?: "N/A"); > -- > 2.9.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 v3 5/9] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
Hi Hans,
On Mon, 2016-08-01 at 12:39 +0200, Hans Verkuil wrote:
> Hi Tiffany,
>
> On 08/01/2016 11:38 AM, Tiffany Lin wrote:
> > Hi Hans,
>
>
>
> >>> +static int vidioc_vdec_g_selection(struct file *file, void *priv,
> >>> + struct v4l2_selection *s)
> >>> +{
> >>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +
> >>> + if (V4L2_TYPE_IS_OUTPUT(s->type))
> >>> + return -EINVAL;
> >>> +
> >>> + if (s->target != V4L2_SEL_TGT_CROP)
> >>> + return -EINVAL;
> >>
> >> How does the cropping rectangle relate to the format size? There is no
> >> s_selection,
> >> so this doesn't make sense.
> >>
> > I want to return encoded crop information or real display region that
> > display driver could know where is padding region.
>
> Sorry, I don't understand this.
>
> This is a decoder, so based on the bitstream it decodes to a certain width
> and height. I assume that is what you refer to as coded_width and
> coded_height?
>
> If so, then what is the 'real display region' and how does it relate to the
> coded width/height?
>
> This is probably a terminology issue but I need to understand this before I
> can decide what should be done here.
>
We define coded_width and coded_height as frame buffer width and height.
Coded resolution is stream resolution in pixels aligned to codec format
and hardware requirements.
And we assign bytesperline as coded_width.
g_selection is for getting visible resolution for user space.
visible resolution - stream resolution of the visible picture, in
pixels, to be used for display purposes; must be smaller or equal to
coded resolution;
visible height - height for given visible resolution
visible width - width for given visible resolution
For my understand, g_fmt should return coded width/height in
pix_mp->width, pix_mp->height.
And bytesperline is coded with.
g_selection return visible width/height.
Is this understanding correct?
best regards,
Tiffany
> Regards,
>
> Hans
>
> > User space use s_fmt/g_fmt to set/get coded_width and coded_height, and
> > use g_crop to get real display region.
> > That's why I do not add s_selection.
> >
> >> Alternatively, it could be that you are really returning
> >> V4L2_SEL_TGT_COMPOSE_PADDED.
> >>
> >
> > V4L2_SEL_TGT_COMPOSE_PADDED means
> > "The active area and all padding pixels that are inserted or modified by
> > hardware."
> > But I just want to return active area to user space.
> >
> >>> +
> >>> + if (ctx->state < MTK_STATE_HEADER)
> >>> + return -EINVAL;
> >>> +
> >>> + if ((ctx->q_data[MTK_Q_DATA_SRC].fmt->fourcc == V4L2_PIX_FMT_H264) ||
> >>> + (ctx->q_data[MTK_Q_DATA_SRC].fmt->fourcc == V4L2_PIX_FMT_VP8) ||
> >>> + (ctx->q_data[MTK_Q_DATA_SRC].fmt->fourcc == V4L2_PIX_FMT_VP9)) {
> >>> +
> >>> + if (vdec_if_get_param(ctx, GET_PARAM_CROP_INFO, &(s->r))) {
> >>> + mtk_v4l2_debug(2,
> >>> + "[%d]Error!! Cannot get param :
> >>> GET_PARAM_CROP_INFO ERR",
> >>> + ctx->id);
> >>> + s->r.left = 0;
> >>> + s->r.top = 0;
> >>> + s->r.width = ctx->picinfo.buf_w;
> >>> + s->r.height = ctx->picinfo.buf_h;
> >>> + }
> >>> + mtk_v4l2_debug(2, "Cropping info: l=%d t=%d w=%d h=%d",
> >>> + s->r.left, s->r.top, s->r.width,
> >>> + s->r.height);
> >>> + } else {
> >>> + s->r.left = 0;
> >>> + s->r.top = 0;
> >>> + s->r.width = ctx->picinfo.pic_w;
> >>> + s->r.height = ctx->picinfo.pic_h;
> >>> + mtk_v4l2_debug(2, "Cropping info: w=%d h=%d fw=%d fh=%d",
> >>> + s->r.width, s->r.height, ctx->picinfo.buf_w,
> >>> + ctx->picinfo.buf_h);
> >>> + }
> >>> + return 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] doc-rst: Remove the media docbook
Hi Jani, Em Mon, 01 Aug 2016 12:57:32 +0300 Jani Nikula escreveu: > On Wed, 27 Jul 2016, Mauro Carvalho Chehab wrote: > > Now that all media documentation was converted to Sphinx, we > > should get rid of the old DocBook one, as we don't want people > > to submit patches against the old stuff. > > Mauro, judging from the discussions we've had over the past six months, > I never would have guessed media docs would be among the first docbooks > converted. Fantastic job! Thanks! Yeah, I opted to do the full conversion while all the discussions are fresh, as I found easier to remember what were the major issues and check if they were properly addressed on the conversion. Thanks for your and Markus support helping to address the issues! My general impression is that it is now a way easier to maintain the media documentation and make it more consistent than with DocBook. Thanks, Mauro -- 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
Functions and data structure cross references with Sphinx
There's one remaining major issue I noticed after the conversion of the media books to Sphinx: While sphinx complains if a cross-reference (using :ref:) points to an undefined reference, the same doesn't happen if the reference uses :c:func: and :c:type:. In practice, it means that, if we do some typo there, or if we forget to add the function/struct prototype (or use the wrong domain, like :cpp:), Sphinx won't generate the proper cross-reference, nor warning the user. That's specially bad for media, as, while we're using the c domain for the kAPI and driver-specific books, we need to use the cpp domain on the uAPI book - as the c domain doesn't allow multiple declarations for syscalls, and we have multiple pages for read, write, open, close, poll and ioctl. It would be good to have a way to run Sphinx on some "pedantic" mode or have something similar to xmlint that would be complaining about invalid c/cpp domain references. Thanks, Mauro -- 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 v2] cx23885: Add support for Hauppauge WinTV quadHD ATSC version
Add support fo the Hauppauge WinTV quadHD ATSC version.
IR support has not been provided, all 4 tuners, demodulators etc are working.
Further documentation can be found on Linux TV wiki.
Signed-Off-by: Stephen Backway
---
v2: Updated to use doc-rst
---
diff --git a/Documentation/media/v4l-drivers/cx23885-cardlist.rst
b/Documentation/media/v4l-drivers/cx23885-cardlist.rst
index ded3b91..d5eb682 100644
--- a/Documentation/media/v4l-drivers/cx23885-cardlist.rst
+++ b/Documentation/media/v4l-drivers/cx23885-cardlist.rst
@@ -60,3 +60,4 @@ cx23885 cards list
54 -> ViewCast 260e [1576:0260]
55 -> ViewCast 460e [1576:0460]
56 -> Hauppauge WinTV-QuadHD-DVB
[0070:6a28,0070:6b28]
+ 57 -> Hauppauge WinTV-quadHD (ATSC)
[0070:6a18,0070:6b18]
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 4abf50f..99ba8d6 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -770,6 +770,11 @@ struct cx23885_board cx23885_boards[] = {
.portb= CX23885_MPEG_DVB,
.portc= CX23885_MPEG_DVB,
},
+ [CX23885_BOARD_HAUPPAUGE_QUADHD_ATSC] = {
+ .name= "Hauppauge WinTV-QuadHD-ATSC",
+ .portb= CX23885_MPEG_DVB,
+ .portc= CX23885_MPEG_DVB,
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -1073,6 +1078,14 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0x0070,
.subdevice = 0x6b28,
.card = CX23885_BOARD_HAUPPAUGE_QUADHD_DVB, /* Tuner Pair 2 */
+ }, {
+ .subvendor = 0x0070,
+ .subdevice = 0x6a18,
+ .card = CX23885_BOARD_HAUPPAUGE_QUADHD_ATSC, /* Tuner Pair 1 */
+ }, {
+ .subvendor = 0x0070,
+ .subdevice = 0x6b18,
+ .card = CX23885_BOARD_HAUPPAUGE_QUADHD_ATSC, /* Tuner Pair 2 */
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -1278,6 +1291,18 @@ static void hauppauge_eeprom(struct cx23885_dev
*dev, u8 *eeprom_data)
/* WinTV-QuadHD (DVB) Tuner Pair 2 (PCIe, IR, half height,
DVB-T/T2/C, DVB-T/T2/C */
break;
+ case 165100:
+ /*
+ * WinTV-QuadHD (ATSC) Tuner Pair 1 (PCIe, IR, half height,
+ * ATSC, ATSC
+ */
+ break;
+ case 165101:
+ /*
+ * WinTV-QuadHD (DVB) Tuner Pair 2 (PCIe, IR, half height,
+ * ATSC, ATSC
+ */
+ break;
default:
printk(KERN_WARNING "%s: warning: "
"unknown hauppauge model #%d\n",
@@ -1751,6 +1776,7 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
break;
case CX23885_BOARD_HAUPPAUGE_HVR5525:
case CX23885_BOARD_HAUPPAUGE_QUADHD_DVB:
+ case CX23885_BOARD_HAUPPAUGE_QUADHD_ATSC:
/*
* HVR5525 GPIO Details:
* GPIO-00 IR_WIDE
@@ -1826,6 +1852,7 @@ int cx23885_ir_init(struct cx23885_dev *dev)
case CX23885_BOARD_HAUPPAUGE_HVR1255_22111:
case CX23885_BOARD_HAUPPAUGE_HVR1210:
case CX23885_BOARD_HAUPPAUGE_QUADHD_DVB:
+ case CX23885_BOARD_HAUPPAUGE_QUADHD_ATSC:
/* FIXME: Implement me */
break;
case CX23885_BOARD_HAUPPAUGE_HVR1270:
@@ -2025,6 +2052,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
case CX23885_BOARD_HAUPPAUGE_IMPACTVCBE:
case CX23885_BOARD_HAUPPAUGE_HVR5525:
case CX23885_BOARD_HAUPPAUGE_QUADHD_DVB:
+ case CX23885_BOARD_HAUPPAUGE_QUADHD_ATSC:
if (dev->i2c_bus[0].i2c_rc == 0)
hauppauge_eeprom(dev, eeprom+0xc0);
break;
@@ -2171,6 +2199,7 @@ void cx23885_card_setup(struct cx23885_dev *dev)
ts2->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
case CX23885_BOARD_HAUPPAUGE_QUADHD_DVB:
+ case CX23885_BOARD_HAUPPAUGE_QUADHD_ATSC:
ts1->gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index e5748a9..c5daa23 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -74,6 +74,7 @@
#include "sp2.h"
#include "m88ds3103.h"
#include "m88rs6000t.h"
+#include "lgdt3306a.h"
static unsigned int debug;
@@ -574,6 +575,30 @@ static struct stb6100_config prof_8000_stb6100_config = {
.refclock = 2700,
};
+static struct lgdt3306a_config hauppauge_quadHD_ATSC_a_config = {
+ .i2c_addr = 0x59,
+ .qam_if_khz = 4000,
+ .vsb_if_khz = 3250,
+ .deny_i2c_rptr = 1, /* Disabled */
+ .spectral_inversion = 0, /* Disabled */
+ .mpeg_mode = LGDT3306A_MPEG_SERIAL,
+ .tpclk_edge = LGDT3306A_TPCLK_RISING_EDGE,
+ .tpvalid_polarity = LGDT3306A_TP_VALID_HIGH,
+ .xtalMHz= 25, /* 24 or 25 */
+};
+
+static struct lgdt3306a_config hauppauge_quadHD_ATSC_b_config = {
+ .i2c_addr = 0x0e,
+ .qam_if_khz = 4000,
+ .vsb_if_khz = 3250,
+ .deny_i2c_rptr = 1, /* Disabled */
+ .spectral_inversion = 0, /* Disabled */
+ .mpeg_mode = LGDT3306A_MPEG_SERIAL,
+ .tpclk_edge
Re: Memory freeing when dmabuf fds are exported with VIDIOC_EXPBUF
On 07/27/2016 02:57 PM, Laurent Pinchart wrote:
> Hello Kobayashi-san,
>
> (CC'ing Hans Verkuil and Marek Szyprowski)
>
> On Wednesday 27 Jul 2016 16:51:47 Kazunori Kobayashi wrote:
>> Hi,
>>
>> I have a question about memory freeing by calling REQBUF(0) before all the
>> dmabuf fds exported with VIDIOC_EXPBUF are closed.
>>
>> In calling REQBUF(0), videobuf2-core returns -EBUSY when the reference count
>> of a vb2 buffer is more than 1. When dmabuf fds are not exported (usual
>> V4L2_MEMORY_MMAP case), the check is no problem, but when dmabuf fds are
>> exported and some of them are not closed (in other words the references to
>> that memory are left), we cannot succeed in calling REQBUF(0) despite being
>> able to free the memory after all the references are dropped.
>>
>> Actually REQBUF(0) does not force a vb2 buffer to be freed but decreases
>> the refcount of it. Also all the vb2 memory allocators that support dmabuf
>> exporting (dma-contig, dma-sg, vmalloc) implements memory freeing by
>> release() of dma_buf_ops, so I think there is no need to return -EBUSY when
>> exporting dmabuf fds.
>>
>> Could you please tell me what you think?
>
> I think you're right. vb2 allocates the vb2_buffer and the memops-specific
> structure separately. videobuf2-core.c will free the vb2_buffer instance, but
> won't touch the memops-specific structure or the buffer memory. Both of these
> are reference-counted in the memops allocators. We could thus allow
> REQBUFS(0)
> to proceed even when buffers have been exported (or at least after fixing the
> small issues we'll run into, I have a feeling that this is too easy to be
> true).
>
> Hans, Marek, any opinion on this ?
What is the use-case for this? What you are doing here is to either free all
existing buffers or reallocate buffers. We can decide to rely on refcounting,
but then you would create a second set of buffers (when re-allocating) or
leave a lot of unfreed memory behind. That's pretty hard on the memory usage.
I think the EBUSY is there to protect the user against him/herself: i.e. don't
call this unless you know all refs are closed.
Given the typical large buffersizes we're talking about, I think that EBUSY
makes sense.
Regards,
Hans
>
>> The code that I am talking about is in
>> drivers/media/v4l2-core/videobuf2-core.c:
>>
>>if (*count == 0 || q->num_buffers != 0 || q->memory != memory) {
>> /*
>>* We already have buffers allocated, so first check if they
>>* are not in use and can be freed.
>>*/
>> mutex_lock(&q->mmap_lock);
>> if (q->memory == VB2_MEMORY_MMAP && __buffers_in_use(q)) {
>> mutex_unlock(&q->mmap_lock);
>> dprintk(1, "memory in use, cannot free\n");
>> return -EBUSY;
>> }
>
--
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 v3 5/9] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
Hi Tiffany,
On 08/01/2016 11:38 AM, Tiffany Lin wrote:
> Hi Hans,
>>> +static int vidioc_vdec_g_selection(struct file *file, void *priv,
>>> + struct v4l2_selection *s)
>>> +{
>>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +
>>> + if (V4L2_TYPE_IS_OUTPUT(s->type))
>>> + return -EINVAL;
>>> +
>>> + if (s->target != V4L2_SEL_TGT_CROP)
>>> + return -EINVAL;
>>
>> How does the cropping rectangle relate to the format size? There is no
>> s_selection,
>> so this doesn't make sense.
>>
> I want to return encoded crop information or real display region that
> display driver could know where is padding region.
Sorry, I don't understand this.
This is a decoder, so based on the bitstream it decodes to a certain width
and height. I assume that is what you refer to as coded_width and coded_height?
If so, then what is the 'real display region' and how does it relate to the
coded width/height?
This is probably a terminology issue but I need to understand this before I
can decide what should be done here.
Regards,
Hans
> User space use s_fmt/g_fmt to set/get coded_width and coded_height, and
> use g_crop to get real display region.
> That's why I do not add s_selection.
>
>> Alternatively, it could be that you are really returning
>> V4L2_SEL_TGT_COMPOSE_PADDED.
>>
>
> V4L2_SEL_TGT_COMPOSE_PADDED means
> "The active area and all padding pixels that are inserted or modified by
> hardware."
> But I just want to return active area to user space.
>
>>> +
>>> + if (ctx->state < MTK_STATE_HEADER)
>>> + return -EINVAL;
>>> +
>>> + if ((ctx->q_data[MTK_Q_DATA_SRC].fmt->fourcc == V4L2_PIX_FMT_H264) ||
>>> + (ctx->q_data[MTK_Q_DATA_SRC].fmt->fourcc == V4L2_PIX_FMT_VP8) ||
>>> + (ctx->q_data[MTK_Q_DATA_SRC].fmt->fourcc == V4L2_PIX_FMT_VP9)) {
>>> +
>>> + if (vdec_if_get_param(ctx, GET_PARAM_CROP_INFO, &(s->r))) {
>>> + mtk_v4l2_debug(2,
>>> + "[%d]Error!! Cannot get param :
>>> GET_PARAM_CROP_INFO ERR",
>>> + ctx->id);
>>> + s->r.left = 0;
>>> + s->r.top = 0;
>>> + s->r.width = ctx->picinfo.buf_w;
>>> + s->r.height = ctx->picinfo.buf_h;
>>> + }
>>> + mtk_v4l2_debug(2, "Cropping info: l=%d t=%d w=%d h=%d",
>>> + s->r.left, s->r.top, s->r.width,
>>> + s->r.height);
>>> + } else {
>>> + s->r.left = 0;
>>> + s->r.top = 0;
>>> + s->r.width = ctx->picinfo.pic_w;
>>> + s->r.height = ctx->picinfo.pic_h;
>>> + mtk_v4l2_debug(2, "Cropping info: w=%d h=%d fw=%d fh=%d",
>>> + s->r.width, s->r.height, ctx->picinfo.buf_w,
>>> + ctx->picinfo.buf_h);
>>> + }
>>> + return 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
[PATCHv2] v4l2-common: add s_selection helper function
Checking the selection constraint flags is often forgotten by drivers,
especially
if the selection code just clamps the rectangle to the minimum and maximum
allowed
rectangles.
This patch adds a simple helper function that checks the adjusted rectangle
against
the constraint flags and either returns -ERANGE if it doesn't fit, or fills in
the
new rectangle and returns 0.
It also adds a small helper function to v4l2-rect.h to check if one rectangle
fits
inside another.
Signed-off-by: Hans Verkuil
---
v2:
- renamed r1/r2 to inner/outer
- moved documentation to source
---
diff --git a/drivers/media/v4l2-core/v4l2-common.c
b/drivers/media/v4l2-core/v4l2-common.c
index 5b80850..f7c34f6 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -61,6 +61,7 @@
#include
#include
#include
+#include
#include
@@ -371,6 +372,30 @@ void v4l_bound_align_image(u32 *w, unsigned int wmin,
unsigned int wmax,
}
EXPORT_SYMBOL_GPL(v4l_bound_align_image);
+/**
+ * v4l2_s_selection - Helper to check adjusted rectangle against constraint
flags
+ *
+ * @s: pointer to &struct v4l2_selection containing the original rectangle
+ * @r: pointer to &struct v4l2_rect containing the adjusted rectangle.
+ *
+ * Returns -ERANGE if the adjusted rectangle doesn't fit the constraints
+ * or 0 if it is fine. On success it sets @s->r to @r.
+ */
+int v4l2_s_selection(struct v4l2_selection *s, const struct v4l2_rect *r)
+{
+ /* The original rect must lay inside the adjusted one */
+ if ((s->flags & V4L2_SEL_FLAG_GE) &&
+ !v4l2_rect_is_inside(&s->r, r))
+ return -ERANGE;
+ /* The adjusted rect must lay inside the original one */
+ if ((s->flags & V4L2_SEL_FLAG_LE) &&
+ !v4l2_rect_is_inside(r, &s->r))
+ return -ERANGE;
+ s->r = *r;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_s_selection);
+
const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
const struct v4l2_discrete_probe *probe,
s32 width, s32 height)
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 350cbf9..226e0cf 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -246,6 +246,8 @@ void v4l_bound_align_image(unsigned int *w, unsigned int
wmin,
unsigned int hmax, unsigned int halign,
unsigned int salign);
+int v4l2_s_selection(struct v4l2_selection *s, const struct v4l2_rect *r);
+
struct v4l2_discrete_probe {
const struct v4l2_frmsize_discrete *sizes;
int num_sizes;
diff --git a/include/media/v4l2-rect.h b/include/media/v4l2-rect.h
index d2125f0..6d9de07 100644
--- a/include/media/v4l2-rect.h
+++ b/include/media/v4l2-rect.h
@@ -95,6 +95,21 @@ static inline bool v4l2_rect_same_size(const struct
v4l2_rect *r1,
}
/**
+ * v4l2_rect_is_inside() - return true if inner is inside outer
+ * @inner: rectangle.
+ * @outer: rectangle.
+ *
+ * Return true if @inner fits inside @outer.
+ */
+static inline bool v4l2_rect_is_inside(const struct v4l2_rect *inner,
+ const struct v4l2_rect *outer)
+{
+ return inner->left >= outer->left && inner->top >= outer->top &&
+ inner->left + inner->width <= outer->left + outer->width &&
+ inner->top + inner->height <= outer->top + outer->height;
+}
+
+/**
* v4l2_rect_intersect() - calculate the intersection of two rects.
* @r: intersection of @r1 and @r2.
* @r1: rectangle.
--
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
linux-media@vger.kernel.org
Fix typo where logical AND was used instead of bitwise AND.
Signed-off-by: Hans Verkuil
Reported-by: David Binderman
---
diff --git a/include/linux/cec-funcs.h b/include/linux/cec-funcs.h
index 82c3d3b..9e054aa 100644
--- a/include/linux/cec-funcs.h
+++ b/include/linux/cec-funcs.h
@@ -227,7 +227,7 @@ static inline void cec_set_digital_service_id(__u8 *msg,
if (digital->service_id_method == CEC_OP_SERVICE_ID_METHOD_BY_CHANNEL) {
*msg++ = (digital->channel.channel_number_fmt << 2) |
(digital->channel.major >> 8);
- *msg++ = digital->channel.major && 0xff;
+ *msg++ = digital->channel.major & 0xff;
*msg++ = digital->channel.minor >> 8;
*msg++ = digital->channel.minor & 0xff;
*msg++ = 0;
@@ -1277,7 +1277,7 @@ static inline void cec_msg_user_control_pressed(struct
cec_msg *msg,
msg->len += 4;
msg->msg[3] = (ui_cmd->channel_identifier.channel_number_fmt <<
2) |
(ui_cmd->channel_identifier.major >> 8);
- msg->msg[4] = ui_cmd->channel_identifier.major && 0xff;
+ msg->msg[4] = ui_cmd->channel_identifier.major & 0xff;
msg->msg[5] = ui_cmd->channel_identifier.minor >> 8;
msg->msg[6] = ui_cmd->channel_identifier.minor & 0xff;
break;
--
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
include/linux/cec-funcs.h:1280: suspicious expression ?
Hello there, include/linux/cec-funcs.h:1280:50: warning: logical ‘and’ applied to non-boolean constant [-Wlogical-op] Source code is msg->msg[4] = ui_cmd->channel_identifier.major && 0xff; Maybe better code msg->msg[4] = ui_cmd->channel_identifier.major & 0xff; Regards David Binderman -- 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] doc-rst: Remove the media docbook
On Wed, 27 Jul 2016, Mauro Carvalho Chehab wrote: > Now that all media documentation was converted to Sphinx, we > should get rid of the old DocBook one, as we don't want people > to submit patches against the old stuff. Mauro, judging from the discussions we've had over the past six months, I never would have guessed media docs would be among the first docbooks converted. Fantastic job! BR, Jani. -- Jani Nikula, Intel Open Source Technology Center -- 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 v7 1/2] [media] atmel-isc: add the Image Sensor Controller code
Hi Songjun,
Some more comments below. Except for one in the open/release functions
it's all small things.
On 07/29/2016 09:54 AM, Songjun Wu wrote:
> Add driver for the Image Sensor Controller. It manages
> incoming data from a parallel based CMOS/CCD sensor.
> It has an internal image processor, also integrates a
> triple channel direct memory access controller master
> interface.
>
> Signed-off-by: Songjun Wu
> ---
>
> Changes in v7:
> - Add enum_framesizes and enum_frameintervals.
> - Call s_stream(0) when stream start fail.
> - Fill the device_caps field of struct video_device
> with V4L2_CAP_STREAMING and V4L2_CAP_VIDEO_CAPTURE.
> - Initialize the dev of struct vb2_queue.
> - Set field to FIELD_NONE if the pix field is not supported.
> - Return the result directly when call g/s_parm of subdev.
>
> Changes in v6: None
> Changes in v5:
> - Modify the macro definition and the related code.
>
> Changes in v4:
> - Modify the isc clock code since the dt is changed.
>
> Changes in v3:
> - Add pm runtime feature.
> - Modify the isc clock code since the dt is changed.
>
> Changes in v2:
> - Add "depends on COMMON_CLK" and "VIDEO_V4L2_SUBDEV_API"
> in Kconfig file.
> - Correct typos and coding style according to Laurent's remarks
> - Delete the loop while in 'isc_clk_enable' function.
> - Replace 'hsync_active', 'vsync_active' and 'pclk_sample'
> with 'pfe_cfg0' in struct isc_subdev_entity.
> - Add the code to support VIDIOC_CREATE_BUFS in
> 'isc_queue_setup' function.
> - Invoke isc_config to configure register in
> 'isc_start_streaming' function.
> - Add the struct completion 'comp' to synchronize with
> the frame end interrupt in 'isc_stop_streaming' function.
> - Check the return value of the clk_prepare_enable
> in 'isc_open' function.
> - Set the default format in 'isc_open' function.
> - Add an exit condition in the loop while in 'isc_config'.
> - Delete the hardware setup operation in 'isc_set_format'.
> - Refuse format modification during streaming
> in 'isc_s_fmt_vid_cap' function.
> - Invoke v4l2_subdev_alloc_pad_config to allocate and
> initialize the pad config in 'isc_async_complete' function.
> - Remove the '.owner = THIS_MODULE,' in atmel_isc_driver.
> - Replace the module_platform_driver_probe() with
> module_platform_driver().
>
> drivers/media/platform/Kconfig|1 +
> drivers/media/platform/Makefile |2 +
> drivers/media/platform/atmel/Kconfig |9 +
> drivers/media/platform/atmel/Makefile |1 +
> drivers/media/platform/atmel/atmel-isc-regs.h | 165 +++
> drivers/media/platform/atmel/atmel-isc.c | 1611
> +
> 6 files changed, 1789 insertions(+)
> create mode 100644 drivers/media/platform/atmel/Kconfig
> create mode 100644 drivers/media/platform/atmel/Makefile
> create mode 100644 drivers/media/platform/atmel/atmel-isc-regs.h
> create mode 100644 drivers/media/platform/atmel/atmel-isc.c
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.c
> b/drivers/media/platform/atmel/atmel-isc.c
> new file mode 100644
> index 000..f2ef664
> --- /dev/null
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -0,0 +1,1611 @@
> +static unsigned int sensor_preferred = 1;
> +module_param(sensor_preferred, uint, S_IRUGO|S_IWUSR);
> +MODULE_PARM_DESC(sensor_preferred,
> + "Sensor is preferred to output the specified format (1-on
> 0-off) default 1");
I have no idea what this means. Can you elaborate? Why would you want to set
this to 0?
> +static inline bool sensor_is_preferred(const struct isc_format *isc_fmt)
> +{
> + if ((sensor_preferred && isc_fmt->sd_support) ||
> + !isc_fmt->isc_support)
I'd just do:
return (sensor_preferred && isc_fmt->sd_support) ||
!isc_fmt->isc_support;
> + return true;
> + else
> + return false;
> +}
> +
> +static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
> + struct isc_format **current_fmt, u32 *code)
> +{
> + struct isc_format *isc_fmt;
> + struct v4l2_pix_format *pixfmt = &f->fmt.pix;
> + struct v4l2_subdev_format format = {
> + .which = V4L2_SUBDEV_FORMAT_TRY,
> + };
> + u32 mbus_code;
> + int ret;
> +
> + if (f->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + return -EINVAL;
> +
> + isc_fmt = find_format_by_fourcc(isc, pixfmt->pixelformat);
> + if (!isc_fmt) {
> + v4l2_warn(&isc->v4l2_dev, "Format 0x%x not found\n",
> + pixfmt->pixelformat);
> + isc_fmt = isc->user_formats[isc->num_user_formats - 1];
> + pixfmt->pixelformat = isc_fmt->fourcc;
> + }
> +
> + /* Limit to Atmel ISC hardware capabilities */
> + if (pixfmt->width > ISC_MAX_SUPPORT_WIDTH)
> + pixfmt->width = ISC_MAX_SUPPORT_WIDTH;
> + if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
> + pixfmt->height = ISC
Re: [PATCH v3 5/9] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
Hi Hans,
On Fri, 2016-07-08 at 13:06 +0200, Hans Verkuil wrote:
> On 05/30/2016 02:29 PM, Tiffany Lin wrote:
> > Add v4l2 layer decoder driver for MT8173
> >
> > Signed-off-by: Tiffany Lin
> > ---
> > drivers/media/platform/mtk-vcodec/Makefile | 10 +-
> > drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 1348
> >
> > drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h | 88 ++
> > .../media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 408 ++
> > .../media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 206 +++
> > .../media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 28 +
> > drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 88 +-
> > .../media/platform/mtk-vcodec/mtk_vcodec_intr.c|4 +-
> > .../media/platform/mtk-vcodec/mtk_vcodec_intr.h|2 +-
> > .../media/platform/mtk-vcodec/mtk_vcodec_util.c| 31 +-
> > .../media/platform/mtk-vcodec/mtk_vcodec_util.h|7 +-
> > drivers/media/platform/mtk-vcodec/vdec_drv_base.h | 56 +
> > drivers/media/platform/mtk-vcodec/vdec_drv_if.c| 107 ++
> > drivers/media/platform/mtk-vcodec/vdec_drv_if.h| 101 ++
> > drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h | 103 ++
> > 15 files changed, 2569 insertions(+), 18 deletions(-)
> > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
> > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
> > create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.h
> > create mode 100644 drivers/media/platform/mtk-vcodec/vdec_drv_base.h
> > create mode 100644 drivers/media/platform/mtk-vcodec/vdec_drv_if.c
> > create mode 100644 drivers/media/platform/mtk-vcodec/vdec_drv_if.h
> > create mode 100644 drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
> >
> > diff --git a/drivers/media/platform/mtk-vcodec/Makefile
> > b/drivers/media/platform/mtk-vcodec/Makefile
> > index dc5cb00..4c8ed2f 100644
> > --- a/drivers/media/platform/mtk-vcodec/Makefile
> > +++ b/drivers/media/platform/mtk-vcodec/Makefile
> > @@ -1,7 +1,13 @@
> >
> >
> > -obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-enc.o mtk-vcodec-common.o
> > -
> > +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-dec.o \
> > + mtk-vcodec-enc.o \
> > + mtk-vcodec-common.o
> > +
> > +mtk-vcodec-dec-y := mtk_vcodec_dec_drv.o \
> > + vdec_drv_if.o \
> > + mtk_vcodec_dec.o \
> > + mtk_vcodec_dec_pm.o \
> >
> >
> > mtk-vcodec-enc-y := venc/venc_vp8_if.o \
> > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> > new file mode 100644
> > index 000..792858a
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
> > @@ -0,0 +1,1348 @@
> > +/*
> > +* Copyright (c) 2016 MediaTek Inc.
> > +* Author: PC Chen
> > +* Tiffany Lin
> > +*
> > +* This program is free software; you can redistribute it and/or modify
> > +* it under the terms of the GNU General Public License version 2 as
> > +* published by the Free Software Foundation.
> > +*
> > +* This program is distributed in the hope that it will be useful,
> > +* but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > +* GNU General Public License for more details.
> > +*/
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include "mtk_vcodec_drv.h"
> > +#include "mtk_vcodec_dec.h"
> > +#include "mtk_vcodec_intr.h"
> > +#include "mtk_vcodec_util.h"
> > +#include "vdec_drv_if.h"
> > +#include "mtk_vcodec_dec_pm.h"
> > +
> > +#define OUT_FMT_IDX0
> > +#define CAP_FMT_IDX3
> > +
> > +#define MTK_VDEC_MIN_W 64U
> > +#define MTK_VDEC_MIN_H 64U
> > +#define DFT_CFG_WIDTH MTK_VDEC_MIN_W
> > +#define DFT_CFG_HEIGHT MTK_VDEC_MIN_H
> > +
> > +static struct mtk_video_fmt mtk_video_formats[] = {
> > + {
> > + .fourcc = V4L2_PIX_FMT_H264,
> > + .type = MTK_FMT_DEC,
> > + .num_planes = 1,
> > + },
> > + {
> > + .fourcc = V4L2_PIX_FMT_VP8,
> > + .type = MTK_FMT_DEC,
> > + .num_planes = 1,
> > + },
> > + {
> > + .fourcc = V4L2_PIX_FMT_VP9,
> > + .type = MTK_FMT_DEC,
> > + .num_planes = 1,
> > + },
> > + {
> > + .fourcc = V4L2_PIX_FMT_MT21,
> > + .type = MTK_FMT_FRAME,
> > + .num_planes = 2,
> > + },
> > +};
> > +
> > +static const struct mtk_codec_framesizes mtk_vdec_framesizes[] = {
> > + {
> > + .fourcc = V4L2_PIX_FMT_H264,
> > + .stepwise = { MTK_VDEC_MIN_W, MTK_VDEC_MAX_W, 16,
> > + MTK_VDEC_MIN_H, MTK_VDEC_MAX_H, 16 },
> > + },
> > + {
> >
Re: [PATCH 3/3] soc-camera/sh_mobile_csi2: remove unused driver
Hi Hans, On Monday 01 Aug 2016 11:07:03 Hans Verkuil wrote: > On 08/01/2016 11:01 AM, Laurent Pinchart wrote: > > On Monday 01 Aug 2016 10:56:21 Hans Verkuil wrote: > >> On 08/01/2016 10:34 AM, Laurent Pinchart wrote: > >>> On Monday 01 Aug 2016 09:54:25 Hans Verkuil wrote: > From: Hans Verkuil > > The sh_mobile_csi2 isn't used anymore (was it ever?), so remove it. > Especially since the soc-camera framework is being deprecated. > > Signed-off-by: Hans Verkuil > Cc: Laurent Pinchart > Cc: Guennadi Liakhovetski > >>> > >>> Acked-by: Laurent Pinchart > >>> > --- > > drivers/media/platform/soc_camera/Kconfig | 7 - > drivers/media/platform/soc_camera/Makefile | 1 - > .../platform/soc_camera/sh_mobile_ceu_camera.c | 229 +--- > drivers/media/platform/soc_camera/sh_mobile_csi2.c | 400 - > include/media/drv-intf/sh_mobile_ceu.h | 1 - > include/media/drv-intf/sh_mobile_csi2.h| 48 --- > 6 files changed, 10 insertions(+), 676 deletions(-) > delete mode 100644 drivers/media/platform/soc_camera/sh_mobile_csi2.c > delete mode 100644 include/media/drv-intf/sh_mobile_c > >>> > >>> Any plan for the sh_mobile_ceu_camera driver by the way ? > >> > >> Yes. > >> > >> The idea is to replace the remaining soc-camera drivers by 'proper' > >> drivers (Robert Jarzmik is working on that for the pxa_camera driver, and > >> I am working on the atmel-isi driver). > >> > >> Once that's done the only soc-camera driver left is the > >> sh_mobile_ceu_camera driver. > >> > >> At that moment the soc-camera framework will be folded into the > >> sh_mobile_ceu_camera driver and it will cease to exist as a framework. > >> It's just a very complex driver. I plan on refactoring it further, > >> removing dead code etc. > >> > >> My original plan was to replace the sh_mobile_ceu_camera driver by a > >> 'proper' driver as well, but it was next to impossible to do that. The > >> fact that it didn't use the device tree and the complexity with scaling > >> and cropping and the close dependency on soc-camera just made this a no > >> go (at least not something I was willing to spend more time on). > >> > >> I think this alternative approach has the best chance of succeeding. > > > > Are there really users of the CEU driver ? There are a few ARM-based > > Renesas platforms that include the CEU, but they're pretty old now and > > don't support the CEU in mainline. As far as I know only arch/sh still > > makes use of the CEU driver. > > Well, I can still test it. And it is still in the arch/sh code. It's not > really my decision since I just don't know enough whether or not it can be > removed. > > You are probably better placed to figure that out. Since arch/sh got taken over by the J-Core developers, not really ;-) What I know is that there's very very little interest at Renesas for SuperH support. > >> I'm not sure yet what we'll do with the soc-camera sensors. I > >> experimented a bit with extracting them from soc-camera, but for most > >> it's not easy to do so. Something to look at later. > > > > It would be a shame to remove them all, but it also depends on whether we > > can find hardware for testing. > > Well, they always remain in git, but I know what you mean. Anyway, that's > for later. -- 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
Re: [PATCH] v4l2-common: add s_selection helper function
On 08/01/2016 10:57 AM, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Monday 01 Aug 2016 10:45:30 Hans Verkuil wrote:
>> Checking the selection constraint flags is often forgotten by drivers,
>> especially if the selection code just clamps the rectangle to the minimum
>> and maximum allowed rectangles.
>>
>> This patch adds a simple helper function that checks the adjusted rectangle
>> against the constraint flags and either returns -ERANGE if it doesn't fit,
>> or fills in the new rectangle and returns 0.
>>
>> It also adds a small helper function to v4l2-rect.h to check if one
>> rectangle fits inside another.
>>
>> Signed-off-by: Hans Verkuil
>> ---
>> diff --git a/drivers/media/v4l2-core/v4l2-common.c
>> b/drivers/media/v4l2-core/v4l2-common.c index 5b80850..a2e5119 100644
>> --- a/drivers/media/v4l2-core/v4l2-common.c
>> +++ b/drivers/media/v4l2-core/v4l2-common.c
>> @@ -61,6 +61,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -371,6 +372,21 @@ void v4l_bound_align_image(u32 *w, unsigned int wmin,
>> unsigned int wmax, }
>> EXPORT_SYMBOL_GPL(v4l_bound_align_image);
>>
>> +int v4l2_s_selection(struct v4l2_selection *s, const struct v4l2_rect *r)
>> +{
>> +/* The original rect must lay inside the adjusted one */
>> +if ((s->flags & V4L2_SEL_FLAG_GE) &&
>> +!v4l2_rect_is_inside(&s->r, r))
>> +return -ERANGE;
>> +/* The adjusted rect must lay inside the original one */
>> +if ((s->flags & V4L2_SEL_FLAG_LE) &&
>> +!v4l2_rect_is_inside(r, &s->r))
>> +return -ERANGE;
>
> I'd like to see how this function is used in drivers.
See my comments here:
https://patchwork.linuxtv.org/patch/35794/
>
>> +s->r = *r;
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_s_selection);
>> +
>> const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
>> const struct v4l2_discrete_probe *probe,
>> s32 width, s32 height)
>> diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
>> index 350cbf9..cfa9cbf 100644
>> --- a/include/media/v4l2-common.h
>> +++ b/include/media/v4l2-common.h
>> @@ -246,6 +246,17 @@ void v4l_bound_align_image(unsigned int *w, unsigned
>> int wmin, unsigned int hmax, unsigned int halign,
>> unsigned int salign);
>>
>> +/**
>> + * v4l2_s_selection - Helper to check adjusted rectangle against constraint
>> flags
>> + *
>> + * @s: pointer to &struct v4l2_selection containing the original rectangle
>> + * @r: pointer to &struct v4l2_rect containing the adjusted rectangle.
>> + *
>> + * Returns -ERANGE if the adjusted rectangle doesn't fit the constraints
>> + * or 0 if it is fine. On success it sets @s->r to @r.
>> + */
>
> Part of the functions are documented in the header and part in the
> implementation. We need to pick one option, and I prefer the latter one
> (which
> is also more consistent with how functions are documented in most subsystems).
I'll move it.
>
>> +int v4l2_s_selection(struct v4l2_selection *s, const struct v4l2_rect *r);
>> +
>> struct v4l2_discrete_probe {
>> const struct v4l2_frmsize_discrete *sizes;
>> int num_sizes;
>> diff --git a/include/media/v4l2-rect.h b/include/media/v4l2-rect.h
>> index d2125f0..858c8cb 100644
>> --- a/include/media/v4l2-rect.h
>> +++ b/include/media/v4l2-rect.h
>> @@ -95,6 +95,21 @@ static inline bool v4l2_rect_same_size(const struct
>> v4l2_rect *r1, }
>>
>> /**
>> + * v4l2_rect_is_inside() - return true if r1 is inside r2
>> + * @r1: rectangle.
>> + * @r2: rectangle.
>> + *
>> + * Return true if r1 fits inside r2.
>> + */
>> +static inline bool v4l2_rect_is_inside(const struct v4l2_rect *r1,
>> + const struct v4l2_rect *r2)
>
> How about calling the arguments inner and outer to make the purpose of each
> argument more explicit from the function prototype ?
Much better, thanks.
> Also, I would name the function v4l2_rect_is_contained(), or possibly
> v4l2_rect_contains() in which case the arguments should be switched. It
> should
> also be noted that C doesn't provide support for function overloading so we
> can't have
>
> /* Rectangle contains rectangle */
> bool v4l2_rect_contains(const struct v4l2_rect *outer,
> const struct v4l2_rect *inner);
> /* Rectangle contains point */
> bool v4l2_rect_contains(const struct v4l2_rect *rect,
> unsigned int x, unsigned int y);
>
> Maybe we should thus name the function v4l2_rect_contains_rect() in prevision
> for a future v4l2_rect_contains_point() ?
I prefer is_inside. The name implies that one rect is inside another
whereas 'contains' just suggests that some object is contained by a rect.
Also, the 'inside' terminology is already used in v4l2-rect.h.
>
>> +{
>> +return r1->left >= r2->left && r1->top >= r2->top &&
>> + r1->left + r1->width <= r2->le
Re: [PATCH 3/3] soc-camera/sh_mobile_csi2: remove unused driver
On 08/01/2016 11:01 AM, Laurent Pinchart wrote: > Hi Hans, > > On Monday 01 Aug 2016 10:56:21 Hans Verkuil wrote: >> On 08/01/2016 10:34 AM, Laurent Pinchart wrote: >>> On Monday 01 Aug 2016 09:54:25 Hans Verkuil wrote: From: Hans Verkuil The sh_mobile_csi2 isn't used anymore (was it ever?), so remove it. Especially since the soc-camera framework is being deprecated. Signed-off-by: Hans Verkuil Cc: Laurent Pinchart Cc: Guennadi Liakhovetski >>> >>> Acked-by: Laurent Pinchart >>> --- drivers/media/platform/soc_camera/Kconfig | 7 - drivers/media/platform/soc_camera/Makefile | 1 - .../platform/soc_camera/sh_mobile_ceu_camera.c | 229 +--- drivers/media/platform/soc_camera/sh_mobile_csi2.c | 400 - include/media/drv-intf/sh_mobile_ceu.h | 1 - include/media/drv-intf/sh_mobile_csi2.h| 48 --- 6 files changed, 10 insertions(+), 676 deletions(-) delete mode 100644 drivers/media/platform/soc_camera/sh_mobile_csi2.c delete mode 100644 include/media/drv-intf/sh_mobile_c >>> >>> Any plan for the sh_mobile_ceu_camera driver by the way ? >> >> Yes. >> >> The idea is to replace the remaining soc-camera drivers by 'proper' drivers >> (Robert Jarzmik is working on that for the pxa_camera driver, and I am >> working on the atmel-isi driver). >> >> Once that's done the only soc-camera driver left is the sh_mobile_ceu_camera >> driver. >> >> At that moment the soc-camera framework will be folded into the >> sh_mobile_ceu_camera driver and it will cease to exist as a framework. It's >> just a very complex driver. I plan on refactoring it further, removing dead >> code etc. >> >> My original plan was to replace the sh_mobile_ceu_camera driver by a >> 'proper' driver as well, but it was next to impossible to do that. The fact >> that it didn't use the device tree and the complexity with scaling and >> cropping and the close dependency on soc-camera just made this a no go (at >> least not something I was willing to spend more time on). >> >> I think this alternative approach has the best chance of succeeding. > > Are there really users of the CEU driver ? There are a few ARM-based Renesas > platforms that include the CEU, but they're pretty old now and don't support > the CEU in mainline. As far as I know only arch/sh still makes use of the CEU > driver. Well, I can still test it. And it is still in the arch/sh code. It's not really my decision since I just don't know enough whether or not it can be removed. You are probably better placed to figure that out. >> I'm not sure yet what we'll do with the soc-camera sensors. I experimented >> a bit with extracting them from soc-camera, but for most it's not easy to >> do so. Something to look at later. > > It would be a shame to remove them all, but it also depends on whether we can > find hardware for testing. Well, they always remain in git, but I know what you mean. Anyway, that's for later. 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 3/3] soc-camera/sh_mobile_csi2: remove unused driver
Hi Hans, On Monday 01 Aug 2016 10:56:21 Hans Verkuil wrote: > On 08/01/2016 10:34 AM, Laurent Pinchart wrote: > > On Monday 01 Aug 2016 09:54:25 Hans Verkuil wrote: > >> From: Hans Verkuil > >> > >> The sh_mobile_csi2 isn't used anymore (was it ever?), so remove it. > >> Especially since the soc-camera framework is being deprecated. > >> > >> Signed-off-by: Hans Verkuil > >> Cc: Laurent Pinchart > >> Cc: Guennadi Liakhovetski > > > > Acked-by: Laurent Pinchart > > > >> --- > >> > >> drivers/media/platform/soc_camera/Kconfig | 7 - > >> drivers/media/platform/soc_camera/Makefile | 1 - > >> .../platform/soc_camera/sh_mobile_ceu_camera.c | 229 +--- > >> drivers/media/platform/soc_camera/sh_mobile_csi2.c | 400 - > >> include/media/drv-intf/sh_mobile_ceu.h | 1 - > >> include/media/drv-intf/sh_mobile_csi2.h| 48 --- > >> 6 files changed, 10 insertions(+), 676 deletions(-) > >> delete mode 100644 drivers/media/platform/soc_camera/sh_mobile_csi2.c > >> delete mode 100644 include/media/drv-intf/sh_mobile_c > > > > Any plan for the sh_mobile_ceu_camera driver by the way ? > > Yes. > > The idea is to replace the remaining soc-camera drivers by 'proper' drivers > (Robert Jarzmik is working on that for the pxa_camera driver, and I am > working on the atmel-isi driver). > > Once that's done the only soc-camera driver left is the sh_mobile_ceu_camera > driver. > > At that moment the soc-camera framework will be folded into the > sh_mobile_ceu_camera driver and it will cease to exist as a framework. It's > just a very complex driver. I plan on refactoring it further, removing dead > code etc. > > My original plan was to replace the sh_mobile_ceu_camera driver by a > 'proper' driver as well, but it was next to impossible to do that. The fact > that it didn't use the device tree and the complexity with scaling and > cropping and the close dependency on soc-camera just made this a no go (at > least not something I was willing to spend more time on). > > I think this alternative approach has the best chance of succeeding. Are there really users of the CEU driver ? There are a few ARM-based Renesas platforms that include the CEU, but they're pretty old now and don't support the CEU in mainline. As far as I know only arch/sh still makes use of the CEU driver. > I'm not sure yet what we'll do with the soc-camera sensors. I experimented > a bit with extracting them from soc-camera, but for most it's not easy to > do so. Something to look at later. It would be a shame to remove them all, but it also depends on whether we can find hardware for testing. -- 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
Re: [PATCH] v4l2-common: add s_selection helper function
Hi Hans,
Thank you for the patch.
On Monday 01 Aug 2016 10:45:30 Hans Verkuil wrote:
> Checking the selection constraint flags is often forgotten by drivers,
> especially if the selection code just clamps the rectangle to the minimum
> and maximum allowed rectangles.
>
> This patch adds a simple helper function that checks the adjusted rectangle
> against the constraint flags and either returns -ERANGE if it doesn't fit,
> or fills in the new rectangle and returns 0.
>
> It also adds a small helper function to v4l2-rect.h to check if one
> rectangle fits inside another.
>
> Signed-off-by: Hans Verkuil
> ---
> diff --git a/drivers/media/v4l2-core/v4l2-common.c
> b/drivers/media/v4l2-core/v4l2-common.c index 5b80850..a2e5119 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -61,6 +61,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -371,6 +372,21 @@ void v4l_bound_align_image(u32 *w, unsigned int wmin,
> unsigned int wmax, }
> EXPORT_SYMBOL_GPL(v4l_bound_align_image);
>
> +int v4l2_s_selection(struct v4l2_selection *s, const struct v4l2_rect *r)
> +{
> + /* The original rect must lay inside the adjusted one */
> + if ((s->flags & V4L2_SEL_FLAG_GE) &&
> + !v4l2_rect_is_inside(&s->r, r))
> + return -ERANGE;
> + /* The adjusted rect must lay inside the original one */
> + if ((s->flags & V4L2_SEL_FLAG_LE) &&
> + !v4l2_rect_is_inside(r, &s->r))
> + return -ERANGE;
I'd like to see how this function is used in drivers.
> + s->r = *r;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_s_selection);
> +
> const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
> const struct v4l2_discrete_probe *probe,
> s32 width, s32 height)
> diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
> index 350cbf9..cfa9cbf 100644
> --- a/include/media/v4l2-common.h
> +++ b/include/media/v4l2-common.h
> @@ -246,6 +246,17 @@ void v4l_bound_align_image(unsigned int *w, unsigned
> int wmin, unsigned int hmax, unsigned int halign,
> unsigned int salign);
>
> +/**
> + * v4l2_s_selection - Helper to check adjusted rectangle against constraint
> flags
> + *
> + * @s: pointer to &struct v4l2_selection containing the original rectangle
> + * @r: pointer to &struct v4l2_rect containing the adjusted rectangle.
> + *
> + * Returns -ERANGE if the adjusted rectangle doesn't fit the constraints
> + * or 0 if it is fine. On success it sets @s->r to @r.
> + */
Part of the functions are documented in the header and part in the
implementation. We need to pick one option, and I prefer the latter one (which
is also more consistent with how functions are documented in most subsystems).
> +int v4l2_s_selection(struct v4l2_selection *s, const struct v4l2_rect *r);
> +
> struct v4l2_discrete_probe {
> const struct v4l2_frmsize_discrete *sizes;
> int num_sizes;
> diff --git a/include/media/v4l2-rect.h b/include/media/v4l2-rect.h
> index d2125f0..858c8cb 100644
> --- a/include/media/v4l2-rect.h
> +++ b/include/media/v4l2-rect.h
> @@ -95,6 +95,21 @@ static inline bool v4l2_rect_same_size(const struct
> v4l2_rect *r1, }
>
> /**
> + * v4l2_rect_is_inside() - return true if r1 is inside r2
> + * @r1: rectangle.
> + * @r2: rectangle.
> + *
> + * Return true if r1 fits inside r2.
> + */
> +static inline bool v4l2_rect_is_inside(const struct v4l2_rect *r1,
> +const struct v4l2_rect *r2)
How about calling the arguments inner and outer to make the purpose of each
argument more explicit from the function prototype ?
Also, I would name the function v4l2_rect_is_contained(), or possibly
v4l2_rect_contains() in which case the arguments should be switched. It should
also be noted that C doesn't provide support for function overloading so we
can't have
/* Rectangle contains rectangle */
bool v4l2_rect_contains(const struct v4l2_rect *outer,
const struct v4l2_rect *inner);
/* Rectangle contains point */
bool v4l2_rect_contains(const struct v4l2_rect *rect,
unsigned int x, unsigned int y);
Maybe we should thus name the function v4l2_rect_contains_rect() in prevision
for a future v4l2_rect_contains_point() ?
> +{
> + return r1->left >= r2->left && r1->top >= r2->top &&
> +r1->left + r1->width <= r2->left + r2->width &&
> +r1->top + r1->height <= r2->top + r2->height;
Isn't that's a big long for an inline function ?
> +}
> +
> +/**
> * v4l2_rect_intersect() - calculate the intersection of two rects.
> * @r: intersection of @r1 and @r2.
> * @r1: rectangle.
--
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/major
Re: [PATCH 3/3] soc-camera/sh_mobile_csi2: remove unused driver
On 08/01/2016 10:34 AM, Laurent Pinchart wrote: > Hi Hans, > > Thank you for the patch. > > On Monday 01 Aug 2016 09:54:25 Hans Verkuil wrote: >> From: Hans Verkuil >> >> The sh_mobile_csi2 isn't used anymore (was it ever?), so remove it. >> Especially since the soc-camera framework is being deprecated. >> >> Signed-off-by: Hans Verkuil >> Cc: Laurent Pinchart >> Cc: Guennadi Liakhovetski > > Acked-by: Laurent Pinchart > >> --- >> drivers/media/platform/soc_camera/Kconfig | 7 - >> drivers/media/platform/soc_camera/Makefile | 1 - >> .../platform/soc_camera/sh_mobile_ceu_camera.c | 229 +--- >> drivers/media/platform/soc_camera/sh_mobile_csi2.c | 400 -- >> include/media/drv-intf/sh_mobile_ceu.h | 1 - >> include/media/drv-intf/sh_mobile_csi2.h| 48 --- >> 6 files changed, 10 insertions(+), 676 deletions(-) >> delete mode 100644 drivers/media/platform/soc_camera/sh_mobile_csi2.c >> delete mode 100644 include/media/drv-intf/sh_mobile_c > > Any plan for the sh_mobile_ceu_camera driver by the way ? > Yes. The idea is to replace the remaining soc-camera drivers by 'proper' drivers (Robert Jarzmik is working on that for the pxa_camera driver, and I am working on the atmel-isi driver). Once that's done the only soc-camera driver left is the sh_mobile_ceu_camera driver. At that moment the soc-camera framework will be folded into the sh_mobile_ceu_camera driver and it will cease to exist as a framework. It's just a very complex driver. I plan on refactoring it further, removing dead code etc. My original plan was to replace the sh_mobile_ceu_camera driver by a 'proper' driver as well, but it was next to impossible to do that. The fact that it didn't use the device tree and the complexity with scaling and cropping and the close dependency on soc-camera just made this a no go (at least not something I was willing to spend more time on). I think this alternative approach has the best chance of succeeding. I'm not sure yet what we'll do with the soc-camera sensors. I experimented a bit with extracting them from soc-camera, but for most it's not easy to do so. Something to look at later. 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
[PATCH] v4l2-common: add s_selection helper function
Checking the selection constraint flags is often forgotten by drivers,
especially
if the selection code just clamps the rectangle to the minimum and maximum
allowed
rectangles.
This patch adds a simple helper function that checks the adjusted rectangle
against
the constraint flags and either returns -ERANGE if it doesn't fit, or fills in
the
new rectangle and returns 0.
It also adds a small helper function to v4l2-rect.h to check if one rectangle
fits
inside another.
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/v4l2-core/v4l2-common.c
b/drivers/media/v4l2-core/v4l2-common.c
index 5b80850..a2e5119 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -61,6 +61,7 @@
#include
#include
#include
+#include
#include
@@ -371,6 +372,21 @@ void v4l_bound_align_image(u32 *w, unsigned int wmin,
unsigned int wmax,
}
EXPORT_SYMBOL_GPL(v4l_bound_align_image);
+int v4l2_s_selection(struct v4l2_selection *s, const struct v4l2_rect *r)
+{
+ /* The original rect must lay inside the adjusted one */
+ if ((s->flags & V4L2_SEL_FLAG_GE) &&
+ !v4l2_rect_is_inside(&s->r, r))
+ return -ERANGE;
+ /* The adjusted rect must lay inside the original one */
+ if ((s->flags & V4L2_SEL_FLAG_LE) &&
+ !v4l2_rect_is_inside(r, &s->r))
+ return -ERANGE;
+ s->r = *r;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_s_selection);
+
const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
const struct v4l2_discrete_probe *probe,
s32 width, s32 height)
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 350cbf9..cfa9cbf 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -246,6 +246,17 @@ void v4l_bound_align_image(unsigned int *w, unsigned int
wmin,
unsigned int hmax, unsigned int halign,
unsigned int salign);
+/**
+ * v4l2_s_selection - Helper to check adjusted rectangle against constraint
flags
+ *
+ * @s: pointer to &struct v4l2_selection containing the original rectangle
+ * @r: pointer to &struct v4l2_rect containing the adjusted rectangle.
+ *
+ * Returns -ERANGE if the adjusted rectangle doesn't fit the constraints
+ * or 0 if it is fine. On success it sets @s->r to @r.
+ */
+int v4l2_s_selection(struct v4l2_selection *s, const struct v4l2_rect *r);
+
struct v4l2_discrete_probe {
const struct v4l2_frmsize_discrete *sizes;
int num_sizes;
diff --git a/include/media/v4l2-rect.h b/include/media/v4l2-rect.h
index d2125f0..858c8cb 100644
--- a/include/media/v4l2-rect.h
+++ b/include/media/v4l2-rect.h
@@ -95,6 +95,21 @@ static inline bool v4l2_rect_same_size(const struct
v4l2_rect *r1,
}
/**
+ * v4l2_rect_is_inside() - return true if r1 is inside r2
+ * @r1: rectangle.
+ * @r2: rectangle.
+ *
+ * Return true if r1 fits inside r2.
+ */
+static inline bool v4l2_rect_is_inside(const struct v4l2_rect *r1,
+ const struct v4l2_rect *r2)
+{
+ return r1->left >= r2->left && r1->top >= r2->top &&
+ r1->left + r1->width <= r2->left + r2->width &&
+ r1->top + r1->height <= r2->top + r2->height;
+}
+
+/**
* v4l2_rect_intersect() - calculate the intersection of two rects.
* @r: intersection of @r1 and @r2.
* @r1: rectangle.
--
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 v2] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder
Hi Tiffany,
On 07/29/2016 11:50 AM, Tiffany Lin wrote:
> Signed-off-by: Tiffany Lin
> ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 83
> ++--
> 1 file changed, 78 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> index 3ed3f2d..8f09dd3 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> @@ -487,7 +487,6 @@ static int vidioc_venc_s_fmt_out(struct file *file, void
> *priv,
> struct mtk_q_data *q_data;
> int ret, i;
> struct mtk_video_fmt *fmt;
> - unsigned int pitch_w_div16;
> struct v4l2_pix_format_mplane *pix_fmt_mp = &f->fmt.pix_mp;
>
> vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
> @@ -530,13 +529,12 @@ static int vidioc_venc_s_fmt_out(struct file *file,
> void *priv,
> q_data->coded_width = f->fmt.pix_mp.width;
> q_data->coded_height = f->fmt.pix_mp.height;
>
> - pitch_w_div16 = DIV_ROUND_UP(q_data->visible_width, 16);
> - if (pitch_w_div16 % 8 != 0) {
> + if (q_data->visible_width % 16) {
> /* Adjust returned width/height, so application could correctly
>* allocate hw required memory
>*/
> - q_data->visible_height += 32;
> - vidioc_try_fmt(f, q_data->fmt);
> + q_data->coded_height += 32;
> + f->fmt.pix_mp.height += 32;
> }
>
> q_data->field = f->fmt.pix_mp.field;
> @@ -631,6 +629,78 @@ static int vidioc_try_fmt_vid_out_mplane(struct file
> *file, void *priv,
> return vidioc_try_fmt(f, fmt);
> }
>
> +static int vidioc_venc_g_selection(struct file *file, void *priv,
> + struct v4l2_selection *s)
> +{
> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> + struct mtk_q_data *q_data;
> +
> + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + mtk_v4l2_err("Invalid s->type = %d", s->type);
This is not an error you want to log, just drop this. You can always get
detailed
debugging by running 'echo 2 >/sys/class/video4linux/videoX/dev_debug'.
> + return -EINVAL;
> + }
> +
> + q_data = mtk_venc_get_q_data(ctx, s->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + /* crop means compose for output devices */
Drop this comment. That's only true for the old G/S_CROP ioctls.
For the selection API crop is really crop.
> + switch (s->target) {
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + s->r.top = 0;
> + s->r.left = 0;
> + s->r.width = q_data->coded_width;
> + s->r.height = q_data->coded_height;
> + break;
> + case V4L2_SEL_TGT_CROP:
> + s->r.top = 0;
> + s->r.left = 0;
> + s->r.width = q_data->visible_width;
> + s->r.height = q_data->visible_height;
> + break;
> + default:
> + mtk_v4l2_err("Invalid s->target = %d", s->target);
Same here: just drop this line.
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int vidioc_venc_s_selection(struct file *file, void *priv,
> + struct v4l2_selection *s)
> +{
> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> + struct mtk_q_data *q_data;
> +
> + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + mtk_v4l2_err("Invalid s->type = %d", s->type);
Ditto.
> + return -EINVAL;
> + }
> +
> + q_data = mtk_venc_get_q_data(ctx, s->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + switch (s->target) {
> + case V4L2_SEL_TGT_CROP:
> + /* Only support crop from (0,0) */
> + if ((s->r.width > q_data->coded_width) ||
> + (s->r.height > q_data->coded_height)) {
> + return -ERANGE;
> + }
This isn't correct, instead just correct the width and height to the
max possible value.
> + s->r.top = 0;
> + s->r.left = 0;
> + q_data->visible_width = s->r.width;
> + q_data->visible_height = s->r.height;
> + break;
> + default:
> + mtk_v4l2_err("Invalid s->target = %d", s->target);
Ditto.
> + return -EINVAL;
> + }
> + return 0;
> +}
Note that this function doesn't check the constraint flags in s->r. However,
this
is a generic problem that I see often. I've written a patch that adds a helper
function that can check the new rectangle against the original rectangle and
constraint flags and returns -ERANGE if it doesn't fit.
That should simplify this code to:
struct v4l2_rect r = s->r;
int err;
...
case V4L2_SEL_TGT_CROP:
r.left = 0;
r.top = 0;
r.width = min(r.width, q_data->coded_width);
r.height =
Re: [PATCH 2/3] soc-camera/rcar-vin: remove obsolete driver
Hi Hans, Thank you for the patch. On Monday 01 Aug 2016 09:54:24 Hans Verkuil wrote: > From: Hans Verkuil > > This driver has been replaced by the non-soc-camera rcar-vin driver. > The soc-camera framework is being deprecated, so drop this older > rcar-vin driver in favor of the newer version that does not rely on > this deprecated framework. > > Signed-off-by: Hans Verkuil > Cc: Laurent Pinchart > Cc: Guennadi Liakhovetski > Cc: Niklas Söderlund I'm all for removal of dead code :-) Acked-by: Laurent Pinchart But please get Niklas' ack to confirm that the new driver supports all the feature available in the old one. > --- > drivers/media/platform/soc_camera/Kconfig| 10 - > drivers/media/platform/soc_camera/Makefile |1 - > drivers/media/platform/soc_camera/rcar_vin.c | 1970 --- > 3 files changed, 1981 deletions(-) > delete mode 100644 drivers/media/platform/soc_camera/rcar_vin.c -- 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
Re: [PATCH 3/3] soc-camera/sh_mobile_csi2: remove unused driver
Hi Hans, Thank you for the patch. On Monday 01 Aug 2016 09:54:25 Hans Verkuil wrote: > From: Hans Verkuil > > The sh_mobile_csi2 isn't used anymore (was it ever?), so remove it. > Especially since the soc-camera framework is being deprecated. > > Signed-off-by: Hans Verkuil > Cc: Laurent Pinchart > Cc: Guennadi Liakhovetski Acked-by: Laurent Pinchart > --- > drivers/media/platform/soc_camera/Kconfig | 7 - > drivers/media/platform/soc_camera/Makefile | 1 - > .../platform/soc_camera/sh_mobile_ceu_camera.c | 229 +--- > drivers/media/platform/soc_camera/sh_mobile_csi2.c | 400 -- > include/media/drv-intf/sh_mobile_ceu.h | 1 - > include/media/drv-intf/sh_mobile_csi2.h| 48 --- > 6 files changed, 10 insertions(+), 676 deletions(-) > delete mode 100644 drivers/media/platform/soc_camera/sh_mobile_csi2.c > delete mode 100644 include/media/drv-intf/sh_mobile_c Any plan for the sh_mobile_ceu_camera driver by the way ? -- 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
Re: [PATCH RFC v2 2/2] media: platform: pxa_camera: make a standalone v4l2 device
Hi Robert,
On 07/31/2016 05:03 PM, Robert Jarzmik wrote:
> Hi Hans,
>
>
> Hans Verkuil writes:
>> On 04/02/2016 04:26 PM, Robert Jarzmik wrote:
>>> diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
>>> b/drivers/media/platform/soc_camera/pxa_camera.c
>>> index b8dd878e98d6..30d266bbab55 100644
>>> --- a/drivers/media/platform/soc_camera/pxa_camera.c
>>> +++ b/drivers/media/platform/soc_camera/pxa_camera.c
>>
>> When you prepare the final patch series, please put the driver in
>> drivers/media/platform/pxa-camera and not in the soc-camera directory.
> Sure.
> Would you accept the final patch to make the move, so that I keep the
> bisectability, ie. that all patches are applied while still in ../soc_camera,
> and then the final one making just the move to .../platform ?
Sure, that's fine.
>
>>> + if (format->name)
>>> + strlcpy(f->description, format->name, sizeof(f->description));
>>
>> You can drop this since the core fills in the description. That means the
>> 'name' field of struct soc_mbus_pixelfmt is not needed either.
> Ok, let's try this, for v3.
>
>>> +static int pxac_vidioc_querycap(struct file *file, void *priv,
>>> + struct v4l2_capability *cap)
>>> +{
>>> + strlcpy(cap->bus_info, "platform:pxa-camera", sizeof(cap->bus_info));
>>> + strlcpy(cap->driver, PXA_CAM_DRV_NAME, sizeof(cap->driver));
>>> + strlcpy(cap->card, pxa_cam_driver_description, sizeof(cap->card));
>>> + cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
>>> + cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
>>
>> Tiny fix: you can drop the capabilities assignment: the v4l2 core does that
>> for you these days.
> Well, above kernel v4.7, if I drop the assignement, v4l2-compliance -s finds 2
> new errors:
> Required ioctls:
> fail: v4l2-compliance.cpp(534): dcaps & ~caps
> test VIDIOC_QUERYCAP: FAIL
>
> Allow for multiple opens:
> test second video open: OK
> fail: v4l2-compliance.cpp(534): dcaps & ~caps
> test VIDIOC_QUERYCAP: FAIL
> test VIDIOC_G/S_PRIORITY: OK
>
> So there is something fishy here if the core provides this data ...
Sorry, I forgot to say that you have to set the device_caps field of struct
video_device to V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING. You do that
where you set up the other fields of that structure.
The advantage is that the v4l2 core now knows the device capabilities and
it can use that information in the future.
>
>>> +static int pxac_vidioc_enum_input(struct file *file, void *priv,
>>> + struct v4l2_input *i)
>>> +{
>>> + if (i->index > 0)
>>> + return -EINVAL;
>>> +
>>> + memset(i, 0, sizeof(*i));
>>
>> The memset can be dropped, it's cleared for you.
> OK, for v3.
>
>>> +static void pxac_vb2_queue(struct vb2_buffer *vb)
>>> +{
>>> + struct pxa_buffer *buf = vb2_to_pxa_buffer(vb);
>>> + struct pxa_camera_dev *pcdev = vb2_get_drv_priv(vb->vb2_queue);
>>> +
>>> + dev_dbg(pcdev_to_dev(pcdev),
>>> +"%s(vb=%p) nb_channels=%d size=%lu active=%p\n",
>>> + __func__, vb, pcdev->channels, vb2_get_plane_payload(vb, 0),
>>> + pcdev->active);
>>> +
>>> + list_add_tail(&buf->queue, &pcdev->capture);
>>> +
>>> + pxa_dma_add_tail_buf(pcdev, buf);
>>> +
>>> + if (!pcdev->active)
>>> + pxa_camera_start_capture(pcdev);
>>
>> This is normally done from start_streaming. Are you really sure this is the
>> right
>> place? I strongly recommend moving this start_capture call.
> Well, it was at least with the previous framework.
> Previously this was done here to "hot-queue" a buffer :
> - if a previous capture was still running, the buffer was queued by
>pxa_dma_add_tail_buf(), and no restart of the DMA pump was necessary
> - if the previous capture was finished, a new one was initiated
>
> Now if the new framework takes care of that, I can move the
> pxa_camera_start_capture() into start_streaming(), no problem, let me try in
> the
> next patchset. That might take a bit of time because testing both the
> "hot-queue" and the "queue but hot-queuing missed" is a bit tricky.
>
>> You may also want to use the struct vb2queue min_buffers_needed field to
>> specify
>> the minimum number of buffers that should be queued up before
>> start_streaming can
>> be called. Whether that's needed depends on your DMA engine.
> I have no minimum required by the pxa dmaengine driver, that's good.
>
>>> +
>>> + v4l2_disable_ioctl(vdev, VIDIOC_G_STD);
>>> + v4l2_disable_ioctl(vdev, VIDIOC_S_STD);
>>> + v4l2_disable_ioctl(vdev, VIDIOC_ENUMSTD);
>>
>> I don't think this is needed since the tvnorms field of struct video_device
>> == 0,
>> signalling that there is no STD support.
> OK, for v3.
>
> Cheers.
>
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body
[PATCH 1/3] tw686x-kh: remove obsolete driver
From: Hans Verkuil
The functionality that was part of the tw686x-kh driver but not of the
mainlined tw686x driver has now been added to the tw686x driver as well.
So this driver no longer adds any functionality not available through
the mainlined driver and it can now be removed.
Signed-off-by: Hans Verkuil
Cc: Krzysztof Hałasa
---
drivers/staging/media/Kconfig | 2 -
drivers/staging/media/Makefile| 1 -
drivers/staging/media/tw686x-kh/Kconfig | 17 -
drivers/staging/media/tw686x-kh/Makefile | 3 -
drivers/staging/media/tw686x-kh/TODO | 6 -
drivers/staging/media/tw686x-kh/tw686x-kh-core.c | 140
drivers/staging/media/tw686x-kh/tw686x-kh-regs.h | 103 ---
drivers/staging/media/tw686x-kh/tw686x-kh-video.c | 813 --
drivers/staging/media/tw686x-kh/tw686x-kh.h | 117
9 files changed, 1202 deletions(-)
delete mode 100644 drivers/staging/media/tw686x-kh/Kconfig
delete mode 100644 drivers/staging/media/tw686x-kh/Makefile
delete mode 100644 drivers/staging/media/tw686x-kh/TODO
delete mode 100644 drivers/staging/media/tw686x-kh/tw686x-kh-core.c
delete mode 100644 drivers/staging/media/tw686x-kh/tw686x-kh-regs.h
delete mode 100644 drivers/staging/media/tw686x-kh/tw686x-kh-video.c
delete mode 100644 drivers/staging/media/tw686x-kh/tw686x-kh.h
diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index 7292f23..5382777 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -31,8 +31,6 @@ source "drivers/staging/media/omap4iss/Kconfig"
source "drivers/staging/media/pulse8-cec/Kconfig"
-source "drivers/staging/media/tw686x-kh/Kconfig"
-
source "drivers/staging/media/s5p-cec/Kconfig"
# Keep LIRC at the end, as it has sub-menus
diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
index 87ce8ad..6316e8c 100644
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@ -6,4 +6,3 @@ obj-$(CONFIG_LIRC_STAGING) += lirc/
obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci_vpfe/
obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/
obj-$(CONFIG_USB_PULSE8_CEC)+= pulse8-cec/
-obj-$(CONFIG_VIDEO_TW686X_KH) += tw686x-kh/
diff --git a/drivers/staging/media/tw686x-kh/Kconfig
b/drivers/staging/media/tw686x-kh/Kconfig
deleted file mode 100644
index 6264d30..000
--- a/drivers/staging/media/tw686x-kh/Kconfig
+++ /dev/null
@@ -1,17 +0,0 @@
-config VIDEO_TW686X_KH
- tristate "Intersil/Techwell TW686x Video For Linux"
- depends on VIDEO_DEV && PCI && VIDEO_V4L2
- depends on !(VIDEO_TW686X=y || VIDEO_TW686X=m) || COMPILE_TEST
- select VIDEOBUF2_DMA_SG
- help
- Support for Intersil/Techwell TW686x-based frame grabber cards.
-
- Currently supported chips:
- - TW6864 (4 video channels),
- - TW6865 (4 video channels, not tested, second generation chip),
- - TW6868 (8 video channels but only 4 first channels using
- built-in video decoder are supported, not tested),
- - TW6869 (8 video channels, second generation chip).
-
- To compile this driver as a module, choose M here: the module
- will be named tw686x-kh.
diff --git a/drivers/staging/media/tw686x-kh/Makefile
b/drivers/staging/media/tw686x-kh/Makefile
deleted file mode 100644
index 2a36a38..000
--- a/drivers/staging/media/tw686x-kh/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-tw686x-kh-objs := tw686x-kh-core.o tw686x-kh-video.o
-
-obj-$(CONFIG_VIDEO_TW686X_KH) += tw686x-kh.o
diff --git a/drivers/staging/media/tw686x-kh/TODO
b/drivers/staging/media/tw686x-kh/TODO
deleted file mode 100644
index 480a495..000
--- a/drivers/staging/media/tw686x-kh/TODO
+++ /dev/null
@@ -1,6 +0,0 @@
-TODO:
-
-- implement V4L2_FIELD_INTERLACED* mode(s).
-- add audio support
-
-Please Cc: patches to Krzysztof Halasa .
diff --git a/drivers/staging/media/tw686x-kh/tw686x-kh-core.c
b/drivers/staging/media/tw686x-kh/tw686x-kh-core.c
deleted file mode 100644
index 03b3b62..000
--- a/drivers/staging/media/tw686x-kh/tw686x-kh-core.c
+++ /dev/null
@@ -1,140 +0,0 @@
-/*
- * Copyright (C) 2015 Industrial Research Institute for Automation
- * and Measurements PIAP
- *
- * Written by Krzysztof Ha?asa.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of version 2 of the GNU General Public License
- * as published by the Free Software Foundation.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include "tw686x-kh.h"
-#include "tw686x-kh-regs.h"
-
-static irqreturn_t tw686x_irq(int irq, void *dev_id)
-{
- struct tw686x_dev *dev = (struct tw686x_dev *)dev_id;
- u32 int_status = reg_read(dev, INT_STATUS); /* cleared on read */
- unsigned long flags;
- unsigned int handled = 0;
-
- if (int_status) {
- spin_lock_irqsave(&dev->irq_lock, flags);
- dev->dma_requests |= int_sta
[PATCH 2/3] soc-camera/rcar-vin: remove obsolete driver
From: Hans Verkuil This driver has been replaced by the non-soc-camera rcar-vin driver. The soc-camera framework is being deprecated, so drop this older rcar-vin driver in favor of the newer version that does not rely on this deprecated framework. Signed-off-by: Hans Verkuil Cc: Laurent Pinchart Cc: Guennadi Liakhovetski Cc: Niklas Söderlund --- drivers/media/platform/soc_camera/Kconfig| 10 - drivers/media/platform/soc_camera/Makefile |1 - drivers/media/platform/soc_camera/rcar_vin.c | 1970 -- 3 files changed, 1981 deletions(-) delete mode 100644 drivers/media/platform/soc_camera/rcar_vin.c diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig index 39f6641..694cead 100644 --- a/drivers/media/platform/soc_camera/Kconfig +++ b/drivers/media/platform/soc_camera/Kconfig @@ -25,16 +25,6 @@ config VIDEO_PXA27x ---help--- This is a v4l2 driver for the PXA27x Quick Capture Interface -config VIDEO_RCAR_VIN_OLD - tristate "R-Car Video Input (VIN) support (DEPRECATED)" - depends on VIDEO_DEV && SOC_CAMERA - depends on ARCH_RENESAS || COMPILE_TEST - depends on HAS_DMA - select VIDEOBUF2_DMA_CONTIG - select SOC_CAMERA_SCALE_CROP - ---help--- - This is a v4l2 driver for the R-Car VIN Interface - config VIDEO_SH_MOBILE_CSI2 tristate "SuperH Mobile MIPI CSI-2 Interface driver" depends on VIDEO_DEV && SOC_CAMERA && HAVE_CLK diff --git a/drivers/media/platform/soc_camera/Makefile b/drivers/media/platform/soc_camera/Makefile index 7703cb7..4407a9b 100644 --- a/drivers/media/platform/soc_camera/Makefile +++ b/drivers/media/platform/soc_camera/Makefile @@ -10,4 +10,3 @@ obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o -obj-$(CONFIG_VIDEO_RCAR_VIN_OLD) += rcar_vin.o diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c deleted file mode 100644 index 9c13752..000 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ /dev/null @@ -1,1970 +0,0 @@ -/* - * SoC-camera host driver for Renesas R-Car VIN unit - * - * Copyright (C) 2011-2013 Renesas Solutions Corp. - * Copyright (C) 2013 Cogent Embedded, Inc., - * - * Based on V4L2 Driver for SuperH Mobile CEU interface "sh_mobile_ceu_camera.c" - * - * Copyright (C) 2008 Magnus Damm - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - */ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include "soc_scale_crop.h" - -#define DRV_NAME "rcar_vin" - -/* Register offsets for R-Car VIN */ -#define VNMC_REG 0x00/* Video n Main Control Register */ -#define VNMS_REG 0x04/* Video n Module Status Register */ -#define VNFC_REG 0x08/* Video n Frame Capture Register */ -#define VNSLPRC_REG0x0C/* Video n Start Line Pre-Clip Register */ -#define VNELPRC_REG0x10/* Video n End Line Pre-Clip Register */ -#define VNSPPRC_REG0x14/* Video n Start Pixel Pre-Clip Register */ -#define VNEPPRC_REG0x18/* Video n End Pixel Pre-Clip Register */ -#define VNSLPOC_REG0x1C/* Video n Start Line Post-Clip Register */ -#define VNELPOC_REG0x20/* Video n End Line Post-Clip Register */ -#define VNSPPOC_REG0x24/* Video n Start Pixel Post-Clip Register */ -#define VNEPPOC_REG0x28/* Video n End Pixel Post-Clip Register */ -#define VNIS_REG 0x2C/* Video n Image Stride Register */ -#define VNMB_REG(m)(0x30 + ((m) << 2)) /* Video n Memory Base m Register */ -#define VNIE_REG 0x40/* Video n Interrupt Enable Register */ -#define VNINTS_REG 0x44/* Video n Interrupt Status Register */ -#define VNSI_REG 0x48/* Video n Scanline Interrupt Register */ -#define VNMTC_REG 0x4C/* Video n Memory Transfer Control Register */ -#define VNYS_REG 0x50/* Video n Y Scale Register */ -#define VNXS_REG 0x54/* Video n X Scale Register */ -#define VNDMR_REG 0x58/* Video n Data Mode Register */ -#define VNDMR2_REG 0x5C/* Video n Data Mode Register 2 */ -#define VNUVAOF_REG0x60/* Video n UV Address Offset Register */ -#define VNC1A_REG 0x80/* Video n Coefficient Set C1A Register */ -#define VNC1B_REG 0x84/* Video n Coefficient Set C1B Register */ -#define VNC1C_REG 0x88/* Video n Coefficient Set C1C Register */ -#define VNC2A_REG
[PATCH 0/3] Remove tw686x-kh, soc-camera/rcar-vin and soc-camera/sh_mobile_csi2
From: Hans Verkuil Remove these three obsolete drivers: the first two have replacement drivers with the same functionality, the last driver is unused. Regards, Hans Hans Verkuil (3): tw686x-kh: remove obsolete driver soc-camera/rcar-vin: remove obsolete driver soc-camera/sh_mobile_csi2: remove unused driver drivers/media/platform/soc_camera/Kconfig | 17 - drivers/media/platform/soc_camera/Makefile |2 - drivers/media/platform/soc_camera/rcar_vin.c | 1970 .../platform/soc_camera/sh_mobile_ceu_camera.c | 229 +-- drivers/media/platform/soc_camera/sh_mobile_csi2.c | 400 drivers/staging/media/Kconfig |2 - drivers/staging/media/Makefile |1 - drivers/staging/media/tw686x-kh/Kconfig| 17 - drivers/staging/media/tw686x-kh/Makefile |3 - drivers/staging/media/tw686x-kh/TODO |6 - drivers/staging/media/tw686x-kh/tw686x-kh-core.c | 140 -- drivers/staging/media/tw686x-kh/tw686x-kh-regs.h | 103 - drivers/staging/media/tw686x-kh/tw686x-kh-video.c | 813 drivers/staging/media/tw686x-kh/tw686x-kh.h| 117 -- include/media/drv-intf/sh_mobile_ceu.h |1 - include/media/drv-intf/sh_mobile_csi2.h| 48 - 16 files changed, 10 insertions(+), 3859 deletions(-) delete mode 100644 drivers/media/platform/soc_camera/rcar_vin.c delete mode 100644 drivers/media/platform/soc_camera/sh_mobile_csi2.c delete mode 100644 drivers/staging/media/tw686x-kh/Kconfig delete mode 100644 drivers/staging/media/tw686x-kh/Makefile delete mode 100644 drivers/staging/media/tw686x-kh/TODO delete mode 100644 drivers/staging/media/tw686x-kh/tw686x-kh-core.c delete mode 100644 drivers/staging/media/tw686x-kh/tw686x-kh-regs.h delete mode 100644 drivers/staging/media/tw686x-kh/tw686x-kh-video.c delete mode 100644 drivers/staging/media/tw686x-kh/tw686x-kh.h delete mode 100644 include/media/drv-intf/sh_mobile_csi2.h -- 2.8.1 -- 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 3/3] soc-camera/sh_mobile_csi2: remove unused driver
From: Hans Verkuil
The sh_mobile_csi2 isn't used anymore (was it ever?), so remove it.
Especially since the soc-camera framework is being deprecated.
Signed-off-by: Hans Verkuil
Cc: Laurent Pinchart
Cc: Guennadi Liakhovetski
---
drivers/media/platform/soc_camera/Kconfig | 7 -
drivers/media/platform/soc_camera/Makefile | 1 -
.../platform/soc_camera/sh_mobile_ceu_camera.c | 229 +---
drivers/media/platform/soc_camera/sh_mobile_csi2.c | 400 -
include/media/drv-intf/sh_mobile_ceu.h | 1 -
include/media/drv-intf/sh_mobile_csi2.h| 48 ---
6 files changed, 10 insertions(+), 676 deletions(-)
delete mode 100644 drivers/media/platform/soc_camera/sh_mobile_csi2.c
delete mode 100644 include/media/drv-intf/sh_mobile_csi2.h
diff --git a/drivers/media/platform/soc_camera/Kconfig
b/drivers/media/platform/soc_camera/Kconfig
index 694cead..3cec521 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -25,13 +25,6 @@ config VIDEO_PXA27x
---help---
This is a v4l2 driver for the PXA27x Quick Capture Interface
-config VIDEO_SH_MOBILE_CSI2
- tristate "SuperH Mobile MIPI CSI-2 Interface driver"
- depends on VIDEO_DEV && SOC_CAMERA && HAVE_CLK
- depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST
- ---help---
- This is a v4l2 driver for the SuperH MIPI CSI-2 Interface
-
config VIDEO_SH_MOBILE_CEU
tristate "SuperH Mobile CEU Interface driver"
depends on VIDEO_DEV && SOC_CAMERA && HAS_DMA && HAVE_CLK
diff --git a/drivers/media/platform/soc_camera/Makefile
b/drivers/media/platform/soc_camera/Makefile
index 4407a9b..8d344fd 100644
--- a/drivers/media/platform/soc_camera/Makefile
+++ b/drivers/media/platform/soc_camera/Makefile
@@ -9,4 +9,3 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
-obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
diff --git a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
index 02b519d..05eafe3 100644
--- a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
+++ b/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
@@ -41,7 +41,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -99,11 +98,6 @@ struct sh_mobile_ceu_buffer {
struct sh_mobile_ceu_dev {
struct soc_camera_host ici;
- /* Asynchronous CSI2 linking */
- struct v4l2_async_subdev *csi2_asd;
- struct v4l2_subdev *csi2_sd;
- /* Synchronous probing compatibility */
- struct platform_device *csi2_pdev;
unsigned int irq;
void __iomem *base;
@@ -517,74 +511,20 @@ out:
return IRQ_HANDLED;
}
-static struct v4l2_subdev *find_csi2(struct sh_mobile_ceu_dev *pcdev)
-{
- struct v4l2_subdev *sd;
-
- if (pcdev->csi2_sd)
- return pcdev->csi2_sd;
-
- if (pcdev->csi2_asd) {
- char name[] = "sh-mobile-csi2";
- v4l2_device_for_each_subdev(sd, &pcdev->ici.v4l2_dev)
- if (!strncmp(name, sd->name, sizeof(name) - 1)) {
- pcdev->csi2_sd = sd;
- return sd;
- }
- }
-
- return NULL;
-}
-
-static struct v4l2_subdev *csi2_subdev(struct sh_mobile_ceu_dev *pcdev,
- struct soc_camera_device *icd)
-{
- struct v4l2_subdev *sd = pcdev->csi2_sd;
-
- return sd && sd->grp_id == soc_camera_grp_id(icd) ? sd : NULL;
-}
-
static int sh_mobile_ceu_add_device(struct soc_camera_device *icd)
{
- struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
- struct sh_mobile_ceu_dev *pcdev = ici->priv;
- struct v4l2_subdev *csi2_sd = find_csi2(pcdev);
- int ret;
-
- if (csi2_sd) {
- csi2_sd->grp_id = soc_camera_grp_id(icd);
- v4l2_set_subdev_hostdata(csi2_sd, icd);
- }
-
- ret = v4l2_subdev_call(csi2_sd, core, s_power, 1);
- if (ret < 0 && ret != -ENOIOCTLCMD && ret != -ENODEV)
- return ret;
-
- /*
-* -ENODEV is special: either csi2_sd == NULL or the CSI-2 driver
-* has not found this soc-camera device among its clients
-*/
- if (csi2_sd && ret == -ENODEV)
- csi2_sd->grp_id = 0;
-
dev_info(icd->parent,
-"SuperH Mobile CEU%s driver attached to camera %d\n",
-csi2_sd && csi2_sd->grp_id ? "/CSI-2" : "", icd->devnum);
+"SuperH Mobile CEU driver attached to camera %d\n",
+icd->devnum);
return 0;
}
static void sh_mobile_ceu_remove_device(struct soc_camera_device *icd)
