On Tue, 2019-09-03 at 07:54 +, Jonas Karlman wrote:
[...]
> After a closer look both ffmpeg and rkmpp only apply zig-zag scan and not
> field scan,
> ffmpeg will memcpy the scaling_matrix4/8 as is for vaapi, vdpau and nvdec,
> for dxva2 there is a workaround flag that controls if zig-zag
Hi Jonas,
On Sun, 2019-09-01 at 12:45 +, Jonas Karlman wrote:
> A decoded 8-bit 4:2:0 frame need memory for up to 448 macroblocks
> and is laid out in memory as follow:
Do you mean "A decoded 8-bit 4:2:0 frame needs up to 448 bytes per
macroblock"?
A 1280x720 frame already consists of 3600
On Mon, 2019-09-02 at 16:18 +, Jonas Karlman wrote:
> On 2019-09-02 16:00, Philipp Zabel wrote:
> > Hi Jonas,
> >
> > On Sun, 2019-09-01 at 12:45 +, Jonas Karlman wrote:
> > > Scaling list supplied from userspace using ffmpeg and libva-v4l2-request
> >
On Mon, 2019-09-02 at 16:01 +0100, Rob Herring wrote:
> On Sun, 1 Sep 2019 23:14:07 +0530, Sibi Sankar wrote:
> > Convert PDC Global bindings to yaml and add SC7180 PDC global to the list
> > of possible bindings.
> >
> > Signed-off-by: Sibi Sankar
> > ---
> >
Hi Andy,
On Mon, 2019-09-02 at 16:19 +0300, Andy Shevchenko wrote:
> On Mon, Aug 19, 2019 at 01:52:52PM +0300, Andy Shevchenko wrote:
> > It seems the commit bb475230b8e5
> > ("reset: make optional functions really optional")
> > brought couple of redundant lines in the comments.
> >
> > Drop
Hi Jonas,
On Sun, 2019-09-01 at 12:45 +, Jonas Karlman wrote:
> Scaling list supplied from userspace using ffmpeg and libva-v4l2-request
> is already in matrix order and can be used without applying the inverse
> scanning process.
"in matrix order" is equivalent to "in raster scan order"?
t;dev, "Can't get amba reset!\n");
> + return PTR_ERR(rstc);
> + }
> + reset_control_deassert(rstc);
> + reset_control_put(rstc);
>
> /*
>* Read pid and cid based on size of resource
Reviewed-by: Philipp Zabel
regards
Philipp
On Mon, 2019-08-26 at 10:42 -0500, Dinh Nguyen wrote:
> The primecell controller on some SoCs, i.e. SoCFPGA, is held in reset by
> default. Until recently, the DMA controller was brought out of reset by the
> bootloader(i.e. U-Boot). But a recent change in U-Boot, the peripherals
> that are not
Hi Dinh, Linus,
On Fri, 2019-08-23 at 10:42 -0500, Dinh Nguyen wrote:
>
> On 8/23/19 4:19 AM, Linus Walleij wrote:
> > On Tue, Aug 20, 2019 at 4:58 PM Dinh Nguyen wrote:
> >
> > > @@ -401,6 +402,26 @@ static int amba_device_try_add(struct amba_device
> > > *dev, struct resource *parent)
> > >
On Sat, 2019-08-24 at 20:54 +0530, Sibi Sankar wrote:
> Add SC7180 AOSS reset to the list of possible bindings.
>
> Signed-off-by: Sibi Sankar
> ---
> Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Fri, 2019-08-23 at 15:05 +0200, Ricardo Ribalda Delgado wrote:
> On Fri, Aug 23, 2019 at 2:56 PM Philipp Zabel wrote:
> >
> > On Fri, 2019-08-23 at 14:37 +0200, Ricardo Ribalda Delgado wrote:
> > > Adding a V4L2_CID_UNIT_CELL_SIZE control requires a lot of boilerplat
On Fri, 2019-08-23 at 14:37 +0200, Ricardo Ribalda Delgado wrote:
> According to the product brief, the unit cell size is 1120 nanometers^2.
>
> https://www.sony-semicon.co.jp/products_en/IS/sensor1/img/products/ProductBrief_IMX214_20150428.pdf
>
> Signed-off-by: Ricardo Ribalda Delgado
If the
On Fri, 2019-08-23 at 14:37 +0200, Ricardo Ribalda Delgado wrote:
> Adding a V4L2_CID_UNIT_CELL_SIZE control requires a lot of boilerplate,
> try to minimize it by adding a new helper.
>
> Suggested-by: Philipp Zabel
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> drivers
On Fri, 2019-08-23 at 14:37 +0200, Ricardo Ribalda Delgado wrote:
> A struct v4l2_area containing the width and the height of a rectangular
> area.
>
> Signed-off-by: Ricardo Ribalda Delgado
> Suggested-by: Hans Verkuil
> ---
> Documentation/media/uapi/v4l/vidioc-queryctrl.rst | 6 ++
> 1
On Fri, 2019-08-23 at 14:37 +0200, Ricardo Ribalda Delgado wrote:
> New control to pass to userspace the width/height of a pixel. Which is
> needed for calibration and lens selection.
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> Documentation/media/uapi/v4l/ext-ctrls-image-source.rst | 8
On Fri, 2019-08-23 at 17:47 +0800, Dilip Kota wrote:
[...]
> Thanks for pointing it out.
> Reset is not supported on LGM platform.
> I will update the reset_device() definition to "return -EOPNOTSUPP"
In that case you can just drop intel_reset_device() completely,
the core checks whether
Hi Dilip,
On Fri, 2019-08-23 at 13:28 +0800, Dilip Kota wrote:
> Add driver for the reset controller present on Intel
> Lightening Mountain (LGM) SoC for performing reset
> management of the devices present on the SoC. Driver also
> registers a reset handler to peform the entire device reset.
>
On Thu, 2019-08-22 at 13:10 +0200, Guido Günther wrote:
> The only mux controls the MIPI DSI input selection.
>
> Signed-off-by: Guido Günther
Reviewed-by: Philipp Zabel
regards
Philipp
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 9 -
> 1 file changed,
On Wed, 2019-08-21 at 19:42 +0200, Guido Günther wrote:
> Hi,
> On Tue, Aug 13, 2019 at 01:07:52PM +0200, Arnd Bergmann wrote:
> > On Tue, Aug 13, 2019 at 12:10 PM Guido Günther wrote:
> > > On Tue, Aug 13, 2019 at 10:08:44AM +0200, Arnd Bergmann wrote:
> > > > On Fri, Aug 9, 2019 at 6:24 PM
On Tue, 2019-08-20 at 11:40 +0200, Ricardo Ribalda Delgado wrote:
> According to the product brief, the unit cell size is 1120 nanometers^2.
>
> https://www.sony-semicon.co.jp/products_en/IS/sensor1/img/products/ProductBrief_IMX214_20150428.pdf
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
>
On Wed, 2019-08-21 at 15:24 +0530, Sibi Sankar wrote:
> Add SC7180 AOSS reset to the list of possible bindings.
>
> Signed-off-by: Sibi Sankar
> ---
> Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git
On Tue, 2019-08-20 at 11:40 +0200, Ricardo Ribalda Delgado wrote:
> New control to pass to userspace the width/height of a pixel. Which is
> needed for calibration and lens selection.
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> Documentation/media/uapi/v4l/ext-ctrls-camera.rst | 8
Hi Jerome,
thank you for the patch. Just one nitpick and one real issue below:
On Tue, 2019-08-20 at 11:46 +0200, Jerome Brunet wrote:
> Add the new arb reset lines of the SM1 SoC family
>
> Signed-off-by: Jerome Brunet
> ---
> drivers/reset/reset-meson-audio-arb.c | 28
On Mon, 2019-08-19 at 14:17 +0200, Ricardo Ribalda Delgado wrote:
> New control to pass to userspace the width/height of a pixel. Which is
> needed for 3D calibration and lens selection.
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> Documentation/media/uapi/v4l/ext-ctrls-camera.rst | 6
Hi Fancy,
On Wed, 2019-06-26 at 06:46 +, Fancy Fang wrote:
> Hi Philipp,
>
> Thanks for your comments. And please see my answers below.
>
[...]
> > +Specifying sft-rstn control of devices
> > +==
> > +
> > +Device nodes in Display Mix should specify the
s needed to properly propagate the OUTPUT buffer timestamp to
> the CAPTURE buffer one, which is required for intra-frame references.
>
> * Patches 9 to 11 adds H264 support for Hantro G1 and then enable
> H264 decoding on RK3288.
>
> This series has been tested using MPV
ast ugliness.
>
> Suggested-by: Philipp Zabel
> Signed-off-by: Sudeep Holla
Reviewed-by: Philipp Zabel
regards
Philipp
ast ugliness.
>
> Suggested-by: Philipp Zabel
> Signed-off-by: Sudeep Holla
> ---
> drivers/firmware/arm_scmi/base.c| 2 +-
> drivers/firmware/arm_scmi/clock.c | 10 --
> drivers/firmware/arm_scmi/common.h | 2 ++
> drivers/firmware/arm_scmi/perf.c| 8 +
et providers and consumers.
^
typo
>
> Cc: Philipp Zabel
regards
Philipp
explicit reset is
> chosen, the caller has to specifically assert and then de-assert the
> reset signal by issuing two separate RESET commands.
>
> Add the basic SCMI reset infrastructure that can be used by Linux
> reset controller driver.
>
> Cc: Philipp Zabel
> Signed-off-b
evice
> operations provided by the ARM SCMI framework.
>
> Cc: Philipp Zabel
> Signed-off-by: Sudeep Holla
> ---
> MAINTAINERS| 1 +
> drivers/reset/Kconfig | 11
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-scmi.c | 126 +++
Hi Luis,
On Tue, 2019-07-23 at 17:17 +0200, Luis Oliveira wrote:
> This adds documentation of device tree bindings for the
> DesignWare IP reset controller.
>
> Signed-off-by: Gustavo Pimentel
> Signed-off-by: Luis Oliveira
> Reviewed-by: Rob Herring
Thank you, both applied to reset/next.
tents of imx-ipuv3-crtc.o are built via imxdrm-objs. So
there's no need to keep an extra entry with a non existing config value
(CONFIG_DRM_IMX_IPUV3).
Fixes: 3d1df96ad468 ("drm/imx: merge imx-drm-core and ipuv3-crtc in one
module")
Signed-off-by: Guido Günther
Rev
On Thu, 2019-08-01 at 09:54 +0200, Neil Armstrong wrote:
> This serie updates the Amlogic Reset driver and bindings.
>
> Neil Armstrong (3):
> reset: reset-meson: update with SPDX Licence identifier
> dt-bindings: reset: amlogic,meson-gxbb-reset: update with SPDX Licence
> identifier
>
On Thu, 2019-08-01 at 10:20 +0200, Guido Günther wrote:
> Some of the mipi dsi resets were called
>
> IMX8MQ_RESET_MIPI_DIS__
>
> instead of
>
> IMX8MQ_RESET_MIPI_DSI__
>
> Since they're DSI related this looks like a typo. This fixes the
> only in tree user as well to not break bisecting.
Hi,
On Mon, 2019-07-29 at 09:12 +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Jul 29, 2019 at 02:43:23PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Jul 29, 2019 at 2:36 PM Uwe Kleine-König
> > wrote:
> > > On Fri, Jul 26, 2019 at 08:40:41PM +0200, Jernej Skrabec wrote:
> > > > @@ -371,6
RM SCMI device
> operations provided by the ARM SCMI framework.
>
> Cc: Philipp Zabel
> Signed-off-by: Sudeep Holla
thank you for the patch. I have a few suggestions below.
> ---
> MAINTAINERS| 1 +
> drivers/reset/Kconfig | 10 +++
> driver
On Thu, 2019-07-25 at 11:17 -0300, Ezequiel Garcia wrote:
> From: Francois Buergisser
>
> The Hantro codec is typically used in platforms with an IOMMU,
> so we need to set a proper DMA segment size.
... to make sure the DMA-mapping subsystem produces contiguous mappings?
> Devices without an
Hi Anson,
On Fri, 2019-07-05 at 00:26 +, Anson Huang wrote:
> Hi, Philipp
>
> > On Thu, 2019-07-04 at 17:44 +0800, anson.hu...@nxp.com wrote:
> > > From: Anson Huang
> > >
> > > i.MX8MM can reuse i.MX8MQ's reset driver, update the compatible
> > > property and related info to support
Hi Anson,
On Thu, 2019-07-04 at 17:44 +0800, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> i.MX8MM can reuse i.MX8MQ's reset driver, update the compatible
> property and related info to support i.MX8MM.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V2:
> - Add separate line
On Thu, 2019-07-04 at 09:46 +, Anson Huang wrote:
> Hi, Philipp
>
> > On Thu, 2019-07-04 at 17:25 +0800, anson.hu...@nxp.com wrote:
> > > From: Anson Huang
> > >
> > > i.MX8MM can reuse i.MX8MQ's reset driver, update the compatible
> > > property and related info to support i.MX8MM.
> > >
On Thu, 2019-07-04 at 17:25 +0800, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> i.MX8MM can reuse i.MX8MQ's reset driver, update the compatible
> property and related info to support i.MX8MM.
>
> Signed-off-by: Anson Huang
> ---
> New patch.
> ---
>
atible = "fsl,imx8mm-src",
> "fsl,imx8mq-src", "syscon";
> reg = <0x3039 0x1>;
> interrupts = ;
> #reset-cells = <1>;
Please also update the compatible property documentation in
Documentation/devicetree/bindings/reset/fsl,imx7-src.txt.
With that,
Reviewed-by: Philipp Zabel
regards
Philipp
Hi Anson,
On Mon, 2019-07-01 at 17:39 +0800, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> i.MX8MM SoC has a subset of i.MX8MQ IP block variant, it can reuse
> the i.MX8MQ reset controller driver and just skip those non-existing
> IP blocks, add support for i.MX8MM SoC reset control.
>
>
On Tue, 2019-07-02 at 14:00 -0300, Ezequiel Garcia wrote:
> From: Pawel Osciak
>
> Add the parsed VP8 frame pixel format and controls, to be used
> with the new stateless decoder API for VP8 to provide parameters
> for accelerator (aka stateless) codecs.
>
> Signed-off-by: Pawel Osciak
>
Hi Ezequiel
On Tue, 2019-07-02 at 14:00 -0300, Ezequiel Garcia wrote:
> From: ZhiChao Yu
>
> Introduce VP8 decoding support in RK3288.
>
> Signed-off-by: ZhiChao Yu
> Signed-off-by: Tomasz Figa
> Signed-off-by: Boris Brezillon
> Signed-off-by: Ezequiel Garcia
I have just tried this (with
On Wed, 2019-06-26 at 06:46 +, Fancy Fang wrote:
[...]
> > The same goes for the clock soft enable bits on i.MX8MM. If those
> > bits actually control clock gates, they should not be described as
> > reset controls in the device tree.
>
> [FF] Make sense. The functions provided by the
vfd = media_entity_to_video_device(pad->entity);
> + vfd = media_entity_to_video_device(start);
> if (buftype == vfd->queue->type)
> return >entity;
> }
Reviewed-by: Philipp Zabel
regards
Philipp
Hi Fancy,
thank you for the patch. I have a few questions below.
On Tue, 2019-06-25 at 05:54 +, Fancy Fang wrote:
> This is an reset driver to implement a reset controller
> device DISPMIX on IMX8MM and IMX8MN platforms. Dispmix
> reset is used to reset or enable related buses and clks
> for
On Tue, 2019-06-11 at 18:16 -0700, Steve Longerbeam wrote:
> The output of the IC downsizer unit in both dimensions must be <= 1024
> before being passed to the IC resizer unit. This was causing corrupted
> images when:
>
> input_dim > 1024, and
> input_dim / 2 < output_dim < input_dim
>
> Some
Hi Steve,
On Tue, 2019-05-21 at 18:03 -0700, Steve Longerbeam wrote:
> Retask imx_media_fill_default_mbus_fields() to try colorimetry parameters,
> renaming it to to imx_media_try_colorimetry(), and call it at both sink and
> source pad try_fmt's. The unrelated check for uninitialized field value
oda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-mpeg2.o
> coda-mpeg4.o coda-jpeg.o
> +coda-vpu-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o
> coda-mpeg2.o coda-mpeg4.o coda-jpeg.o
>
> -obj-$(CONFIG_VIDEO_CODA) += coda.o
> +obj-$(CONFIG_VIDEO_CODA) += coda-vpu.o
Thanks,
Reviewed-by: Philipp Zabel
regards
Philipp
On Wed, 2019-06-05 at 15:39 +0200, Hans Verkuil wrote:
> Hi Maxime,
>
> I am wondering if this flag shouldn't be inverted: you set
> V4L2_FMT_FLAG_DYN_RESOLUTION if dynamic resolution is supported,
> otherwise it isn't.
>
> Can all the existing mainlined codec drivers handle midstream
>
Hi Fabio,
On Fri, 2019-05-24 at 08:06 -0300, Fabio Estevam wrote:
> The correct spelling is 'indices', so fix it accordingly.
>
> Signed-off-by: Fabio Estevam
> ---
> Documentation/devicetree/bindings/reset/fsl,imx7-src.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Mon, 2019-05-13 at 19:36 +0530, Manivannan Sadhasivam wrote:
> Hi Philipp,
>
> On Mon, May 13, 2019 at 01:06:29PM +0200, Philipp Zabel wrote:
> > Hi,
> >
> > On Sat, 2019-05-11 at 00:15 +0530, Manivannan Sadhasivam wrote:
> > > Hello,
> > >
>
Hi,
On Sun, 2019-05-12 at 18:32 +0200, Paul Kocialkowski wrote:
[...]
> I would be curious to know what the situation is on the i.MX6 coda
> block, which also seems pretty obscure.
FWIW, I had started collecting things I learned about the BIT processor
in the CODA IP cores, mostly by looking at
Hi,
On Sat, 2019-05-11 at 00:15 +0530, Manivannan Sadhasivam wrote:
> Hello,
>
> This patchset adds reset controller support for Bitmain BM1880 SoC.
> BM1880 SoC has only one reset controller and the reset-simple driver
> has been reused here.
>
> This patchset has been tested on 96Boards
eing null checked
> > so at first this seems like a potential null pointer dereference.
> >
> > In fact, _reset_control_get_from_lookup is only ever called from
> > __reset_control_get, right after checking dev->of_node hence
> > dev can never be null. Clean this up by
Hi Colin,
[added Bartosz to Cc:]
On Thu, 2019-05-09 at 17:00 +0100, Colin King wrote:
> From: Colin Ian King
>
> Pointer dev is being dereferenced when passed to the inlined
> functon dev_name, however, dev is later being null checked.
> Thus there is a potential null pointer dereference on a
;,
> .data = _simple_socfpga },
> @@ -129,6 +133,8 @@ static const struct of_device_id reset_simple_dt_ids[] = {
> .data = _simple_active_low },
> { .compatible = "aspeed,ast2400-lpc-reset" },
> { .compatible = "aspeed,ast2500-lpc-reset" },
> + { .compatible = "bitmain,bm1880-reset",
> + .data = _simple_bm1880 },
> { /* sentinel */ },
> };
With these changes,
Reviewed-by: Philipp Zabel
for both parts.
regards
Philipp
On Tue, 2019-04-02 at 08:20 -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> The header file uses errno constant(s) and the
> ERR_PTR() macro but does not #include the appropriate header files
> that provide those facilities, so add 2 header files to fix
> build errors.
Thank you, applied
Hi Kevin,
On Fri, 2019-03-22 at 15:53 -0700, Kevin Hilman wrote:
[...]
> Could ou make a immtable tag for this in your tree? This is needed for
> some upcoming DT users we'd like to queue for the next cycle.
I have just sent a reset/fixes pull request including this patch.
Once that gets
On Mon, 2019-03-04 at 11:49 +0100, Neil Armstrong wrote:
> The G12A Documentation lacked these 2 reset lines, but they are present and
> used for each USB 2 PHYs.
>
> Add them to the dt-bindings for the upcoming USB support.
>
> Fixes: dbfc54534dfc ("dt-bindings: reset: meson: add g12a
t;failed to acquire reset: %d\n", err);
> + clk_disable_unprepare(sor->clk);
> + return err;
> + }
> +
> err = reset_control_deassert(sor->rst);
> if (err < 0) {
> dev_err(dev, "failed to deassert reset: %d\n", err);
> + reset_control_release(sor->rst);
> clk_disable_unprepare(sor->clk);
> return err;
> }
Reviewed-by: Philipp Zabel
regards
Philipp
uire resets: %d\n", err);
> + goto out;
> + }
> +
> + if (off) {
> err = reset_control_assert(pg->reset);
> - else
> + } else {
> err = reset_control_deassert(pg->reset);
> + if (err < 0)
> + goto out;
>
> - if (err)
> + reset_control_release(pg->reset);
> + }
> +
> +out:
> + if (err) {
> + reset_control_release(pg->reset);
> reset_control_put(pg->reset);
> + }
>
> return err;
> }
Reviewed-by: Philipp Zabel
regards
Philipp
On Thu, 2019-02-21 at 16:25 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Add implementations that apply acquire and release operations to all
> reset controls part of a reset control array.
>
> Signed-off-by: Thierry Reding
Reviewed-by: Philipp Zabel
> ---
&g
Hi Thierry,
On Thu, 2019-02-21 at 16:28 +0100, Thierry Reding wrote:
> On Thu, Feb 21, 2019 at 04:25:53PM +0100, Thierry Reding wrote:
> > From: Philipp Zabel
> >
> > There are cases where a driver needs explicit control over a reset line
> > that is exclusi
Hi Thierry,
On Mon, 2019-03-18 at 10:12 +0100, Thierry Reding wrote:
> On Thu, Feb 21, 2019 at 04:28:58PM +0100, Thierry Reding wrote:
> > On Thu, Feb 21, 2019 at 04:25:53PM +0100, Thierry Reding wrote:
> > > From: Philipp Zabel
> > >
> > > There are cases w
ke in
> account IPU")
>
> Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
regards
Philipp
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
> Add support for the following conversions:
>
> - YUV full-range to YUV limited-range
> - YUV limited-range to YUV full-range
> - YUV limited-range to RGB full-range
> - RGB full-range to YUV limited-range
>
> The last two conversions
On Thu, 2019-03-07 at 15:33 -0800, Steve Longerbeam wrote:
> Only providing the input and output RGB/YUV space to the IC task init
> functions is not sufficient. To fully characterize a colorspace
> conversion, the colorspace (chromaticities), Y'CbCr encoding standard,
> and quantization also need
cale << 8) |
> - (params->sat << 9);
> + (params->sat << 10);
> writel(param, base++);
>
> param = ((a[1] & 0x1f) << 27) | ((c[0][1] & 0x1ff) << 18) |
Reviewed-by: Philipp Zabel
regards
Philipp
rgb table is just an identity matrix, so rename to
> ic_encode_identity.
>
> Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")
>
> Suggested-by: Philipp Zabel
> Signed-off-by: Steve Longerbeam
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/ipu
he number of cells needed to encode a
>reset source. The type shall be a and the value shall be 2.
Thank you, I think it makes sense for this to be merged together with
the other patch via the linux-hisi tree.
Acked-by: Philipp Zabel
regards
Philipp
t;
> > For instances using of_node_cmp, this has the side effect of now using
> > case sensitive comparisons. This should not matter for any FDT based
> > system which this is.
> >
> > Cc: Philipp Zabel
> > Cc: David Airlie
> > Cc: dri-de...@lists.freedesktop
On Tue, 2019-02-12 at 09:42 -0800, Steve Longerbeam wrote:
[...]
> > > But what about this "SAT_MODE" field in the IC task parameter memory?
> >
> > That just controls the saturation. The result after the matrix
> > multiplication is either saturated to [0..255] or to [16..235]/[16..240]
> > when
Hi Steve,
On Mon, 2019-02-11 at 17:20 -0800, Steve Longerbeam wrote:
[...]
> > Should we support YUV BT.601 <-> YUV REC.709 conversions? That would
> > require separate encodings for input and output.
>
> How about if we pass the input and output encodings to the init ic task
> functions, but
Hi Steve,
On Mon, 2019-02-11 at 10:24 -0800, Steve Longerbeam wrote:
[...]
> Looking more closely at these coefficients now, I see you are right,
> they are the BT.601 YUV full-range coefficients (Y range 0 to 1, U and V
> range -0.5 to 0.5). Well, not even that -- the coefficients are not
>
On Fri, 2019-02-08 at 17:47 -0800, Steve Longerbeam wrote:
> Pass v4l2 encoding enum to the ipu_ic task init functions, and add
> support for the BT.709 encoding and inverse encoding matrices.
>
> Reported-by: Tim Harvey
> Signed-off-by: Steve Longerbeam
> ---
> Changes in v4:
> - fix compile
On Fri, 2019-02-08 at 17:47 -0800, Steve Longerbeam wrote:
> Simplify the selection of the Y'CbCr encoding matrices in init_csc().
> A side-effect of this change is that init_csc() now allows YUV->YUV
> using the identity matrix, intead of returning error.
>
> Signed-off-by: Steve Longerbeam
On Fri, 2019-02-08 at 17:47 -0800, Steve Longerbeam wrote:
> The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
> coefficients, so rename them to indicate that. And add some comments
> to make clear these are BT.601 coefficients encoding between YUV limited
> range and RGB
On Thu, 2019-02-07 at 14:10 +0100, Neil Armstrong wrote:
[...]
> The controller is the exact same as Meson8, GXBB, and AXG.
>
> We had doubts since the previous datasheets were not clear, but for G12A we
> are sure it's 100% same to at least GXBB and AXG, thus using the same
> compatible as AXG
On Fri, 2019-02-01 at 21:08 +0530, Manivannan Sadhasivam wrote:
> HI3670 SoC is architecturally same as the HI3660 SoC. Hence, add the
> HI3670 compatible to HI3660 reset driver in order to reuse it.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> drivers/reset/hisilicon/reset-hi3660.c | 1 +
>
Hi Manivannan,
On Fri, 2019-02-01 at 21:08 +0530, Manivannan Sadhasivam wrote:
> HI3670 SoC is architecturally same as the HI3660 SoC. Hence, the same
> driver is reused for HI3670 SoC and the binding is documented here.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
>
On Fri, 2019-02-01 at 21:08 +0530, Manivannan Sadhasivam wrote:
> Add reset controller support for HiSilicon HI3670 SoC.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm64/boot/dts/hisilicon/hi3670.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
Hi Jerome,
is there any public documentation for the G12A reset controller?
On Fri, 2019-02-01 at 13:50 +0100, Jerome Brunet wrote:
> Add device tree bindings for the reset controller of g12a SoC family.
>
> Acked-by: Neil Armstrong
> Signed-off-by: Jerome Brunet
> ---
>
> Changes since v2
On Wed, 2019-02-06 at 17:00 +0100, Thierry Reding wrote:
[...]
> > reset_control_get_exclusive() // implicitly acquires, may fail
> > reset_control_acquire() // optional, just makes acquire explicit (no-op)
> > reset_control_assert/deassert()
> > reset_control_release()
>
> I don't think we can
r reset
requests and then argue about whether to give other drivers veto power
or force them to store internal state and cease all operations.
> Hm... so I don't think the implicit acquire step during request would
> work because of the race conditions I mentioned above. The only other
> sol
On Tue, 2019-02-05 at 23:13 +0100, Thierry Reding wrote:
[...]
> > Drivers that never call _acquire()/_release() must continue to work as
> > they are, so exclusive reset controls have to be acquired by default.
>
> I don't think they have to. See below.
Currently the API makes guarantees about
Hi Thierry,
On Fri, 2019-02-01 at 15:00 +0100, Thierry Reding wrote:
[...]
> It sounds pretty good and elegant actually. Let me try to restate to see
> if I understand correctly:
>
> So basically what you're saying is that we would be changing the
> definition of exclusive resets to make them
On Thu, 2019-01-31 at 13:30 +0100, Hans Verkuil wrote:
> On 1/31/19 11:45 AM, Hans Verkuil wrote:
> > On 1/24/19 11:04 AM, Tomasz Figa wrote:
> > > Due to complexity of the video decoding process, the V4L2 drivers of
> > > stateful decoder hardware require specific sequences of V4L2 API calls
> >
Hi Nicolas,
On Wed, 2019-01-30 at 10:32 -0500, Nicolas Dufresne wrote:
> Le mercredi 30 janvier 2019 à 15:17 +0900, Tomasz Figa a écrit :
> > > I don't remember saying that, maybe I meant to say there might be a
> > > workaround ?
> > >
> > > For the fact, here we queue the headers (or first
Hi Thierry,
On Mon, 2019-01-28 at 15:58 +0100, Thierry Reding wrote:
> On Mon, Jan 28, 2019 at 12:26:48PM +0100, Philipp Zabel wrote:
> > Hi Thierry,
> >
> > On Fri, 2019-01-25 at 11:15 +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
On Sun, 2019-01-27 at 08:17 +, David Binderman wrote:
> Hello there,
>
> drivers/media/platform/imx-pxp.c:683:24: warning: duplicated ‘if’ condition
> [-Wd
> uplicated-cond]
>
> Source code is
>
>} else if (ycbcr_enc == V4L2_YCBCR_ENC_709) {
> if
Hi Thierry,
On Fri, 2019-01-25 at 11:15 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> When requesting a reset control for exclusive use that's already in use,
> an -EBUSY error code is returned. Users can react accordingly when they
> receive that error code, so there is no need to
Hi Andrey,
On Thu, 2019-01-24 at 16:21 -0800, Andrey Smirnov wrote:
> > Thank you, applied all three to reset/next with a small whitespace
> > alignment fix.
> >
>
> Thanks again for applying this stuff. If that's not too much to ask,
> would you mind creating an immutable branch, so I could
On Thu, 2019-01-24 at 10:49 +0100, Michal Simek wrote:
> On 24. 01. 19 10:43, Philipp Zabel wrote:
> > On Fri, 2019-01-25 at 13:16 +0530, Nava kishore Manne wrote:
> > > This Patch Adds reset API's to support release, assert
> > > and status functionalities
nelli
> Signed-off-by: Philipp Zabel
> ---
> Philipp,
>
> This is a replacement patch for what is currently in your reset/next
> branch.
>
> Thank you!
Applied to reset/next, thank you.
regards
Philipp
On Fri, 2019-01-25 at 13:16 +0530, Nava kishore Manne wrote:
> This Patch Adds reset API's to support release, assert
> and status functionalities by using firmware interface.
>
> Signed-off-by: Nava kishore Manne
Michal, Should I merge this through the reset tree together with the
reset
Hi Andrey,
On Wed, 2019-01-23 at 21:33 -0800, Andrey Smirnov wrote:
> On Wed, Jan 23, 2019 at 2:52 AM Philipp Zabel wrote:
> >
> > On Thu, 2019-01-17 at 14:38 -0800, Andrey Smirnov wrote:
> > [...]
> > > > To be honest, I don't like the
201 - 300 of 3512 matches
Mail list logo
