Re: [PATCH v2 09/13] media: imx274: get rid of mode_index

Hi Luca, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.17-rc2 next-20180424] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com

[PATCH] media: zoran: move to dma-mapping interface

No drivers should use virt_to_bus() any more. This converts one of the few remaining ones to the DMA mapping interface. Signed-off-by: Arnd Bergmann --- drivers/media/pci/zoran/Kconfig| 2 +- drivers/media/pci/zoran/zoran.h| 10 +--

Re: [PATCH v2 00/12] media: ov5640: Misc cleanup and improvements

FYI, still hard at work on this. Did some more experiments last week that seemed to corroborate the clock tree in the spreadsheet. It also seems that the output of the P divider cell, SCLK cell and MIPI Rate cell in the spreadsheet must have a ratio of 2x:1x:8x (respectively) in order for the

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote: > > At the very lowest level they will need to be handled differently for > > many architectures, the questions is at what point we'll do the > > branching out. > > Having at least struct page also in that list with (dma_addr_t,

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

On Tue, Apr 24, 2018 at 02:47:55PM -0300, Mauro Carvalho Chehab wrote: > So, I'm wondering if are there any way to mitigate it inside the > core itself, instead of doing it on every driver, e. g. changing > v4l_enum_fmt() implementation at v4l2-ioctl. > > Ok, a "poor man" approach would be to

Re: [PATCH v5 1/2] media: ov2680: dt: Add bindings for OV2680

Hi Fabio, On Tue 24 Apr 2018 at 15:53, Fabio Estevam wrote: Hi Rui, On Thu, Apr 19, 2018 at 8:00 AM, Rui Miguel Silva wrote: Add device tree binding documentation for the OV2680 camera sensor. Reviewed-by: Rob Herring CC: devicet...@vger.kernel.org

Re: [PATCH] media: stv0910: fix get_algo()'s return type

Am Tue, 24 Apr 2018 15:19:38 +0200 schrieb Luc Van Oostenryck : > The method dvb_frontend_ops::get_frontend_algo() is defined as > returning an 'enum dvbfe_algo', but the implementation in this > driver returns an 'int'. > > Fix this by returning 'enum dvbfe_algo' in

Re: [PATCH] media: mxl5xx: fix get_algo()'s return type

Am Tue, 24 Apr 2018 15:19:31 +0200 schrieb Luc Van Oostenryck : > The method dvb_frontend_ops::get_frontend_algo() is defined as > returning an 'enum dvbfe_algo', but the implementation in this > driver returns an 'int'. > > Fix this by returning 'enum dvbfe_algo' in

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

Em Tue, 24 Apr 2018 12:36:09 +0200 Peter Zijlstra escreveu: > On Tue, Apr 24, 2018 at 12:35:00PM +0300, Dan Carpenter wrote: > > On Mon, Apr 23, 2018 at 03:24:55PM -0300, Mauro Carvalho Chehab wrote: > > > Em Mon, 23 Apr 2018 12:38:03 -0500 > > > "Gustavo A. R. Silva"

Re: [PATCH v2 08/12] media: ov5640: Adjust the clock based on the expected rate

Hi Sakari, On Tue, Apr 24, 2018 at 10:21:47AM +0300, Sakari Ailus wrote: > > /* download ov5640 settings to sensor through i2c */ > > static int ov5640_load_regs(struct ov5640_dev *sensor, > > const struct ov5640_mode_info *mode) > > @@ -1620,6 +1830,14 @@ static int

Re: [PATCH 2/8] dt-bindings: display: bridge: thc63lvd1024: Add lvds map property

On Thu, Apr 19, 2018 at 11:31:03AM +0200, Jacopo Mondi wrote: > The THC63LVD1024 LVDS to RGB bridge supports two different input mapping > modes, selectable by means of an external pin. > > Describe the LVDS mode map through a newly defined mandatory property in > device tree bindings. > >

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 24, 2018 at 8:48 PM, Christoph Hellwig wrote: > On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote: >> > At the very lowest level they will need to be handled differently for >> > many architectures, the questions is at what point we'll do the >> >

[PATCH] rcar-vin: enable field toggle after a set number of lines for Gen3

The VIN Gen3 hardware don't have Line Post-Clip capabilities as VIN Gen2 hardware have. To protect against writing outside the capture window enable field toggle after a set number of lines have been captured. Capturing outside the allocated capture buffer where observed on R-Car Gen3 Salvator-XS

Re: [PATCH v3][RESEND] media: i2c: tda1997: replace codec to component

