Hi Sakari,
On Wed, Sep 26, 2018 at 11:38 AM wrote:
>
> From: Bingbu Cao
>
> Add a v4l2 sub-device driver for the Sony imx319 image sensor.
> This is a camera sensor using the i2c bus for control and the
> csi-2 bus for data.
>
> This driver supports following features:
> - manual exposure and
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: Fri Oct 12 05:00:10 CEST 2018
media-tree git hash:8caec72e8cbff65afa38928197bea5a393b67975
media_build
Replace hardcoded function names with `__func__`
in debug prints.
Signed-off-by: Dafna Hirschfeld
---
.../staging/media/davinci_vpfe/dm365_ipipe.c | 6 +-
.../media/davinci_vpfe/dm365_resizer.c| 2 +-
.../media/davinci_vpfe/vpfe_mc_capture.c | 8 +--
On Mon, Oct 08, 2018 at 09:46:01PM -0700, Joel Fernandes wrote:
> On Fri, Apr 06, 2018 at 10:23:04AM -0400, Mauro Carvalho Chehab wrote:
> > As warned:
> > drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1834 vpfe_ipipe_init()
> > error: we previously assumed 'res' could be null (see line
The "transmit queue full" message doesn't warrant debug level 1 since
it is already clear from the error code what's going on.
Bump to level 2.
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 0c0d9107383e..b21f80c20fb2 100644
---
On 10/11/2018 05:33 PM, Kieran Bingham wrote:
> Hi Rajmohan
>
> Thank you for the patch,
>
> On 10/10/18 00:42, Rajmohan Mani wrote:
>> Removed redundant CIO2_IMAGE_MAX_* definitions
>>
>> Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
>>
>> Signed-off-by: Rajmohan
Hi Rajmohan
Thank you for the patch,
On 10/10/18 00:42, Rajmohan Mani wrote:
> Removed redundant CIO2_IMAGE_MAX_* definitions
>
> Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
>
> Signed-off-by: Rajmohan Mani
Reviewed-by: Kieran Bingham
Looks like this
The current code uses an algorithm to clamp the FPS values and round them
to the closest supported one that isn't really allows to be extended to
more than two values.
Rework it a bit to make it much easier to extend the amount of FPS options
we support.
Signed-off-by: Maxime Ripard
---
The current logic only requires to call ov5640_set_mode, which will in turn
change the clock rates according to the mode and frame interval, when a new
mode is set up.
However, when only the frame interval is changed but the mode isn't,
ov5640_set_mode is never called and the resulting frame rate
In the ov5640_try_frame_interval function, the ret variable actually holds
the frame rate index to use, which is represented by the enum
ov5640_frame_rate in the driver.
Make it more obvious.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 8
1 file changed, 4
The autoexposure setup in the 1080p init array is redundant with the
default value of the sensor.
Remove it.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
The pixel clock rates were introduced to report the initially static clock
rate.
Since this is now handled dynamically, we can remove them entirely.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff
Now that we have moved the clock generation logic out of the bytes array,
these arrays are identical between the 15fps and 30fps variants.
Remove the duplicate entries, and convert the code accordingly.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 306
The clock structure for the PCLK is quite obscure in the documentation, and
was hardcoded through the bytes array of each and every mode.
This is troublesome, since we cannot adjust it at runtime based on other
parameters (such as the number of bytes per pixel), and we can't support
either
The MIPI divider is also cleared as part of the clock setup sequence, so we
can remove that code.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index
Now that we have everything in place to compute the clock rate at runtime,
we can enable the 60fps framerate for the mode we tested it with.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git
Part of the hardcoded initialization sequence is to set up the proper clock
dividers. However, this is now done dynamically through proper code and as
such, the static one is now redundant.
Let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/media/i2c/ov5640.c | 46
The clock rate, while hardcoded until now, is actually a function of the
resolution, framerate and bytes per pixel. Now that we have an algorithm to
adjust our clock rate, we can select it dynamically when we change the
mode.
This changes a bit the clock rate being used, with the following
Hi,
Here is a "small" series that mostly cleans up the ov5640 driver code,
slowly getting rid of the big data array for more understandable code
(hopefully).
The biggest addition would be the clock rate computation at runtime,
instead of relying on those arrays to setup the clock tree
properly.
The OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT and OV5640_SCLK_ROOT_DIVIDER_DEFAULT
defines represent exactly the same setup, and are at the same value, than
the more consistent with the rest of the driver OV5640_SCLK2X_ROOT_DIV and
OV5640_SCLK_ROOT_DIV.
Remove them.
Signed-off-by: Maxime Ripard
---
Tested-by: Bingbu Cao
Reviewed-by: Bingbu Cao
On 10/10/2018 04:32 PM, Sakari Ailus wrote:
> The ipu3-cio2 driver has a function to tear down video devices as well as
> the associated video buffer queues. Use it.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/pci/intel/ipu3/ipu3-cio2.c
Tested-by: Bingbu Cao
Reviewed-by: Bingbu Cao
On 10/10/2018 04:32 PM, Sakari Ailus wrote:
> While there are issues related to object lifetime management, unregister
> the media device first, followed immediately by other device nodes when
> the driver is being unbound. Only then the resources
On Thu, Oct 11, 2018 at 5:26 PM Stanimir Varbanov
wrote:
>
> Hi Alex,
>
> On 10/11/2018 09:50 AM, Alexandre Courbot wrote:
> > Please ignore this patch - I did not notice that a similar one has
> > been sent before.
>
> The difference is that you made it for decoder as well. Do you need
> userptr
On Mon, 2018-10-08 at 13:53 +0200, Hans Verkuil wrote:
> Hi all,
>
> I would like to meet up somewhere during the ELCE to discuss userspace support
> for stateless (and perhaps stateful as well?) codecs.
>
> It is also planned as a topic during the summit, but I would prefer to prepare
> for
Hi Alex,
On 10/11/2018 09:50 AM, Alexandre Courbot wrote:
> Please ignore this patch - I did not notice that a similar one has
> been sent before.
The difference is that you made it for decoder as well. Do you need
userptr for decoder?
--
regards,
Stan
On Tue, Oct 9, 2018 at 4:52 PM Malathi Gottam wrote:
>
> Add USERPTR to queue access methods by adding this
> support to io_modes on both the planes.
>
> Signed-off-by: Malathi Gottam
Tested-by: Alexandre Courbot
Please ignore this patch - I did not notice that a similar one has
been sent before. >_<
On Thu, Oct 11, 2018 at 3:46 PM Alexandre Courbot wrote:
>
> The venus codec can work just fine with USERPTR buffers. Enable this
> possibility.
>
> Signed-off-by: Alexandre Courbot
> ---
>
The venus codec can work just fine with USERPTR buffers. Enable this
possibility.
Signed-off-by: Alexandre Courbot
---
drivers/media/platform/qcom/venus/vdec.c | 4 ++--
drivers/media/platform/qcom/venus/venc.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
28 matches
Mail list logo
