regmap for i2c pages

I'm working on a driver for an i2c based media controller device that uses pages. By that I mean there are several pages of 8bit registers and a page-select register that holds the current page. Multiple accesses to the same page can occur without writing to this page register but if you want to

Re: [PATCH v7] dw9714: Initial driver for dw9714 VCM

On Thu, Jun 01, 2017 at 11:06:51PM -0700, Rajmohan Mani wrote: > +static int dw9714_probe(struct i2c_client *client, > + const struct i2c_device_id *devid) > +{ > + struct dw9714_device *dw9714_dev; > + int rval; > + > + dw9714_dev = devm_kzalloc(>dev,

Re: [PATCH v2 00/27] Revised full patchset for PCM in-kernel copy support

On Jul 02 2017 05:58, Takashi Iwai wrote: Hi, this is a full patchset of what I sent previously, containing the all changes instead of the snippet. The main purpose of this patchset is to eliminate the remaining usages of set_fs(). They are basically used for in-kernel PCM data transfer, and

Re: [PATCH v7 1/1] [media] i2c: add support for OV13858 sensor

Hi Hyungwoo, On Thu, Jun 01, 2017 at 03:45:16PM -0700, Hyungwoo Yang wrote: ... > +static int ov13858_probe(struct i2c_client *client, > + const struct i2c_device_id *devid) > +{ > + struct ov13858 *ov13858; > + int ret; > + > + ov13858 = devm_kzalloc(>dev,

[PATCH v7] dw9714: Initial driver for dw9714 VCM

DW9714 is a 10 bit DAC, 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: Rajmohan Mani --- Changes in v7: - Removed DW9714 ACPI hwid from ACPI match table, until

Re: [PATCH] ALSA: hda - Fix applying MSI dual-codec mobo quirk

Hello! On 6/1/2017 11:58 PM, Takashi Iwai wrote: The previous commit [63691587f7b0: ALSA: hda - Apply dual-codec quirk for MSI Z270-Gaming mobo] attempted to apply the existing dual-codec The standard way of citing a commit is: commit 63691587f7b0 ("ALSA: hda - Apply dual-codec quirk for

[PATCH][media] atomisp: make repool_pgnr and punit_ddr_dvfs_enable static

From: Colin Ian King integer repool_pgnr and function punit_ddr_dvfs_enable can be made static as they do not need to be in global scope. Cleans up sparse warnings: "symbol 'repool_pgnr' was not declared. Should it be static?" "symbol 'punit_ddr_dvfs_enable' was not

[PATCH] cec: add cec_transmit_attempt_done helper function

A simpler variant of cec_transmit_done to be used where the HW does just a single attempt at a transmit. So if the status indicates an error, then the corresponding error count will always be 1 and this function figures that out based on the status argument. Signed-off-by: Hans Verkuil

[PATCH 0/3] tc358743: minor driver fixes

These 3 patches for TC358743 came out of trying to use the existing driver with a new Raspberry Pi CSI-2 receiver driver. A couple of the subdevice API calls were not implemented or otherwise gave odd results. Those are fixed. The TC358743 interface board being used didn't have the IRQ line

Re: [PATCH 0/3] tc358743: minor driver fixes

On 06/02/17 14:18, Dave Stevenson wrote: > These 3 patches for TC358743 came out of trying to use the > existing driver with a new Raspberry Pi CSI-2 receiver driver. Nice! Doing that has been on my todo list for ages but I never got around to it. I have one of these and using the Raspberry Pi

Re: [PATCH 4.4 058/103] [media] ttusb2: limit messages to buffer size

[Dropped cc to stable and LKML.] On Tue, 2017-05-23 at 22:09 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Alyssa Milburn > > commit a12b8ab8c5ff7ccd7b107a564743507c850a441d

[PATCH 2/3] [media] tc358743: Setup default mbus_fmt before registering

Previously the mbus_fmt_code was set after the device was registered. If a connected sub-device called tc358743_get_fmt prior to that point it would get an invalid code back. Signed-off-by: Dave Stevenson --- drivers/media/i2c/tc358743.c | 3 ++- 1 file changed,

[PATCH 3/3] [media] tc358743: Add support for platforms without IRQ line

interrupts is listed as an optional property in the DT binding, but in reality the driver didn't work without it. The existing driver relied on having the interrupt line connected to the SoC to trigger handling various events. Add the option to poll the interrupt status register via a timer if no

[PATCH 1/3] [media] tc358743: Add enum_mbus_code

There was no way to query the supported mbus formats from this driver. enum_mbus_code is the function to expose that, so implement it. Signed-off-by: Dave Stevenson --- drivers/media/i2c/tc358743.c | 18 ++ 1 file changed, 18 insertions(+) diff

Re: [PATCH 0/3] tc358743: minor driver fixes

Hi Hans. On 2 June 2017 at 13:35, Hans Verkuil wrote: > On 06/02/17 14:18, Dave Stevenson wrote: >> These 3 patches for TC358743 came out of trying to use the >> existing driver with a new Raspberry Pi CSI-2 receiver driver. > > Nice! Doing that has been on my todo list for

Support for RGB/YUV 10, 12 BPC(bits per color/component) image data formats in kernel

Hi all, I have tried searching for RGB/YUV 10, 12 BPC formats in videodev2.h, media-bus-format.h and drm_fourcc.h I could only find RGB 10BPC support in drm_fourcc.h. I guess not much support is present for formats with (BPC > 8) in the kernel. Are there any plans to add fourcc defines for such

Re: [PATCH 0/3] tc358743: minor driver fixes

On 06/02/17 15:03, Dave Stevenson wrote: > Hi Hans. > > On 2 June 2017 at 13:35, Hans Verkuil wrote: >> On 06/02/17 14:18, Dave Stevenson wrote: >>> These 3 patches for TC358743 came out of trying to use the >>> existing driver with a new Raspberry Pi CSI-2 receiver driver.

Re: [PATCH 0/3] tc358743: minor driver fixes

Hi Dave, On Fri, 2017-06-02 at 15:36 +0100, Dave Stevenson wrote: [...] > >> > Are you aware of the HDMI modes that the TC358743 driver has been used > >> > with? > >> > The comments mention 720P60 at 594MHz, but I have had to modify the > >> > fifo_level value from 16 to 110 to get VGA60 or

Re: [PATCH 0/3] tc358743: minor driver fixes

On 2 June 2017 at 15:13, Philipp Zabel wrote: > On Fri, 2017-06-02 at 15:27 +0200, Hans Verkuil wrote: >> On 06/02/17 15:03, Dave Stevenson wrote: >> > Hi Hans. >> > >> > On 2 June 2017 at 13:35, Hans Verkuil wrote: >> >> On 06/02/17 14:18, Dave

Re: [PATCH 0/3] tc358743: minor driver fixes

On Fri, 2017-06-02 at 15:27 +0200, Hans Verkuil wrote: > On 06/02/17 15:03, Dave Stevenson wrote: > > Hi Hans. > > > > On 2 June 2017 at 13:35, Hans Verkuil wrote: > >> On 06/02/17 14:18, Dave Stevenson wrote: > >>> These 3 patches for TC358743 came out of trying to use the >

[PATCH 1/9] [media] s5p-jpeg: Reset the Codec before doing a soft reset

From: Abhilash Kesavan This patch resets the encoding and decoding register bits before doing a soft reset. Signed-off-by: Tony K Nadackal Signed-off-by: Thierry Escande ---

[PATCH 0/9] [media] s5p-jpeg: Various fixes and improvements

Hi, This series contains various fixes and improvements for the Samsung s5p-jpeg driver. All these patches come from the Chromium v3.8 kernel tree. Regards, Thierry Abhilash Kesavan (1): [media] s5p-jpeg: Reset the Codec before doing a soft reset Ricky Liang (1): [media] s5p-jpeg: Add

[PATCH 4/9] [media] s5p-jpeg: Decode 4:1:1 chroma subsampling format

From: Tony K Nadackal This patch adds support for decoding 4:1:1 chroma subsampling in the jpeg header parsing function. Signed-off-by: Tony K Nadackal Signed-off-by: Thierry Escande ---

[PATCH 9/9] [media] s5p-jpeg: Add support for multi-planar APIs

From: Ricky Liang This patch adds multi-planar APIs to the s5p-jpeg driver. The multi-planar APIs are identical to the exisiting single-planar APIs except the plane format info is stored in the v4l2_pixel_format_mplan struct instead of the v4l2_pixel_format struct.

[PATCH 2/9] [media] s5p-jpeg: Call jpeg_bound_align_image after qbuf

From: Tony K Nadackal When queuing an OUTPUT buffer for decoder, s5p_jpeg_parse_hdr() function parses the input jpeg file and takes the width and height parameters from its header. These new width/height values will be used for the calculation of stride. HX_JPEG Hardware

[PATCH 5/9] [media] s5p-jpeg: Add IOMMU support

From: Tony K Nadackal This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU and ARM DMA IOMMU configurations are supported. The address space is created with size limited to 256M and base address set to 0x2000. Signed-off-by: Tony K Nadackal

[PATCH 6/9] [media] s5p-jpeg: Add support for resolution change event

From: henryhsu This patch adds support for resolution change event to notify clients so they can prepare correct output buffer. When resolution change happened, G_FMT for CAPTURE should return old resolution and format before CAPTURE queues streamoff. Signed-off-by:

[PATCH 7/9] [media] s5p-jpeg: Change sclk_jpeg to 166MHz for Exynos5250

From: henryhsu The default clock parent of jpeg on Exynos5250 is fin_pll, which is 24MHz. We have to change the clock parent to CPLL, which is 333MHz, and set sclk_jpeg to 166MHz. Signed-off-by: Heng-Ruey Hsu Signed-off-by: Thierry Escande

[PATCH 8/9] [media] s5p-jpeg: Add stream error handling for Exynos5420

From: henryhsu On Exynos5420, the STREAM_STAT bit raised on the JPGINTST register means there is a syntax error or an unrecoverable error on compressed file when ERR_INT_EN is set to 1. Fix this case and report BUF_STATE_ERROR to videobuf2. Signed-off-by: Henry-Ruey Hsu

Re: regmap for i2c pages

On Thu, Jun 01, 2017 at 11:37:43PM -0700, Tim Harvey wrote: > I believe this is a very common i2c register mechanism but I'm not > clear what the best way to use i2c regmap for this is. I'm reading > that regmap 'handles register pages' but I'm not clear if that's the > same thing I'm looking

[PATCH 3/9] [media] s5p-jpeg: Correct WARN_ON statement for checking subsampling

From: Tony K Nadackal Corrects the WARN_ON statement for subsampling based on the JPEG Hardware version. Signed-off-by: Tony K Nadackal Signed-off-by: Thierry Escande --- drivers/media/platform/s5p-jpeg/jpeg-core.c | 6

Re: [PATCH v2 02/27] ALSA: pcm: Introduce copy_user, copy_kernel and fill_silence ops

On Thu, Jun 01, 2017 at 10:58:25PM +0200, Takashi Iwai wrote: > For supporting the explicit in-kernel copy of PCM buffer data, and > also for further code refactoring, three new PCM ops, copy_user, > copy_kernel and fill_silence, are introduced. The old copy and > silence ops will be deprecated

Re: [PATCH v2 14/27] ASoC: blackfin: Convert to the new PCM ops

On Thu, Jun 01, 2017 at 10:58:37PM +0200, Takashi Iwai wrote: > Replace the copy and the silence ops with the new PCM ops. > In AC97 and I2S-TDM mode, we need to convert back to frames, but > otherwise the conversion is pretty straightforward. Acked-by: Mark Brown

Re: [PATCH] ARM: dts: exynos: Add HDMI CEC device to Exynos5 SoC family

On Thu, Jun 01, 2017 at 08:19:23AM +0200, Marek Szyprowski wrote: > Hi Krzysztof, > > On 2017-05-31 21:55, Krzysztof Kozlowski wrote: > > On Wed, May 31, 2017 at 01:00:17PM +0200, Marek Szyprowski wrote: > > > Exynos5250 and Exynos542x SoCs have the same CEC hardware module as > > > Exynos4 SoC

Re: [PATCH 2/9] [media] s5p-jpeg: Call jpeg_bound_align_image after qbuf

Hi Thierry, Thanks for the patch. On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Tony K Nadackal > > When queuing an OUTPUT buffer for decoder, s5p_jpeg_parse_hdr() > function parses the input jpeg file and takes the width and height > parameters from its header.

RE: [PATCH v7 1/1] [media] i2c: add support for OV13858 sensor

Hi Sakari, I have fixed runtime PM calls in .probe() and .remove(). I'll submit v8 Thanks, Hyungwoo -Original Message- > From: Sakari Ailus [mailto:sakari.ai...@iki.fi] > Sent: Friday, June 2, 2017 12:54 AM > To: Yang, Hyungwoo > Cc:

[PATCH v8 1/1] [media] i2c: add support for OV13858 sensor

This patch adds driver for Omnivision's ov13858 sensor, the driver supports following features: - manual exposure/analog gain - two link frequencies - VBLANK support - test pattern support - media controller support - runtime pm support - supported resolutions + 4224x3136 at 30FPS + 2112x1568

Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support

Cc Marek Szyprowski. Marek, could you share your opinion about this patch? On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Tony K Nadackal > > This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU > and ARM DMA IOMMU configurations are supported. The

Re: [PATCH 7/9] [media] s5p-jpeg: Change sclk_jpeg to 166MHz for Exynos5250

Cc Marek and Sylwester. On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: henryhsu > > The default clock parent of jpeg on Exynos5250 is fin_pll, which is > 24MHz. We have to change the clock parent to CPLL, which is 333MHz, > and set sclk_jpeg to 166MHz. > >

[PATCH 0/4] [media] davinci: vpif_capture: raw camera support

This series fixes/updates the support for raw camera input to the VPIF. Tested on da850-evm boards using the add-on UI board. Tested with both composite video input (on-board tvp514x) and raw camera input using the camera board from On-Semi based on the aptina,mt9v032 sensor[1], as this was the

[PATCH 4/4] [media] davinci: vpif: adaptions for DT support

The davinci VPIF is a single hardware block, but the existing driver is broken up into a common library (vpif.c), output (vpif_display.c) and intput (vpif_capture.c). When migrating to DT, to better model the hardware, and because registers, interrupts, etc. are all common,it was decided to have

[PATCH 1/4] [media] davinci: vpif_capture: drop compliance hack

Capture driver silently overrides pixel format with a hack (according to the comments) to pass v4l2 compliance tests. This isn't needed for normal functionality, and works for composite video and raw camera capture without. In addition, the hack assumes that it only supports raw capture with a

[PATCH 3/4] [media] davinci: vpif_capture: cleanup raw camera support

The current driver has a handful of hard-coded assumptions based on its primary use for capture of video signals. Cleanup those assumptions, and also query the subdev for format information and use that if available. Tested with 10-bit raw bayer input (SGRBG10) using the aptina,mt9v032 sensor,

[PATCH 2/4] [media] davinci: vpif_capture: get subdevs from DT when available

Enable getting of subdevs from DT ports and endpoints. The _get_pdata() function was larely inspired by (i.e. stolen from) am437x-vpfe.c Signed-off-by: Kevin Hilman --- drivers/media/platform/davinci/vpif_capture.c | 126 +-

Re: [PATCH 4/9] [media] s5p-jpeg: Decode 4:1:1 chroma subsampling format

Hi Thierry, On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Tony K Nadackal > > This patch adds support for decoding 4:1:1 chroma subsampling in the > jpeg header parsing function. > > Signed-off-by: Tony K Nadackal > Signed-off-by: Thierry

Re: [PATCH 6/9] [media] s5p-jpeg: Add support for resolution change event

Hi Thierry, On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: henryhsu > > This patch adds support for resolution change event to notify clients so > they can prepare correct output buffer. When resolution change happened, > G_FMT for CAPTURE should return old

Re: [PATCH 9/9] [media] s5p-jpeg: Add support for multi-planar APIs

Hi Thierry, What is the gain of introducing multiplanar API for this hardware? AFAIR all the HW implementations store the data in a single contiguous memory region and use suitable padding between planes. On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Ricky Liang >

[PATCH] staging: atomisp: Fix endless recursion in hmm_init

hmm_init calls hmm_alloc to set dummy_ptr, hmm_alloc calls hmm_init when dummy_ptr is not yet set, which is the case in the call from hmm_init, so it calls hmm_init again, this continues until we have a stack overflow due to the recursion. This commit fixes this by adding a separate flag for

Re: Firmware for staging atomisp driver

Hi, On 05/28/2017 02:30 PM, Hans de Goede wrote: Hi All, I've been trying to get the atomisp driver from staging to work on a couple of devices I have. I started with an Asus T100TA after fixing 2 oopses in the sensor driver there I found out that the BIOS does not allow to put the ISP in PCI

Re: [PATCH 1/9] [media] s5p-jpeg: Reset the Codec before doing a soft reset

Hi Thierry, On 06/02/2017 06:02 PM, Thierry Escande wrote: > From: Abhilash Kesavan > > This patch resets the encoding and decoding register bits before doing a > soft reset. > > Signed-off-by: Tony K Nadackal > Signed-off-by: Thierry Escande

[RFC PATCH v3 04/11] [media] vimc: common: Add vimc_pipeline_s_stream helper

Move the vimc_cap_pipeline_s_stream from the vimc-cap.c to vimc-common.c as this core will be reused by other subdevices to activate the stream in their directly connected nodes Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: Add vimc_pipeline_s_stream in

[RFC PATCH v3 03/11] [media] vimc: common: Add vimc_ent_sd_* helper

As all the subdevices in the topology will be initialized in the same way, to avoid code repetition the vimc_ent_sd_{register, unregister} helper functions were created Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: Add vimc_ent_sd_* helper functions

Re: [media] vimc: API proposal, configuring the topology from user space

ping On 2017-04-10 07:53 PM, Helen Koike wrote: Hi, Continuing the discussion about the API of the vimc driver, I made some changes based on the previous comments, please see below and let me know your opinion about it. Helen /*** Configfs considerations:

cron job: media_tree daily build: WARNINGS

This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Jun 3 05:00:21 CEST 2017 media-tree git hash:36bcba973ad478042d1ffc6e89afd92e8bd17030 media_build

Re: media_build: fails to install

On Wed, May 31, 2017 at 03:57:04AM +0300, Olli Salonen wrote: > It seems that I'm able to build the media_build correctly on Ubuntu > 16.04.2 with kernel 4.8, but make install fails: > > ~/src/media_build$ sudo make install > make -C /home/olli/src/media_build/v4l install > make[1]: Entering

[RFC PATCH v3 06/11] [media] vimc: sen: Support several image formats

Allow user space to change the image format as the frame size, the media bus pixel format, colorspace, quantization, field YCbCr encoding and the transfer function Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: sen: Support several image formats

[RFC PATCH v3 07/11] [media] vimc: cap: Support several image formats

Allow user space to change the image format as the frame size, the pixel format, colorspace, quantization, field YCbCr encoding and the transfer function Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: cap: Support several image formats - use

[RFC PATCH v3 02/11] [media] vimc: Move common code from the core

Remove helper functions from vimc-core and add it in vimc-common to clean up the core. Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: Move common code from the core - This is a new patch in the series Changes in v2: None ---

[RFC PATCH v3 01/11] [media] vimc: sen: Integrate the tpg on the sensor

Initialize the test pattern generator on the sensor Generate a colored bar image instead of a grey one Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: sen: Integrate the tpg on the sensor - Declare frame_size as a local variable - Set tpg

[RFC PATCH v3 10/11] [media] vimc: deb: Add debayer filter

Implement the debayer filter and integrate it with the core Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: deb: Add debayer filter - Declare frame_size as a local variable - s_stream(sd, 1): return 0 if stream is already enabled -

[RFC PATCH v3 09/11] [media] vimc: Subdevices as modules

Change the core structure for adding subdevices in the topology. Instead of calling the specific create function for each subdevice, inject a child platform_device with the driver's name. Each type of node in the topology (sensor, capture, debayer, scaler) will register a platform_driver with the

[RFC PATCH v3 08/11] [media] vimc: Optimize frame generation through the pipe

Add a parameter called vsen_tpg, if true then vimc will work as before: frames will be generated in the sensor nodes then propagated through the pipe and processed by each node until a capture node is reached. If vsen_tpg is false, then the frame is not generated by the sensor, but directly from

[RFC PATCH v3 11/11] [media] vimc: sca: Add scaler

Implement scaler and integrated with the core Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: sca: Add scaler - Declare frame_size as a local variable - s_stream(sd, 1): return 0 if stream is already enabled - s_stream(sd, 0):

[RFC PATCH v3 05/11] [media] vimc: common: Add vimc_link_validate

All links will be checked in the same way. Adding a helper function for that Signed-off-by: Helen Koike --- Changes in v3: [media] vimc: common: Add vimc_link_validate - this is a new patch in the series Changes in v2: None ---

[RFC PATCH v3 00/11] [media]: vimc: Virtual Media Control VPU's

This patch series improves the current video processing units in vimc (by adding more controls to the sensor and capture node, allowing the user to configure different frame formats) and also adds a debayer and a scaler node. The debayer transforms the bayer format image received in its sink pad

Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support

On Fri, Jun 2, 2017 at 10:02 AM, Thierry Escande wrote: > From: Tony K Nadackal > > This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU > and ARM DMA IOMMU configurations are supported. The address space is > created with size