t; + status = "disabled";
> + };
> +
As Geert mentioned, you should add vin2 here.
> qspi: spi@e6b1 {
> compatible = "renesas,qspi-r8a7793", "renesas,qspi";
> reg = <0 0xe6b1 0 0x2c>;
--
Regards,
Laurent Pinchart
On Friday 30 Sep 2016 15:00:59 Geert Uytterhoeven wrote:
> On Fri, Sep 30, 2016 at 2:40 PM, Laurent Pinchart wrote:
> >> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> >> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> >> @@ -374,6 +374,11 @@
> >&
t don't deployed it.. if you don't
> mind can you please give me a feedback of my work..My source tree is v4.7.5
Could you please send your changes as an inline diff (which you can generate
with git diff) instead of as a source file attachment ? That will let us
reviewing it easily and replying inline.
--
Regards,
Laurent Pinchart
= <0>;
> +
> + vin0ep: endpoint {
> + remote-endpoint = <>;
> + bus-width = <24>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
ideo input */
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vin1ep: endpoint {
> + remote-endpoint = <>;
> + bus-width = <8>;
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
error log
> here
>
> I have the rootfs of ALT Board in /exports folder..
Quickly looking at the log I don't see anything that's really kernel-specific
there. I think you have reached a point where you need to start debugging by
yourself, we can't do all the work for you.
--
Regards,
Laurent Pinchart
PFC_PIN_NAMED_CFG(ROW_GROUP_A('T'), 30, AT30,
> > SH_PFC_PIN_CFG_DRIVE_STRENGTH),/* ASEBRK */
> > + SH_PFC_PIN_NAMED_CFG(ROW_GROUP_A('T'), 30, ASEBRK,
> > SH_PFC_PIN_CFG_DRIVE_STRENGTH), /* ASEBRK */
> >
> > That would keep the names and numbers consistent on both H3 varinats.
> > The names would correlate to function and the numbers simply serve as a
> > pin identifier which is unique and derived from the H3SiP pin layout,
> > probably a comment about this in the source is a good idea :-)
>
> So "the system" would be H3SiP pin numbers.
> Looks good to me.
>
> Laurent, do you agree?
I'm fine with that.
--
Regards,
Laurent Pinchart
ex: tty/drivers/tty/serial/sh-sci.c
> > ===
> > --- tty.orig/drivers/tty/serial/sh-sci.c
> > +++ tty/drivers/tty/serial/sh-sci.c
> > @@ -2950,6 +2950,9 @@ static const struct of_device_id of_sci_
> > }, {
> > .compatible = "renesas,rcar-gen3-scif",
> > .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> >
> > + }, {
> > + .compatible = "renesas,rzg-scif",
> > + .data = SCI_OF_DATA(PORT_SCIF, SCIx_SH4_SCIF_BRG_REGTYPE),
> > },
> > /* Generic types */
> > {
>
> However, I wouldn't bother adding RZ/G family-specific DT bindings, as
> RZ/G is a derivative of R-Car Gen2.
I agree, we need to stop the compat string proliferation madness.
--
Regards,
Laurent Pinchart
The SMP initialization function is only called if CONFIG_SMP is defined.
Remove the duplicate check.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
arch/arm/mach-shmobile/platsmp.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-sh
> +
> +#include
> +
> +#include
> +
> +#include "common.h"
> +#include "rcar-gen2.h"
> +
> +static const char * const r8a7743_boards_compat_dt[] __initconst = {
> + "renesas,r8a7743",
> + NULL,
> +};
> +
> +DT_MACHINE_START(R8A7743_DT, "Generic R8A7743 (Flattened Device Tree)")
> + .init_early = shmobile_init_delay,
> + .init_time = rcar_gen2_timer_init,
> + .init_late = shmobile_init_late,
> + .reserve= rcar_gen2_reserve,
> + .dt_compat = r8a7743_boards_compat_dt,
> +MACHINE_END
--
Regards,
Laurent Pinchart
The three SoCs use the exact same machine definition, consolidate them
into a single one.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
arch/arm/mach-shmobile/Makefile | 3 ---
arch/arm/mach-shmobile/setup-r8a7792.c
too if you want
> to throw that one on the pile
I'm totally fine adding compatible strings when it makes sense, what bothers
me is a pile of compat strings to describe IP cores that are identical :-)
--
Regards,
Laurent Pinchart
Hi Geert,
On Wednesday 05 Oct 2016 13:25:12 Geert Uytterhoeven wrote:
> On Wed, Oct 5, 2016 at 12:28 PM, Laurent Pinchart wrote:
> > The SMP initialization function is only called if CONFIG_SMP is defined.
> > Remove the duplicate check.
> >
> > Sign
On Wednesday 05 Oct 2016 12:03:24 Geert Uytterhoeven wrote:
> Hi Laurent,
>
> On Wed, Oct 5, 2016 at 11:55 AM, Laurent Pinchart
>
> <laurent.pinch...@ideasonboard.com> wrote:
> > On Friday 30 Sep 2016 10:38:48 Geert Uytterhoeven wrote:
> >> On Thu, Sep 29, 201
On Wednesday 05 Oct 2016 08:28:05 Rob Herring wrote:
> On Wed, Oct 5, 2016 at 4:55 AM, Laurent Pinchart
>
> <laurent.pinch...@ideasonboard.com> wrote:
> > On Friday 30 Sep 2016 10:38:48 Geert Uytterhoeven wrote:
> >> On Thu, Sep 29, 2016 at 11:37 PM, Sergei Shtyly
On Wednesday 05 Oct 2016 13:31:29 Laurent Pinchart wrote:
> The three SoCs use the exact same machine definition, consolidate them
> into a single one.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
> ---
> arch/arm/mach-shmobil
The node pointer passed to the display timing functions is never
modified, make it const.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/video/of_display_timing.c | 6 +++---
include/video/of_display_timing.h | 15 ---
2 files chang
The node passed as a pointer to the rcar_du_lvds_connector_init()
function is never modified, make it const.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 2 +-
2
not going through your tree,
could you please ack them ?
Cc: David Airlie <airl...@linux.ie>
Cc: Tomi Valkeinen <tomi.valkei...@ti.com>
Laurent Pinchart (6):
video: of: Constify node argument to display timing functions
drm: rcar-du: Constify node argument to rcar_du_lvds_connector_
The driver has lost platform data support a long time ago. R-Car DU
devices can only be instantiated through DT now, making it impossible to
have a NULL DT node pointer. Remove the error check.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/gpu/dr
Capitalize acronyms and use determiners and punctuation.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmien
Memory allocation failures print messages to the kernel log, there's no
need to print an extra one. Remove the duplicate message.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 4 +---
1 file changed, 1 insertion
context to the error, and make sure we still own a reference to
the encoder's DT node by delaying the of_node_put() call.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 10 +-
1 file changed, 5 insertions(+), 5 del
Please use the mainline kernel, it should support HDMI output.
--
Regards,
Laurent Pinchart
Hi Geert,
On Friday 07 Oct 2016 09:43:53 Geert Uytterhoeven wrote:
> On Wed, Oct 5, 2016 at 12:31 PM, Laurent Pinchart wrote:
> > The three SoCs use the exact same machine definition, consolidate them
> > into a single one.
>
> Thanks for your patch!
>
> > S
ARM: shmobile:
Consolidate R8A779[234] machine definitions".
--
Regards,
Laurent Pinchart
on the DT bindings.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 29 +
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 11 +--
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.
-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
.../bindings/display/panel/panel-lvds.txt | 119 +
1 file changed, 119 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/panel-lvds.txt
diff --git a/Documen
g them. The control signals positions correspond to DC-balanced LVDS
(see figure 18 on page 19 of http://www.ti.com/lit/ds/symlink/ds90cf388.pdf),
but the R-Car DU doesn't support DC-balanced LVDS as far as I can tell, so
it's not a match. If anyone knows of other devices supporting the
Add a new compatible string for the R8A7796 (M3-W) RAVB.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 ++-
1 file changed, 2 inse
The VYUY format isn't supported on Gen3 hardware, disable it.
Gen2 hardware supports VYUY in practice even though the documentation
doesn't advertise it, so keep it for Gen2 devices.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/media/platfor
Hi Mauro,
On Monday 19 Sep 2016 14:55:43 Mauro Carvalho Chehab wrote:
> Em Wed, 14 Sep 2016 02:16:59 +0300 Laurent Pinchart escreveu:
> > Cropping on the WPF sink pad restricts the left and top coordinates to
> > 0-255. The same result can be obtained by cropping on the RPF
Hi Mauro,
On Monday 19 Sep 2016 16:10:31 Mauro Carvalho Chehab wrote:
> Em Mon, 19 Sep 2016 21:35:36 +0300 Laurent Pinchart escreveu:
> > On Monday 19 Sep 2016 15:26:19 Mauro Carvalho Chehab wrote:
> >> Several multi-line comments added at the vsp1 patch series
> >> vio
Hi Mauro,
On Monday 19 Sep 2016 15:26:15 Mauro Carvalho Chehab wrote:
> Em Mon, 19 Sep 2016 20:59:56 +0300 Laurent Pinchart escreveu:
> > On Monday 19 Sep 2016 14:55:43 Mauro Carvalho Chehab wrote:
> >> Em Wed, 14 Sep 2016 02:16:59 +0300 Laurent Pinchart escreveu:
> >>
P1_ENTITY_WPF,
> };
>
> -/*
> +/**
Quoting another mail I've sent:
I don't think those comments should become part of the kernel documentation.
They're really about driver internals, and meant for the driver developers. In
particular only a subset of the driver is documented that way,
Hi Rubin,
On Friday 16 Sep 2016 11:36:29 Robin Murphy wrote:
> On 16/09/16 10:48, Laurent Pinchart wrote:
> > On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> >> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> >>> On Wed, Aug 10, 2016 at 11:0
Hi Robin,
On Friday 16 Sep 2016 13:49:21 Robin Murphy wrote:
> On 16/09/16 13:05, Laurent Pinchart wrote:
> [...]
>
> >>>> One concern I have is that we might get an awkward situation if we ever
> >>>> encounter one DMA engine hardware that is used in
Hi Arnd,
On Friday 16 Sep 2016 14:02:35 Arnd Bergmann wrote:
> On Friday, September 16, 2016 12:48:23 PM CEST Laurent Pinchart wrote:
> > On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> >> On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> >>>
Hi Arnd,
On Friday 16 Sep 2016 14:22:31 Arnd Bergmann wrote:
> On Friday, September 16, 2016 3:09:29 PM CEST Laurent Pinchart wrote:
> >> I wasn't thinking quite that far, though that is also a theoretical
> >> problem. However, the simple solution would be to have a bit in t
Hi Ricardo,
On Wednesday 07 Sep 2016 09:07:35 Ricardo Ribalda Delgado wrote:
> Hi Laurent
>
> Thank you very much!
You're welcome.
> On Wed, Sep 7, 2016 at 2:14 AM, Laurent Pinchart wrote:
> > Support both the HSV24 and HSV32 formats. From a hardware point of view
>
On Wednesday 17 Aug 2016 11:00:38 Geert Uytterhoeven wrote:
> On Wed, Aug 17, 2016 at 9:13 AM, Simon Horman <ho...@verge.net.au> wrote:
> > On Fri, Aug 12, 2016 at 12:18:55PM +0300, Laurent Pinchart wrote:
> >> Signed-off-by: Laurent Pinchart
> >> <laure
The vsp1 driver supports tri-planar formats, but the DRM API only passes
two memory addresses. Add a third one.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_drm.c | 6 +++---
include/media/vsp1.h | 2
error parsing input tree
> make[1]: *** [arch/arm/boot/dts/r8a7791-koelsch.dtb] Error 1
> make: *** [r8a7791-koelsch.dtb] Error 2
>
> here i am attaching my r8a7791.dts file
--
Regards,
Laurent Pinchart
s v4.7.5 stable edition
>
> No one has added LVDS support for r8a7794/alt yet.
The R8A7794 has no LVDS output. The Alt board uses an RGB to LVDS bridge,
similar to the one used by the Marzen board. You can have a look at the Marzen
DT to see how to implement that.
--
Regards,
Laurent Pinchart
Hi Niklas,
On Saturday 01 Oct 2016 11:19:31 Niklas Söderlund wrote:
> On 2016-09-30 16:32:52 +0300, Laurent Pinchart wrote:
> > On Friday 30 Sep 2016 15:00:59 Geert Uytterhoeven wrote:
> >> On Fri, Sep 30, 2016 at 2:40 PM, Laurent Pinchart wrote:
> >>>> --- a/a
t; +
> + vin0ep: endpoint {
> + remote-endpoint = <>;
> + bus-width = <24>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + pclk-sample = <1>;
> + data-active = <1>;
> + };
> + };
> +};
> +
> /* composite video input */
> {
> status = "okay";
--
Regards,
Laurent Pinchart
Hello Jithin,
Could you please reply to e-mails instead of sending unrelated new e-mails, in
order to keep all mails related to the subject grouped in a single thread ?
--
Regards,
Laurent Pinchart
net.au> wrote:
> >>> On Tue, Oct 18, 2016 at 12:19:26PM +0300, Laurent Pinchart wrote:
> >>>> On Tuesday 18 Oct 2016 11:05:32 Geert Uytterhoeven wrote:
> >>>>> On Mon, Oct 17, 2016 at 11:34 PM, Laurent Pinchart wrote:
> >>>>>>
mments about the other patches (sorry for the late
review, I got delayed by KS and LPC), the follow-up patch should probably be
squashed into this one when Magnus addresses my comments. Could you please
hold off pushing the arm/renesas branch until Magnus replies to this ?
--
Regards,
Laurent Pinchart
Hello Truong,
On Friday 21 Oct 2016 14:20:24 Laurent Pinchart wrote:
> On Friday 21 Oct 2016 19:53:47 Xuan Truong Nguyen wrote:
> > Hello Laurent.
> >
> > > The document mentions that you have used shmobile_defconfig. However,
> > > that configuration in v4.8
mu_detach_device,
.map = ipmmu_map,
--
Regards,
Laurent Pinchart
pping;
> >
> > @@ -783,7 +800,7 @@ error:
> > if (mmu)
> >
> > arm_iommu_release_mapping(mmu->mapping);
> >
> > - dev->archdata.iommu = NULL;
> > + set_archdata(dev, NULL);
> >
> > if (!IS_ERR_OR_NULL(group))
> >
> > iommu_group_remove_device(dev);
> >
> > @@ -793,7 +810,7 @@ error:
> > static void ipmmu_remove_device(struct device *dev)
> > {
> >
> > - struct ipmmu_vmsa_archdata *archdata = dev->archdata.iommu;
> > + struct ipmmu_vmsa_archdata *archdata = to_archdata(dev);
> >
> > arm_iommu_detach_device(dev);
> > iommu_group_remove_device(dev);
> >
> > @@ -801,7 +818,7 @@ static void ipmmu_remove_device(struct d
> >
> > kfree(archdata->utlbs);
> > kfree(archdata);
> >
> > - dev->archdata.iommu = NULL;
> > + set_archdata(dev, NULL);
> >
> > }
> >
> > static struct iommu_domain *ipmmu_domain_alloc(unsigned type)
--
Regards,
Laurent Pinchart
ain *io_domain;
> - struct ipmmu_vmsa_domain *domain;
> + irqreturn_t status = IRQ_NONE;
> + unsigned int i;
> + unsigned long flags;
Nitpicking again I like to arrange variable declarations by decreasing line
length when there's no reason not to :-)
> - if (!
,10 +778,8 @@ static int ipmmu_add_device(struct devic
> return 0;
>
> error:
> - arm_iommu_release_mapping(mmu->mapping);
> -
> - kfree(dev->archdata.iommu);
> - kfree(utlbs);
> + if (mmu)
> + arm_iommu_release_mapping(mmu->mapping);
Looking at the surrounding code, shouldn't the mapping only be destroyed here
if it has been created by the same call to the function ? If there's an
existing mapping for the IPMMU instance and the arm_iommu_attach_device() call
fails, releasing the mapping seems to be a bug. As the bug isn't introduced by
this patch, we can fix it separately, but if you end up resubmitting due to
the first comment you could also add a fix.
>
> dev->archdata.iommu = NULL;
--
Regards,
Laurent Pinchart
nmap,
> + .map_sg = default_iommu_map_sg,
> + .iova_to_phys = ipmmu_iova_to_phys,
> + .add_device = ipmmu_add_device_dma,
> + .remove_device = ipmmu_remove_device_dma,
> + .device_group = ipmmu_device_group_dma,
> + .pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K,
> + .of_xlate = ipmmu_of_xlate_dma,
The ARM implementation should switch to .of_xlate() too. Have you given it a
try by any chance ?
> +};
> +
> +#endif /* CONFIG_IOMMU_DMA */
> +
> /*
> * Probe/remove and init
> */
> @@ -910,7 +1014,9 @@ static int ipmmu_remove(struct platform_
> list_del(>list);
> spin_unlock(_devices_lock);
>
> +#if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
> arm_iommu_release_mapping(mmu->mapping);
> +#endif
>
> ipmmu_device_reset(mmu);
--
Regards,
Laurent Pinchart
: Magnus Damm <damm+rene...@opensource.se>
> Reviewed-by: Joerg Roedel <jroe...@suse.de>
This looks good to me,
Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
(assuming my review of the next patches in the series won't make me conclude
that this patch is
is that it is based of
> floating point calculus. On integer mathematics you should replace
> fractional part with fractional modulus (usually letter "K" is used for
> fractional modulus on PLL calc).
>
> So that ends up something like:
> 1) select suitable lo output divider from desired output frequency
> 2) calculate vco frequency
> 3) convert vco frequency to N and K
> * N = Fvco/Fref
> * K = Fvco%Fref
> 4) convert K to control word (looks like << 20)
> 5) program values
>
> Result should be calculus without scaling.
Thanks for reviewing this part.
I'd like to add that we already have two PLL helpers in the media subsystem,
in drivers/media/i2c/aptina-pll.c and drivers/media/i2c/smiapp-pll.c. As the
PLL used here seems to be a classic one, it would make sense to also extract
the code in a helper function that could be shared between drivers.
--
Regards,
Laurent Pinchart
> '1', '4') /* complex s14le */ #define V4L2_SDR_FMT_RU12LE
> > v4l2_fourcc('R', 'U', '1', '2') /* real u12le */>
> > +#define V4L2_SDR_FMT_SCU16BE v4l2_fourcc('S', 'C', '1', '6') /*
sliced
> > complex u16be */ +#define V4L2_SDR_FMT_SCU18BEv4l2_fourcc('S',
'C',
> > '1', '8') /* sliced complex u18be */ +#define V4L2_SDR_FMT_SCU20BE
> > v4l2_fourcc('S', 'C', '2', '0') /* sliced complex u20be */>
> > /* Touch formats - used for Touch devices */
> > #define V4L2_TCH_FMT_DELTA_TD16v4l2_fourcc('T', 'D', '1', '6') /* 16-
bit
> > signed deltas */
--
Regards,
Laurent Pinchart
/ #define V4L2_SDR_FMT_RU12LE
> > v4l2_fourcc('R', 'U', '1', '2') /* real u12le */>
> > +#define V4L2_SDR_FMT_SCU16BE v4l2_fourcc('S', 'C', '1', '6') /*
sliced
> > complex u16be */ +#define V4L2_SDR_FMT_SCU18BEv4l2_fourcc('S',
'C',
> > '1', '8') /* sliced complex u18be */ +#define V4L2_SDR_FMT_SCU20BE
> > v4l2_fourcc('S', 'C', '2', '0') /* sliced complex u20be */>
> > /* Touch formats - used for Touch devices */
> > #define V4L2_TCH_FMT_DELTA_TD16v4l2_fourcc('T', 'D', '1', '6') /* 16-
bit
> > signed deltas */
--
Regards,
Laurent Pinchart
hist[hue_pos/2][hist_n] += 16 - weight;
> + }
> }
> }
>
> @@ -1349,9 +1409,9 @@ static void histogram_compute_hgt(const struct image
> *image, void *histo, histo += 4;
>
> /* Weighted Frequency of Hue Area-m and Saturation Area-n */
> - for (m = 0; m < 6; m++) {
> - for (n = 0; n < 32; n++) {
> - *(uint32_t *)histo = hist[m][n];
> + for (x = 0; x < 6; x++) {
> + for (y = 0; y < 32; y++) {
> + *(uint32_t *)histo = hist[x][y];
> histo += 4;
> }
> }
--
Regards,
Laurent Pinchart
Hi Hans,
On Friday 11 Nov 2016 14:53:58 Hans Verkuil wrote:
> On 11/10/2016 09:08 AM, Laurent Pinchart wrote:
> > Antti, Hans, ping ? Please see below.
> >
> > On Friday 04 Nov 2016 09:23:29 Ramesh Shanmugasundaram wrote:
> >>> On 11/02/2016 10:58 PM, Laurent Pi
n, option 2 seems better to me. However, it
somehow abuses the DT parent-child model that is supposed to describe
relationships from a control bus point of view. Option 3 has the drawback of
not scaling properly, at least with phandles in both channels pointing to the
other one.
Rob, Geert, tell me you have a fourth idea I haven't thought of that would
solve all those problems :-)
> +Board specific dts file
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> + renesas,syncac-pol-high;
> + status = "okay";
> + port {
> + drif0_ep: endpoint {
> + remote-endpoint = <_subdev_ep>;
> + };
> + };
> +};
[snip]
--
Regards,
Laurent Pinchart
Antti, Hans, ping ? Please see below.
On Friday 04 Nov 2016 09:23:29 Ramesh Shanmugasundaram wrote:
> > On 11/02/2016 10:58 PM, Laurent Pinchart wrote:
> >> On Wednesday 02 Nov 2016 09:00:00 Ramesh Shanmugasundaram wrote:
> >>>>> On Wednesday 12 Oct 2016 15:10
the meantime, you can remove all the blank lines between table rows :-)
> + - Byte B0
> +
> + - Byte B1
> +
> + - Byte B2
> +
> + - Byte B3
[snip]
--
Regards,
Laurent Pinchart
_bits(ctx, 4, 7, 0, (u8)(frac_desired & 0xff));
> >> + /* Flush the above registers to device */
> >> + max2175_flush_regstore(ctx, 1, 6);
> >> + return ret;
> >> +}
[snip]
> >> +static int max2175_get_lna_gain(struct max2175_ctx *ctx) {
> >> + int gain = 0;
> >> + enum max2175_band band = max2175_get_bits(ctx, 5, 1, 0);
> >> +
> >> + switch (band) {
> >> + case MAX2175_BAND_AM:
> >> + gain = max2175_read_bits(ctx, 51, 3, 1);
> >> + break;
> >> + case MAX2175_BAND_FM:
> >> + gain = max2175_read_bits(ctx, 50, 3, 1);
> >> + break;
> >> + case MAX2175_BAND_VHF:
> >> + gain = max2175_read_bits(ctx, 52, 3, 0);
> >> + break;
> >> + default:
> >> + v4l2_err(ctx->client, "invalid band %d to get rf gain\n",
> >> band);
> >
> > Can this happen ?
>
> Yes, there is "L-band". It is a paranoia check as I am testing by comparing
> logs sometimes :-(
OK. By the way, you could get rid of the gain variable by returning directly
in the case statements.
> >> + break;
> >> + }
> >> + return gain;
> >> +}
[snip]
> >> +static const struct v4l2_ctrl_config max2175_i2s_mode = {
> >> + .ops = _ctrl_ops,
> >> + .id = V4L2_CID_MAX2175_I2S_MODE,
> >> + .name = "I2S_MODE value",
> >> + .type = V4L2_CTRL_TYPE_INTEGER,
> >
> > Should this be a menu control ?
>
> Hmm... the strings would be named "i2s mode x"? Will that be OK?
How about describing the modes instead ? Are they standardized ?
> >> + .min = 0,
> >> + .max = 4,
> >> + .step = 1,
> >> + .def = 0,
> >> +};
[snip]
--
Regards,
Laurent Pinchart
Hi Simon,
On Tuesday 18 Oct 2016 11:05:32 Geert Uytterhoeven wrote:
> On Mon, Oct 17, 2016 at 11:34 PM, Laurent Pinchart wrote:
> > Add the DU device to r8a7796.dtsi in a disabled state.
> >
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+rene...@i
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
Changes since v1:
- Updated the DU* parent clocks to S2D1
---
drivers/clk/renesas/r8a7796-cpg-mssr.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c
b/drive
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/clk/renesas/r8a7796-cpg-mssr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c
b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index 41a3677a4b3a..679054658f99
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/clk/renesas/r8a7796-cpg-mssr.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c
b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index eb347ed265f2..41a367
Hello,
This patch series adds all the r8a7796 FCP, VSP and DU clocks. This includes
not only all the clocks required for display, but also the FCPC, FCPF, VSPB
and VSPI0 clocks to cover all the FCP and VSP instances.
The FCPC parent clocks haven't been confirmed yet.
Laurent Pinchart (3):
clk
1 << rcdu->info->num_crtcs) - 1);
+ if (ret < 0)
+ return ret;
+
/* Initialize the groups. */
num_groups = DIV_ROUND_UP(rcdu->num_crtcs, 2);
--
Regards,
Laurent Pinchart
return ret;
+
/* Initialize the groups. */
num_groups = DIV_ROUND_UP(rcdu->num_crtcs, 2);
--
Regards,
Laurent Pinchart
ntical to the
+* ->encoder.encoder_type for the last bridge in the chain only.
+*/
+ int encoder_type;
const struct drm_bridge_funcs *funcs;
void *driver_private;
};
--
Regards,
Laurent Pinchart
Hi Simon,
On Thursday 20 Oct 2016 10:42:30 Simon Horman wrote:
> Hi Laurent,
>
> On Wed, Oct 19, 2016 at 01:23:02AM +0300, Laurent Pinchart wrote:
> > The system uses one address cell and one size cell, not two. Fix the DU
> > DT node.
>
> Do you want to handle th
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
drivers/clk/renesas/r8a7796-cpg-mssr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c
b/drivers
FCPF and FCPV instances" scheduled for merge in v4.10.
Kieran Bingham (2):
dt-bindings: Add Renesas R-Car FDP1 bindings
v4l: Add Renesas R-Car FDP1 Driver
Laurent Pinchart (2):
v4l: ctrls: Add deinterlacing mode control
arm64: dts: renesas: r8a7796: Add FDP1 instance
.../devicetre
Hi Hans,
On Friday 21 Oct 2016 16:34:50 Hans Verkuil wrote:
> On 09/08/16 00:25, Laurent Pinchart wrote:
> > The menu control selects the operation mode of a video deinterlacer. The
> > menu entries are driver specific.
> >
> > Signed-off-by: Laurent Pinchart
From: Kieran Bingham <kieran+rene...@bingham.xyz>
The FDP1 is a de-interlacing module which converts interlaced video to
progressive video. It is also capable of performing pixel format conversion
between YCbCr/YUV formats and RGB formats.
Reviewed-by: Laurent Pinchart <laur
The r8a7796 has a single FDP1 instance.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/r
The menu control selects the operation mode of a video deinterlacer. The
menu entries are driver specific.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
Reviewed-by: Kieran Bingham <kie...@bingham.xyz>
Acked-by: Hans Verkuil <hans.verk...@cisco.com>
cp_device *fcp) { }
static inline int rcar_fcp_enable(struct rcar_fcp_device *fcp)
{
- return -ENOSYS;
+ return 0;
}
static inline void rcar_fcp_disable(struct rcar_fcp_device *fcp) { }
#endif
--
Regards,
Laurent Pinchart
compatible = "adi,adv7511w";
> reg = <0x39>;
> @@ -622,3 +640,21 @@
> };
> };
> };
> +
> +/* composite video input */
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vin1ep: endpoint {
> + remote-endpoint = <>;
> + bus-width = <8>;
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
compatible = "adi,adv7511w";
> reg = <0x39>;
> @@ -622,3 +640,21 @@
> };
> };
> };
> +
> +/* composite video input */
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vin1ep: endpoint {
> + remote-endpoint = <>;
> + bus-width = <8>;
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
Hi Tomi and Dave,
On Tuesday 04 Oct 2016 15:31:33 Laurent Pinchart wrote:
> Hello,
>
> This patch series contains five simple cleanups and fixes for the
> rcar-du-drm driver, as well as an argument constification patch for
> video/of.
>
> The patches themselves are
Hello,
On Tuesday 18 Oct 2016 17:13:32 Laurent Pinchart wrote:
[snip]
> Issue 14 ("USB-CAM: Warning message appears if remove the usb-camera cable
> under using") is likely not a Renesas-specific problem, but as I'm the
> maintainer of the uvcvideo webcam driver you us
Hi Ulrich,
Thank you for the patch.
On Tuesday 18 Oct 2016 17:02:21 Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht <ulrich.hecht+rene...@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> ---
> arch/arm/boot/dts/r8a7793.dtsi | 27 +++
hdmi_con_in: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +
> hdmi-out {
> compatible = "hdmi-connector";
> type = "a";
For consistency you might want to rename the hdmi-out endpoint like y
Hi Ulrich,
Thank you for the patches.
For the whole series,
Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
On Tuesday 18 Oct 2016 17:01:32 Ulrich Hecht wrote:
> Hi!
>
> This series enables HDMI input on the Lager and Koelsch boards.
> It sits on renesas-
Hi Greg,
On Tuesday 18 Oct 2016 16:05:21 Greg KH wrote:
> On Tue, Oct 18, 2016 at 04:24:20PM +0300, Laurent Pinchart wrote:
> > commit fd44aa9a254b18176ec3792a18e7de6977030ca8 upstream.
> >
> > The rcar_fcp_enable() function immediately returns successfully when the
&
I'\ :sub:`0[D3:D0]`
> +
> +- .. row 2
> +
> + - start + buffer_size/2:
> +
> + - Q'\ :sub:`0[D19:D12]`
> +
> + - Q'\ :sub:`0[D11:D4]`
> +
> + - Q'\ :sub:`0[D3:D0]`
> diff --git a/Documentation/media/uapi/v4l/sdr-formats.rst
> b/Documentation/media/uapi/v4l/sdr-formats.rst index f863c08..4c01cf9
> 100644
> --- a/Documentation/media/uapi/v4l/sdr-formats.rst
> +++ b/Documentation/media/uapi/v4l/sdr-formats.rst
> @@ -17,3 +17,6 @@ These formats are used for :ref:`SDR ` interface
> only. pixfmt-sdr-cs08
> pixfmt-sdr-cs14le
> pixfmt-sdr-ru12le
> +pixfmt-sdr-scu16be
> +pixfmt-sdr-scu18be
> +pixfmt-sdr-scu20be
--
Regards,
Laurent Pinchart
gt; <ramesh.shanmugasunda...@bp.renesas.com>"); diff --git
> a/drivers/media/i2c/max2175/max2175.h b/drivers/media/i2c/max2175/max2175.h
> new file mode 100644
> index 000..61a508b
> --- /dev/null
> +++ b/drivers/media/i2c/max2175/max2175.h
> @@ -0,0 +1,124 @@
> +/*
> + * Maxim Integrated MAX2175 RF to Bits tuner driver
> + *
> + * This driver & most of the hard coded values are based on the reference
> + * application delivered by Maxim for this chip.
> + *
> + * Copyright (C) 2016 Maxim Integrated Products
> + * Copyright (C) 2016 Renesas Electronics Corporation
> + *
> + * 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.
> + */
> +
> +#ifndef __MAX2175_H__
> +#define __MAX2175_H__
> +
> +#include
> +
> +enum max2175_region {
> + MAX2175_REGION_EU = 0, /* Europe */
> + MAX2175_REGION_NA, /* North America */
> +};
> +
> +#define MAX2175_EU_XTAL_FREQ (36864000) /* In Hz */
> +#define MAX2175_NA_XTAL_FREQ (40186125) /* In Hz */
> +
> +enum max2175_band {
> + MAX2175_BAND_AM = 0,
> + MAX2175_BAND_FM,
> + MAX2175_BAND_VHF,
> + MAX2175_BAND_L,
> +};
> +
> +/* NOTE: Any addition/deletion in the below enum should be reflected in
> + * V4L2_CID_MAX2175_RX_MODE ctrl strings
> + */
> +enum max2175_modetag {
> + /* EU modes */
> + MAX2175_DAB_1_2 = 0,
> +
> + /* Other possible modes to add in future
> + * MAX2175_DAB_1_0,
> + * MAX2175_DAB_1_3,
> + * MAX2175_EU_FM_2_2,
> + * MAX2175_EU_FM_1_0,
> + * MAX2175_EU_FMHD_4_0,
> + * MAX2175_EU_AM_1_0,
> + * MAX2175_EU_AM_2_2,
> + */
> +
> + /* NA modes */
> + MAX2175_NA_FM_1_0 = 0,
> +
> + /* Other possible modes to add in future
> + * MAX2175_NA_FM_1_2,
> + * MAX2175_NA_FMHD_1_0,
> + * MAX2175_NA_FMHD_1_2,
> + * MAX2175_NA_AM_1_0,
> + * MAX2175_NA_AM_1_2,
> + */
> +};
> +
> +/* Supported I2S modes */
> +enum {
> + MAX2175_I2S_MODE0 = 0,
> + MAX2175_I2S_MODE1,
> + MAX2175_I2S_MODE2,
> + MAX2175_I2S_MODE3,
> + MAX2175_I2S_MODE4,
> +};
> +
> +/* Coefficient table groups */
> +enum {
> + MAX2175_CH_MSEL = 0,
> + MAX2175_EQ_MSEL,
> + MAX2175_AA_MSEL,
> +};
> +
> +/* HSLS LO injection polarity */
> +enum {
> + MAX2175_LO_BELOW_DESIRED = 0,
> + MAX2175_LO_ABOVE_DESIRED,
> +};
> +
> +/* Channel FSM modes */
> +enum max2175_csm_mode {
> + MAX2175_CSM_MODE_LOAD_TO_BUFFER = 0,
> + MAX2175_CSM_MODE_PRESET_TUNE,
> + MAX2175_CSM_MODE_SEARCH,
> + MAX2175_CSM_MODE_AF_UPDATE,
> + MAX2175_CSM_MODE_JUMP_FAST_TUNE,
> + MAX2175_CSM_MODE_CHECK,
> + MAX2175_CSM_MODE_LOAD_AND_SWAP,
> + MAX2175_CSM_MODE_END,
> + MAX2175_CSM_MODE_BUFFER_PLUS_PRESET_TUNE,
> + MAX2175_CSM_MODE_BUFFER_PLUS_SEARCH,
> + MAX2175_CSM_MODE_BUFFER_PLUS_AF_UPDATE,
> + MAX2175_CSM_MODE_BUFFER_PLUS_JUMP_FAST_TUNE,
> + MAX2175_CSM_MODE_BUFFER_PLUS_CHECK,
> + MAX2175_CSM_MODE_BUFFER_PLUS_LOAD_AND_SWAP,
> + MAX2175_CSM_MODE_NO_ACTION
> +};
> +
> +/* Rx mode */
> +struct max2175_rxmode {
> + enum max2175_band band; /* Associated band */
> + u32 freq; /* Default freq in Hz */
> + u8 i2s_word_size; /* Bit value */
> + u8 i2s_modes[4];/* Supported modes */
> +};
> +
> +/* Register map */
> +struct max2175_regmap {
> + u8 idx; /* Register index */
> + u8 val; /* Register value */
> +};
As no other file than max2175.c includes this, I would move at least the
structure definitions to the .c file.
> +#endif /* __MAX2175_H__ */
--
Regards,
Laurent Pinchart
eran+rene...@bingham.xyz>
Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Acked-by: Rob Herring <r...@kernel.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
Changes since v4:
- Rewrote the power-domains property documentation
- A
DU0 uses an externally provided clock, but the corresponding pin isn't
correctly muxed. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
arch/arm/boot/dts/r8a7779-marzen.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Along with the DU r
Initialize the new drm_bridge::encoder_type field to the right value for
all bridges that model on-SoC IP cores.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 ++
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 ++
d
inally migrate the rcar-du-drm driver to the DRM bridge
API, removing the custom VGA DAC implementation in patch 7/8 and the table of
bridge compatible strings used to find the encoder type in patch 8/8.
Cc: devicet...@vger.kernel.org
Laurent Pinchart (8):
drm: bridge: Add LVDS encoder driver
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/gpu/drm/rcar-du/Kconfig | 6 --
drivers/gpu/drm/rcar-du/Makefile | 5 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 52
drivers/gpu/drm/rcar-du/rcar_du_encoder.h
Set the type of the DRM encoder that models the hardware encoders
(bridges) chain based on the type of the last bridge in the chain
instead of hardcoding encoder compatible strings in the display driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drive
g backward compatibility.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
drivers/gpu/drm/bridge/lvds-encoder.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 33e8025c8a
Only the VGA output is supported for now.
Signed-off-by: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
---
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 48 ++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-sa
tor-x.dts | 48
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 131 +
2 files changed, 179 insertions(+)
--
Regards,
Laurent Pinchart
501 - 600 of 2024 matches
Mail list logo