Hi Tim, Mark > >> Could you add some detail to the commit explaining why we need to > >> replace codec to component? I don't really know what that means. > >> Please refer to a commit if the ASoC API is changing in some way we > >> need to catch up with. > > > > This is a big transition in the

[PATCH] rcar-vin: fix null pointer dereference in rvin_group_get()

Store the group pointer before disassociating the VIN from the group. Fixes: 3bb4c3bc85bf77a7 ("media: rcar-vin: add group allocator functions") Reported-by: Colin Ian King Signed-off-by: Niklas Söderlund ---

RE: [RESEND PATCH v7 1/2] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

Hi Rob, Apologize missed your comment before sent out v8. I will definitely add acks/reviewed-bys in next version. Regards, Andy -Original Message- From: Rob Herring [mailto:r...@kernel.org] Sent: Friday, April 13, 2018 11:11 PM To: Yeh, Andy Cc:

cron job: media_tree daily build: ERRORS

This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Apr 25 05:00:10 CEST 2018 media-tree git hash:a2b2eff6ac2716f499defa590a6ec4ba379d765e media_build

Re: [PATCH] media: i2c: adv748x: Fix pixel rate values

Hi Laurent, Thanks for your patch. On 2018-04-21 15:44:44 +0300, Laurent Pinchart wrote: > The pixel rate, as reported by the V4L2_CID_PIXEL_RATE control, must > include both horizontal and vertical blanking. Both the AFE and HDMI > receiver program it incorrectly: > > - The HDMI receiver goes

[PATCH] cx88: Get rid of spurious call to cx8800_start_vbi_dma()

This was left over from the conversion to VB2, where the call was getting invoked both in buffer_queue and start_streaming, which was intermittently causing invalid opcodes on the VBI RISC queue. This change effectively mirrors the exact same change Hans Verkuil made in cx88-video.c in

[PATCH] rcar-vin: remove generic gen3 compatible string

The compatible string "renesas,rcar-gen3-vin" was added before the Gen3 driver code was added but it's not possible to use. Each SoC in the Gen3 series require SoC specific knowledge in the driver to function. Remove it before it is added to any device tree descriptions. Signed-off-by: Niklas

[GIT FIXES FOR v4.17] UVC fixes

Hi Mauro, The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

Re: a 4.16 kernel with Debian 9.4 "stretch" causes a log explosion

Hi Guennadi, On Wednesday, 11 April 2018 22:33:43 EEST Guennadi Liakhovetski wrote: > On Wed, 11 Apr 2018, Kieran Bingham wrote: > > On 11/04/18 18:06, Guennadi Liakhovetski wrote: > > > > > > Just figured out this commit > > > > From: Edgar Thier > >

[PATCH] rcar-vin: add support for MEDIA_BUS_FMT_UYVY8_1X16

By setting VNMC_YCAL rcar-vin can support input video in MEDIA_BUS_FMT_UYVY8_1X16 format. Signed-off-by: Niklas Söderlund --- drivers/media/platform/rcar-vin/rcar-core.c | 1 + drivers/media/platform/rcar-vin/rcar-dma.c | 5 + 2 files changed, 6

[RESEND PATCH v8 2/2] media: dw9807: Add dw9807 vcm driver

From: Alan Chiang DW9807 is a 10 bit DAC from Dongwoon, designed for linear control of voice coil motor. This driver creates a V4L2 subdevice and provides control to set the desired focus. Signed-off-by: Andy Yeh --- since v1: - changed author.

[RESEND PATCH v8 1/2] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

From: Alan Chiang Dongwoon DW9807 is a voice coil lens driver. Signed-off-by: Andy Yeh --- Documentation/devicetree/bindings/media/i2c/dongwoon,dw9807.txt | 9 + 1 file changed, 9 insertions(+) create mode 100644

[RESEND PATCH v8 0/2] DW9807 DT binding and driver patches

Hi Sakari and Tomasz, The two patches are the DT binding and driver for DW9807 VCM controller. Alan Chiang (2): media: dw9807: Add dw9807 vcm driver media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil .../bindings/media/i2c/dongwoon,dw9807.txt | 9 + MAINTAINERS

RE: [RESEND PATCH v7 2/2] media: dw9807: Add dw9807 vcm driver

Hi Jocopo, Tomasz, Thanks for your comments. Resend patches to https://patchwork.linuxtv.org/patch/49029/ Most of the comments are addressed. However some remain no change based on the discussion with Sakari and Tomasz. Posted as below. > if (MAX_RETRY == ++retry) { >

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote: > Out of curiosity, how much virtual flushing stuff is there still out > there? At least in drm we've pretty much ignore this, and seem to be > getting away without a huge uproar (at least from driver developers > and users, core folks

Re: [PATCH 5/8] media: Add LE version of RGB LVDS formats

HI Laurent, On Mon, Apr 23, 2018 at 04:06:01PM +0300, Laurent Pinchart wrote: > Hi Jacopo, > > Thank you for the patch. > > On Thursday, 19 April 2018 12:31:06 EEST Jacopo Mondi wrote: > > Some LVDS controller can output swapped versions of LVDS RGB formats. > > Define and document them in the

Re: [PATCH 8/8] drm: connector: Remove DRM_BUS_FLAG_DATA_* flags

Hi Laurent, On Tue, Apr 24, 2018 at 12:03:04AM +0300, Laurent Pinchart wrote: > Hi Jacopo, > > Thank you for the patch. > > On Thursday, 19 April 2018 12:31:09 EEST Jacopo Mondi wrote: > > DRM_BUS_FLAG_DATA_* flags, defined in drm_connector.h header file are > > used to swap ordering of LVDS RGB

Re: [PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

Hi Mauro, On Fri, Apr 20, 2018 at 7:42 PM, Mauro Carvalho Chehab wrote: > The virt_to_bus/bus_to_virt macros are arch-specific. Some > archs don't support it. Yet, as it is interesting to allow > doing compilation tests on non-ia32/ia64 archs, provide a > fallback for

Re: [PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

On Fri, Apr 20, 2018 at 7:42 PM, Mauro Carvalho Chehab wrote: > The virt_to_bus/bus_to_virt macros are arch-specific. Some > archs don't support it. Yet, as it is interesting to allow > doing compilation tests on non-ia32/ia64 archs, provide a > fallback for such archs.

Re: [PATCH v2 08/12] media: ov5640: Adjust the clock based on the expected rate

Hi Maxime, On Mon, Apr 16, 2018 at 02:36:57PM +0200, Maxime Ripard wrote: > 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 >

[PATCH v2 12/13] media: imx274: add helper function to fill a reg_8 table chunk

Tables of struct reg_8 are used to simplify multi-byte register assignment. However filling these snippets with values computed at runtime is currently implemented by very similar functions doing the needed shift & mask manipulation. Replace all those functions with a unique helper function to

[PATCH v2 07/13] media: imx274: initialize format before v4l2 controls

The current probe function calls v4l2_ctrl_handler_setup() before initializing the format info. This triggers call paths such as: imx274_probe -> v4l2_ctrl_handler_setup -> imx274_s_ctrl -> imx274_set_exposure, where priv->mode_index is accessed before being assigned. This is wrong but does not

[PATCH v2 09/13] media: imx274: get rid of mode_index

After restructuring struct imx274_frmfmt, the mode_index field is still in use only for two dev_dbg() calls in imx274_s_stream(). Let's remove it and avoid duplicated information. Replacing the first usage requires a some rather annoying but trivial pointer math. The other one can be removed

[PATCH v2 10/13] media: imx274: actually use IMX274_DEFAULT_MODE

IMX274_DEFAULT_MODE is defined but not used. Start using it, so the default can be more easily changed without digging into the code. Signed-off-by: Luca Ceresoli --- Changed v1 -> v2: - add "media: " prefix to commit message --- drivers/media/i2c/imx274.c | 2 +- 1

[PATCH v2 01/13] media: imx274: document reset delays more clearly

Document the unit to avoid having to look through the code to compute it. Also clarify that these are min and max values. Signed-off-by: Luca Ceresoli --- Changed v1 -> v2: - add "media: " prefix to commit message --- drivers/media/i2c/imx274.c | 2 +- 1 file changed, 1

[PATCH v2 02/13] media: imx274: fix typo in comment

Signed-off-by: Luca Ceresoli --- Changed v1 -> v2: - add "media: " prefix to commit message --- drivers/media/i2c/imx274.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c index

[PATCH v2 03/13] media: imx274: slightly simplify code

imx274_s_frame_interval() already has a direct pointer to the v4l2 exposure control, so reuse it to simplify code. Signed-off-by: Luca Ceresoli --- Changed v1 -> v2: - add "media: " prefix to commit message --- drivers/media/i2c/imx274.c | 2 +- 1 file changed, 1

[PATCH v2 06/13] media: imx274: remove non-indexed pointers from mode_table

mode_table[] has 3 members that are accessed based on their index, which makes worth using an array. The other members are always accessed with a constant index. This added indirection gives no improvement and only makes code more verbose. Remove these pointers from the array and access them

[PATCH v2 05/13] media: imx274: rename and reorder register address definitions

Most registers are defined using the name used in the datasheet. E.g. the defines for the HMAX register are IMX274_HMAX_REG_*. Rename the SHR and VMAX register accordingly. Also move them close to related registers: SHR close to SVR, VMAX close to HMAX. Signed-off-by: Luca Ceresoli

Re: [PATCH v2 03/10] videobuf2-core: Add helper to get buffer private data from media request

Hi Paul, On Thu, Apr 19, 2018 at 05:41:17PM +0200, Paul Kocialkowski wrote: > When calling media operation driver callbacks related to media requests, > only a pointer to the request itself is provided, which is insufficient > to retrieve the driver's context. Since the driver context is usually

Re: [PATCH 2/3] media: ov5640: add PIXEL_RATE and LINK_FREQ controls

Hi Daniel, On Fri, Apr 20, 2018 at 11:44:18AM +0200, Daniel Mack wrote: > Add v4l2 controls to report the pixel and MIPI link rates of each mode. > The camss camera subsystem needs them to set up the correct hardware > clocks. > > Tested on msm8016 based hardware. > > Signed-off-by: Daniel Mack

Re: [PATCH v2] [media] uvcvideo: Refactor teardown of uvc on USB disconnect

On 04/24/18 10:28, Kieran Bingham wrote: > Hi Hans, > > On 23/04/18 20:12, Hans Verkuil wrote: >> Laurent, Kieran, >> >> Can one of you look at this? >> >> https://patchwork.linuxtv.org/patch/40941/ > > Looking through it now. Looks good so far - I'll try it against my Async UVC > work as well!

Re: [PATCH v10 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

Hi Simon, On Tue, Apr 24, 2018 at 10:23:56AM +0200, Simon Horman wrote: > On Mon, Apr 23, 2018 at 05:21:43PM +0200, jacopo mondi wrote: > > Hi Simon, > > > > On Wed, Feb 21, 2018 at 07:29:18PM +0100, Simon Horman wrote: > > > On Wed, Feb 21, 2018 at 06:47:58PM +0100, Jacopo Mondi wrote: > > > >

Re: [RESEND PATCH] media: i2c: ov5640: Add pixel clock support

On 29 March 2018 at 16:55, Manivannan Sadhasivam wrote: > Some of the camera subsystems like camss in Qualcommm MSM chipsets > require pixel clock support in camera sensor drivers. So, this commit > adds a default pixel clock rate of 96MHz to OV5640 camera sensor

Re: [PATCH v2 05/10] media: v4l: Add definitions for MPEG2 frame format and header metadata

Hi Paul, On Thu, Apr 19, 2018 at 05:45:31PM +0200, Paul Kocialkowski wrote: > Stateless video decoding engines require both the MPEG slices and > associated metadata from the video stream in order to decode frames. > > This introduces definitions for a new pixel format, describing buffers > with

[linux-next:master 1383/2517] sound/isa/ad1816a/ad1816a_lib.c:93:14: sparse: restricted snd_pcm_format_t degrades to integer

tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: 43cd1f4979998ba0ef1c0b8e1c5d23d2de5ab172 commit: da112f13996de6e8dc0011f77ce8f7d0353dd14e [1383/2517] media: sound, isapnp: allow building more drivers with COMPILE_TEST reproduce: # apt-get

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

Hi Dan, Em Tue, 24 Apr 2018 12:35:00 +0300 Dan Carpenter escreveu: > Hi Mauro, > > I saw your comment on LWN. You argue on LWN that since the format array > is static the CPU won't speculatively read past the L1 cache? The intent of that comment is to be

Re: [PATCH 1/7] asm-generic, media: allow COMPILE_TEST with virt_to_bus

Em Tue, 24 Apr 2018 09:55:55 +0200 Arnd Bergmann escreveu: > On Fri, Apr 20, 2018 at 7:42 PM, Mauro Carvalho Chehab > wrote: > > The virt_to_bus/bus_to_virt macros are arch-specific. Some > > archs don't support it. Yet, as it is interesting to allow > >

Re: [PATCH 3/3] media: ov5640: add support for xclk frequency control

On Fri, Apr 20, 2018 at 11:44:19AM +0200, Daniel Mack wrote: > Allow setting the xclk rate via an optional 'clock-frequency' property in > the device tree node. > > Signed-off-by: Daniel Mack > --- > Documentation/devicetree/bindings/media/i2c/ov5640.txt | 2 ++ >

Re: [PATCH] staging: media: use relevant lock

Hi Julia Thank you for the patch. On 03/08/17 13:26, Julia Lawall wrote: > The data protected is video_out2 and the lock that is released is > _out2->dma_queue_lock, so it seems that that lock should be > taken as well. I agree - this certainly looks like there was a copy/paste error perhaps

Re: [PATCH v10 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

On Mon, Apr 23, 2018 at 05:21:43PM +0200, jacopo mondi wrote: > Hi Simon, > > On Wed, Feb 21, 2018 at 07:29:18PM +0100, Simon Horman wrote: > > On Wed, Feb 21, 2018 at 06:47:58PM +0100, Jacopo Mondi wrote: > > > Add Capture Engine Unit (CEU) node to device tree. > > > > > > Signed-off-by: Jacopo

[PATCH v2 08/13] media: imx274: consolidate per-mode data in imx274_frmfmt

Data about the implemented readout modes is partially stored in imx274_formats[], the rest is scattered in several arrays. The latter are then accessed using the mode index, e.g.: min_frame_len[priv->mode_index] Consolidate all these data in imx274_formats[], and store a pointer to the

[PATCH v2 11/13] media: imx274: simplify imx274_write_table()

imx274_write_table() is a mere wrapper (and the only user) to imx274_regmap_util_write_table_8(). Remove this useless indirection by merging the two functions into one. Also get rid of the wait_ms_addr and end_addr parameters since it does not make any sense to give them any values other than

[PATCH v2 13/13] media: imx274: add SELECTION support for cropping

Currently this driver does not support cropping. The supported modes are the following, all capturing the entire area: - 3840x2160, 1:1 binning (native sensor resolution) - 1920x1080, 2:1 binning - 1280x720, 3:1 binning The set_fmt callback chooses among these 3 configurations the one that

Re: [RESEND PATCH] media: i2c: ov5640: Add pixel clock support

On Tue, Apr 24, 2018 at 11:01:18AM +0200, Loic Poulain wrote: > On 29 March 2018 at 16:55, Manivannan Sadhasivam > wrote: > > Some of the camera subsystems like camss in Qualcommm MSM chipsets > > require pixel clock support in camera sensor drivers. So, this

Re: [PATCH v2] [media] uvcvideo: Refactor teardown of uvc on USB disconnect

Hi Hans, On 23/04/18 20:12, Hans Verkuil wrote: > Laurent, Kieran, > > Can one of you look at this? > > https://patchwork.linuxtv.org/patch/40941/ Looking through it now. Looks good so far - I'll try it against my Async UVC work as well! It looks like there won't be conflicts though. I now

Re: [PATCH v2 02/10] media-request: Add a request complete operation to allow m2m scheduling

Hi Paul, On Thu, Apr 19, 2018 at 05:41:16PM +0200, Paul Kocialkowski wrote: > When using the request API in the context of a m2m driver, the > operations that come with a m2m run scheduling call in their > (m2m-specific) ioctl handler are delayed until the request is queued > (for instance, this

[PATCH v2 00/13] media: imx274: cleanups, improvements and SELECTION API support

Hi, this patchset introduces cropping support for the Sony IMX274 sensor using the SELECTION API. With respect to v1 this patchset adds the "media: " prefix to commits and fixes a warning in patch 9. Patches 1-6 clean up and restructure code in various places and are pretty much independent

[PATCH v2 04/13] media: imx274: remove unused data from struct imx274_frmfmt

struct imx274_frmfmt is instantiated only in the imx274_formats[] array, where imx274_formats[N].mode always equals N (via enum imx274_mode). So .mode carries no information, and unsurprisingly it is never used. mbus_code is never used because the 12 bit modes are not implemented. The

Re: [PATCH] sound, isapnp: allow building more drivers with COMPILE_TEST

On 4/20/2018 2:58 PM, Mauro Carvalho Chehab wrote: Drivers that depend on ISAPNP currently can't be built with COMPILE_TEST. However, looking at isapnp.h, there are already stubs there to allow drivers to include it even when isa PNP is not supported. So, remove such dependencies when

Re: [PATCH v2 06/15] media: staging/imx: add imx7 capture subsystem

Hi Philipp, On Mon 23 Apr 2018 at 15:48, Philipp Zabel wrote: On Mon, 2018-04-23 at 14:47 +0100, Rui Miguel Silva wrote: Add imx7 capture subsystem to imx-media core to allow the use some of the existing modules for i.MX5/6 with i.MX7 SoC. Since i.MX7 does not have an IPU unset the

Re: [PATCH v2 07/10] media: platform: Add Sunxi-Cedrus VPU decoder driver

Hi Paul On Thu, Apr 19, 2018 at 05:45:33PM +0200, Paul Kocialkowski wrote: > This introduces the Sunxi-Cedrus VPU driver that supports the VPU found > in Allwinner SoCs, also known as Video Engine. It is implemented through > a v4l2 m2m decoder device and a media device (used for media requests).

Re: [PATCH v3 6/7] drm/i2c: tda998x: add CEC support

On 04/09/18 14:16, Russell King wrote: > The TDA998x is a HDMI transmitter with a TDA9950 CEC engine integrated > onto the same die. Add support for the TDA9950 CEC engine to the > TDA998x driver. > > Signed-off-by: Russell King Reviewed-by: Hans Verkuil

Re: [PATCH v3 5/7] drm/i2c: tda9950: add CEC driver

On 04/09/18 14:16, Russell King wrote: > Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device, > but is also integrated into HDMI transceivers such as the TDA9989 and > TDA19989. > > The TDA9950 contains a command processor which handles retransmissions > and the low level bus

Re: [PATCH v3 7/7] dt-bindings: tda998x: add the calibration gpio

On 04/09/18 14:16, Russell King wrote: > Add the optional calibration gpio for integrated TDA9950 CEC support. > This GPIO corresponds with the interrupt from the TDA998x, as the > calibration requires driving the interrupt pin low. > > Reviewed-by: Rob Herring > Signed-off-by:

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

Hi Mauro, I saw your comment on LWN. You argue on LWN that since the format array is static the CPU won't speculatively read past the L1 cache? I don't know if that's true. It should be easy enough to filter out the reads into static arrays. Peter do you know the answer here? regards, dan

Re: [PATCH v3 0/7] TDA998x CEC support

On Tue, Apr 24, 2018 at 11:29:42AM +0200, Hans Verkuil wrote: > On 04/09/18 14:15, Russell King - ARM Linux wrote: > > Hi, > > > > This patch series adds CEC support to the DRM TDA998x driver. The > > TDA998x family of devices integrate a TDA9950 CEC at a separate I2C > > address from the HDMI

Re: [PATCH/RFC 7/8] ARM: shmobile: Remove the ARCH_SHMOBILE Kconfig symbol

(Reducing/enhancing CC list) On Fri, Apr 20, 2018 at 3:28 PM, Geert Uytterhoeven wrote: > All drivers for Renesas ARM SoCs have gained proper ARCH_RENESAS > platform dependencies. Hence finish the conversion from ARCH_SHMOBILE > to ARCH_RENESAS for Renesas 32-bit ARM

Re: [PATCH v3 0/7] TDA998x CEC support

On 04/24/18 11:42, Russell King - ARM Linux wrote: > On Tue, Apr 24, 2018 at 11:29:42AM +0200, Hans Verkuil wrote: >> On 04/09/18 14:15, Russell King - ARM Linux wrote: >>> Hi, >>> >>> This patch series adds CEC support to the DRM TDA998x driver. The >>> TDA998x family of devices integrate a

Re: [PATCH v3 02/11] media: ov772x: allow i2c controllers without I2C_FUNC_PROTOCOL_MANGLING

Hi guys, On Mon, Apr 23, 2018 at 11:51:30PM +0300, Laurent Pinchart wrote: > Hi Wolfram, > > On Monday, 23 April 2018 23:36:16 EEST Wolfram Sang wrote: > > > SCCB helpers would work too. It would be easy to just move the functions > > > defined in this patch to helpers and be done with it.

Re: [PATCH] media: em28xx: Don't use ops->resume if NULL

On Mon, Apr 23, 2018 at 07:02:39AM -0400, Mauro Carvalho Chehab wrote: > Changeset be7fd3c3a8c5 ("media: em28xx: Hauppauge DualHD > second tuner functionality") introduced a potential NULL pointer > dereference, as pointed by Coverity: > > CID 1434731 (#1 of 1): Dereference after null check

Re: [PATCH] media: davinci: don't override the error code

On Mon, Apr 23, 2018 at 07:22:19AM -0400, Mauro Carvalho Chehab wrote: > As warned by Coverity: > CID 1415211 (#1 of 1): Unused value (UNUSED_VALUE)assigned_value: > Assigning value -22 to ret here, but that stored value is > overwritten before it can be used. > > On all cases

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

On Tue, Apr 24, 2018 at 12:35:00PM +0300, Dan Carpenter wrote: > On Mon, Apr 23, 2018 at 03:24:55PM -0300, Mauro Carvalho Chehab wrote: > > Em Mon, 23 Apr 2018 12:38:03 -0500 > > "Gustavo A. R. Silva" escreveu: > > > @@ -875,6 +876,7 @@ static int

Re: [PATCH v2 11/15] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections

Hi Philipp, On Mon 23 Apr 2018 at 15:46, Philipp Zabel wrote: On Mon, 2018-04-23 at 14:47 +0100, Rui Miguel Silva wrote: This patch adds the device tree nodes for csi, video multiplexer and mipi-csi besides the graph connecting the necessary endpoints to make the media capture entities to

Re: [PATCH v3 0/7] TDA998x CEC support

On 04/09/18 14:15, Russell King - ARM Linux wrote: > Hi, > > This patch series adds CEC support to the DRM TDA998x driver. The > TDA998x family of devices integrate a TDA9950 CEC at a separate I2C > address from the HDMI encoder. > > Implementation of the CEC part is separate to allow

Re: [PATCH v2 13/13] media: imx274: add SELECTION support for cropping

Hi Luca, Thank you for the patchset. Some comments below... what I propose is that I apply the rest of the patches and then the comments to this one could be addressed separately. Would that work for you? On Tue, Apr 24, 2018 at 10:24:18AM +0200, Luca Ceresoli wrote: > Currently this driver

Re: [PATCH 1/1] media: rc: Add NVIDIA IR keymapping

On Fri, Apr 20, 2018 at 11:47:47AM -0700, Vladislav Zhurba wrote: > From: Jun Yan > > Add keymap with NEC and SONY12 protocol for NVIDIA IR > > Signed-off-by: Jun Yan > Signed-off-by: marting > Signed-off-by: Daniel Fu

[PATCH 1/1] ov5640: Use dev_fwnode() to obtain device's fwnode

Use dev_fwnode() on the device instead of getting an fwnode handle of the device's OF node. The result is the same on OF-based systems and looks better, too. Signed-off-by: Sakari Ailus --- drivers/media/i2c/ov5640.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[RESEND PATCH 1/1] ov5640: Use dev_fwnode() to obtain device's fwnode

Use dev_fwnode() on the device instead of getting an fwnode handle of the device's OF node. The result is the same on OF-based systems and looks better, too. Signed-off-by: Sakari Ailus --- Fixed Maxime's e-mail. drivers/media/i2c/ov5640.c | 4 ++-- 1 file

Re: [RESEND PATCH] media: i2c: ov5640: Add pixel clock support

Hi Sakari, >> Any comments on this change? > > > > There's also another set that adds PIXEL_CLOCK (as well as LINK_FREQ) > support to the driver, that seems more complete than this patch but > requires

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

On Tue, Apr 24, 2018 at 12:36:09PM +0200, Peter Zijlstra wrote: > > Then usespace probes which part of the descr[] array is now in cache and > from that it can infer the initial out-of-bound value. Just had a better look at v4l_fill_fmtdesc() and actually read the comment. The code cannot be

Re: [PATCH 2/3] media: ov5640: add PIXEL_RATE and LINK_FREQ controls

Hi, On Tuesday, April 24, 2018 12:22 PM, Sakari Ailus wrote: > On Fri, Apr 20, 2018 at 11:44:18AM +0200, Daniel Mack wrote: >> Add v4l2 controls to report the pixel and MIPI link rates of each mode. >> The camss camera subsystem needs them to set up the correct hardware >> clocks. >> >> Tested on

[PATCH v11 4/4] v4l: cadence: Add Cadence MIPI-CSI2 TX driver

The Cadence MIPI-CSI2 TX controller is an hardware block meant to be used as a bridge between pixel interfaces and a CSI-2 bus. It supports operating with an internal or external D-PHY, with up to 4 lanes, or without any D-PHY. The current code only supports the latter case. While the virtual

[PATCH v11 1/4] dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings

The Cadence MIPI-CSI2 RX controller is a CSI2RX bridge that supports up to 4 CSI-2 lanes, and can route the frames to up to 4 streams, depending on the hardware implementation. It can operate with an external D-PHY, an internal one or no D-PHY at all in some configurations. Acked-by: Rob Herring

[PATCH v11 3/4] dt-bindings: media: Add Cadence MIPI-CSI2 TX Device Tree bindings

The Cadence MIPI-CSI2 TX controller is a CSI2 bridge that supports up to 4 video streams and can output on up to 4 CSI-2 lanes, depending on the hardware implementation. It can operate with an external D-PHY, an internal one or no D-PHY at all in some configurations. Acked-by: Rob Herring

[PATCH v11 2/4] v4l: cadence: Add Cadence MIPI-CSI2 RX driver

The Cadence CSI-2 RX Controller is an hardware block meant to be used as a bridge between a CSI-2 bus and pixel grabbers. It supports operating with internal or external D-PHY, with up to 4 lanes, or without any D-PHY. The current code only supports the latter case. It also support dynamic

[PATCH v11 0/4] media: v4l: Add support for the Cadence MIPI-CSI2 TX controller

Hi, Here is a hopefully final attempt at supporting the MIPI-CSI2 RX and TX blocks from Cadence. This is a merged serie of the CSI2-RX and CSI2-TX series I've been sending for a while now and gathered a significant amount of Reviewed-by/Acked-by. The merge has been done thanks to Sakari's

[PATCH 27/28] venus: add sdm845 compatible and resource data

This adds sdm845 DT compatible string with it's resource data table. Cc: devicet...@vger.kernel.org Signed-off-by: Stanimir Varbanov --- .../devicetree/bindings/media/qcom,venus.txt | 1 + drivers/media/platform/qcom/venus/core.c | 22

[PATCH 17/28] venus: delete no longer used bufmode flag from instance

Delete no longer used flag cap_bufs_mode_dynamic from instance structure. Signed-off-by: Stanimir Varbanov --- drivers/media/platform/qcom/venus/core.h | 2 -- drivers/media/platform/qcom/venus/hfi_parser.c | 6 +- 2 files changed, 1 insertion(+), 7

[PATCH 15/28] venus: add a helper function to set dynamic buffer mode

Adds a new helper function to set dymaic buffer mode if it is supported by current HFI version. Signed-off-by: Stanimir Varbanov --- drivers/media/platform/qcom/venus/helpers.c | 22 ++ drivers/media/platform/qcom/venus/helpers.h | 1 +

[PATCH 14/28] venus: helpers: rename a helper function and use buffer mode from caps

Rename is_reg_unreg_needed() to better name is_dynamic_bufmode() and use buffer mode from enumerated per codec capabilities. Signed-off-by: Stanimir Varbanov --- drivers/media/platform/qcom/venus/helpers.c | 21 +++-- 1 file changed, 11

[PATCH 08/28] venus: hfi_venus: add suspend function for 4xx version

This adds suspend (power collapse) function with slightly different order of calls comparing with Venus 3xx. Signed-off-by: Stanimir Varbanov --- drivers/media/platform/qcom/venus/hfi_venus.c | 52 +++ 1 file changed, 52 insertions(+) diff

[PATCH 06/28] venus: hfi: handle buffer output2 type as well

This adds handling of buffers of type OUTPUT2 which is needed to support Venus 4xx version. Signed-off-by: Stanimir Varbanov --- drivers/media/platform/qcom/venus/hfi.c | 3 ++- drivers/media/platform/qcom/venus/hfi_msgs.c | 3 ++- 2 files changed, 4

[PATCH 05/28] venus: hfi: support session continue for 4xx version

This makes possible to handle session_continue for 4xx as well. Signed-off-by: Stanimir Varbanov --- drivers/media/platform/qcom/venus/hfi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/qcom/venus/hfi.c

Re: [RESEND PATCH 1/1] ov5640: Use dev_fwnode() to obtain device's fwnode

On Tue, Apr 24, 2018 at 02:10:29PM +0300, Sakari Ailus wrote: > Use dev_fwnode() on the device instead of getting an fwnode handle of the > device's OF node. The result is the same on OF-based systems and looks > better, too. > > Signed-off-by: Sakari Ailus

[PATCH 28/28] venus: add HEVC codec support

This add HEVC codec support for venus versions 3xx and 4xx. Signed-off-by: Stanimir Varbanov --- drivers/media/platform/qcom/venus/helpers.c | 3 +++ drivers/media/platform/qcom/venus/hfi.c | 2 ++ drivers/media/platform/qcom/venus/vdec.c| 4

[PATCH 25/28] venus: move frame size calculations in common place

move calculations of raw and compressed in a common helper and make it identical for encoder and decoder. Signed-off-by: Stanimir Varbanov --- drivers/media/platform/qcom/venus/helpers.c | 98 +

  1   2   >