Re: [PATCH] pinctrl: rza1: report if devm_kasptrinf() fails
Hi Nicholas, Linus,
I'm sorry I might have missed this
On Sat, Nov 24, 2018 at 05:30:33PM +0100, Nicholas Mc Guire wrote:
> devm_kasprintf() may return NULL on failure of internal allocation
> thus the assignments are not safe if not checked. On error
> rza1_pinctrl_register() respectively rza1_parse_gpiochip() return
> negative values so -ENOMEM in the (unlikely) failure case of
> devm_kasprintf() should be fine here.
devm_kasprintf() returns -ENOMEM in case of failure (which I agree it's
unlikely, but still...), so I guess it's fine returning -ENOMEM as well
here.
Acked-by: Jacopo Mondi
Thanks
j
>
> Signed-off-by: Nicholas Mc Guire
> Fixes: 5a49b644b307 ("pinctrl: Renesas RZ/A1 pin and gpio controller")
> ---
>
> Problem was located with an experimental coccinelle script
>
> The dev_err() for this unlikely case is added so that a failures of
> rza1_pinctrl_register() respectively rza1_parse_gpiochip() can be
> understood as currently the negative return value is simply passed up
> the call stack but it would be hard to identify the cause.
>
> Patch was compile tested with: shmobile_defconfig (implies PINCTRL_RZA1=y)
>
> Patch is against 4.20-rc3 (localversion-next is next-20181123)
>
> drivers/pinctrl/pinctrl-rza1.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/pinctrl/pinctrl-rza1.c b/drivers/pinctrl/pinctrl-rza1.c
> index 14eb576..2533df4 100644
> --- a/drivers/pinctrl/pinctrl-rza1.c
> +++ b/drivers/pinctrl/pinctrl-rza1.c
> @@ -1225,6 +1225,11 @@ static int rza1_parse_gpiochip(struct rza1_pinctrl
> *rza1_pctl,
> chip->base = -1;
> chip->label = devm_kasprintf(rza1_pctl->dev, GFP_KERNEL, "%pOFn",
>np);
> + if (!chip->label) {
> + dev_err(rza1_pctl->dev, "Failed to allocate label\n");
> + return -ENOMEM;
> + }
> +
> chip->ngpio = of_args.args[2];
> chip->of_node = np;
> chip->parent= rza1_pctl->dev;
> @@ -1326,6 +1331,11 @@ static int rza1_pinctrl_register(struct rza1_pinctrl
> *rza1_pctl)
> pins[i].number = i;
> pins[i].name = devm_kasprintf(rza1_pctl->dev, GFP_KERNEL,
> "P%u-%u", port, pin);
> + if (!pins[i].name) {
> + dev_err(rza1_pctl->dev,
> + "RZ/A1 pin controller allocation failed\n");
> + return -ENOMEM;
> + }
>
> if (i % RZA1_PINS_PER_PORT == 0) {
> /*
> --
> 2.1.4
>
signature.asc
Description: PGP signature
Re: [PATCH v6 06/17] media: v4l2-fwnode: Add a convenience function for registering subdevs with notifiers
Hi Sakari,
On Thu, Sep 13, 2018 at 03:44:25PM +0300, Sakari Ailus wrote:
> Hi Jacopo,
>
> On Thu, Sep 13, 2018 at 12:37:27PM +0200, jacopo mondi wrote:
> > Hi Steve,
> >
> > On Mon, Jul 09, 2018 at 03:39:06PM -0700, Steve Longerbeam wrote:
> > > Adds v4l2_async_register_fwnode_subdev(), which is a convenience function
> > > for parsing a sub-device's fwnode port endpoints for connected remote
> > > sub-devices, registering a sub-device notifier, and then registering
> > > the sub-device itself.
> > >
> > > Signed-off-by: Steve Longerbeam
> > > ---
> > > Changes since v5:
> > > - add call to v4l2_async_notifier_init().
> > > Changes since v4:
> > > - none
> > > Changes since v3:
> > > - remove support for port sub-devices, such sub-devices will have to
> > > role their own.
> > > Changes since v2:
> > > - fix error-out path in v4l2_async_register_fwnode_subdev() that forgot
> > > to put device.
> > > Changes since v1:
> > > - add #include to v4l2-fwnode.h for
> > > 'struct v4l2_subdev' declaration.
> > > ---
> > > drivers/media/v4l2-core/v4l2-fwnode.c | 64
> > > +++
> > > include/media/v4l2-fwnode.h | 38 +
> > > 2 files changed, 102 insertions(+)
> > >
> > > diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c
> > > b/drivers/media/v4l2-core/v4l2-fwnode.c
> > > index 67ad333..94d867a 100644
> > > --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> > > +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> > > @@ -872,6 +872,70 @@ int v4l2_async_register_subdev_sensor_common(struct
> > > v4l2_subdev *sd)
> > > }
> > > EXPORT_SYMBOL_GPL(v4l2_async_register_subdev_sensor_common);
> > >
> > > +int v4l2_async_register_fwnode_subdev(
> >
> > The meat of this function is to register a subdev with a notifier,
> > so I would make it clear in the function name which is otherwise
> > misleading
> >
> > > + struct v4l2_subdev *sd, size_t asd_struct_size,
> > > + unsigned int *ports, unsigned int num_ports,
> > > + int (*parse_endpoint)(struct device *dev,
> > > + struct v4l2_fwnode_endpoint *vep,
> > > + struct v4l2_async_subdev *asd))
> > > +{
> > > + struct v4l2_async_notifier *notifier;
> > > + struct device *dev = sd->dev;
> > > + struct fwnode_handle *fwnode;
> > > + int ret;
> > > +
> > > + if (WARN_ON(!dev))
> > > + return -ENODEV;
> > > +
> > > + fwnode = dev_fwnode(dev);
> > > + if (!fwnode_device_is_available(fwnode))
> > > + return -ENODEV;
> > > +
> > > + notifier = kzalloc(sizeof(*notifier), GFP_KERNEL);
> > > + if (!notifier)
> > > + return -ENOMEM;
> > > +
> > > + v4l2_async_notifier_init(notifier);
> > > +
> > > + if (!ports) {
> > > + ret = v4l2_async_notifier_parse_fwnode_endpoints(
> > > + dev, notifier, asd_struct_size, parse_endpoint);
> > > + if (ret < 0)
> > > + goto out_cleanup;
> > > + } else {
> > > + unsigned int i;
> > > +
> > > + for (i = 0; i < num_ports; i++) {
> >
> > It's not particularly exciting to iterate on pointers received from
> > callers without checking for num_ports first.
>
> The loop is not executed if num_ports is zero, so I don't see a problem
> with that.
>
I know this is internal drivers API and failures are meant to be
catched early in development, but what if the actual number of ports
identifiers is < then the num_ports parameter?
> >
> > Also the caller has to allocate an array of "ports" and keep track of it
> > just to pass it to this function and I don't see a way to set the
> > notifier's ops before the notifier gets registered here below.
>
> True; this can be seen as an omission but quite a few drivers have no need
> for this either. It could be added later on --- I think it'd make perfect
> sense.
>
In a 'notifier configuration' structure that gather these and existing
function parameters together as you suggested...
> >
> > > + ret =
> > > v4l2_async_notifier_parse_fwnode_endpoints_by_port(
> > > + dev, notifier, asd_struct_size,
> > > + ports[i], parse_endpoint);
> > > +
Re: [PATCH v3 2/3] pinctrl: renesas: Renesas RZ/N1 pinctrl driver
Hi Phil,
On Tue, Sep 18, 2018 at 11:55:16AM +, Phil Edworthy wrote:
> Hi Jacopo,
>
[snip]
> > > +
> > > +/*
> > > + * Structure detailing the HW registers on the RZ/N1 devices.
> > > + * Both the Level 1 mux registers and Level 2 mux registers have the
> > > +same
> > > + * structure. The only difference is that Level 2 has additional MDIO
> > > +registers
> > > + * at the end.
> > > + */
> > > +struct rzn1_pinctrl_regs {
> > > + union {
> > > + u32 conf[170];
> > > + u8 pad0[0x400];
> >
> > Is pad0 actually used?
> No, it's just to implement the padding. Would you prefer not using a union
> here?
Oh, I did the math wrong, to me it was (32*170 > 8*400) but it's
actually (32*170 < 8*1024).
Also using a struct to define the memory region layout confused me and
I was about to ask "WHY ARE YOU RESERVING MEMORY HERE???" but this
type is just used for pointers, and it makes accessing HW locations
nicer actually (thanks Geert for having saved me a silly comment on this).
Cheers
j
signature.asc
Description: PGP signature
Re: [PATCH] media: tw9910: Whitespace alignment
Hi Joe,
On Thu, Mar 01, 2018 at 03:50:22AM -0800, Joe Perches wrote:
> Update multiline statements to open parenthesis.
> Update a ?: to a single line.
Thanks for the cleanup.
You may want to rebase this on my series from a few days ago
https://patchwork.linuxtv.org/patch/47475/
which includes some of the changes you made here and in patch
[PATCH] media: tw9910: Miscellaneous neatening
or the other way around and I should rebase mine on these two patches.
Thanks
j
>
> Signed-off-by: Joe Perches
> ---
> drivers/media/i2c/tw9910.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
> index cc5d383fc6b8..ab32cd81ebd0 100644
> --- a/drivers/media/i2c/tw9910.c
> +++ b/drivers/media/i2c/tw9910.c
> @@ -445,7 +445,7 @@ static const struct tw9910_scale_ctrl
> *tw9910_select_norm(v4l2_std_id norm,
>
> for (i = 0; i < size; i++) {
> tmp = abs(width - scale[i].width) +
> - abs(height - scale[i].height);
> + abs(height - scale[i].height);
> if (tmp < diff) {
> diff = tmp;
> ret = scale + i;
> @@ -534,9 +534,9 @@ static int tw9910_s_std(struct v4l2_subdev *sd,
> v4l2_std_id norm)
> if (!ret)
> ret = i2c_smbus_write_byte_data(client, CROP_HI,
> ((vdelay >> 2) & 0xc0) |
> - ((vact >> 4) & 0x30) |
> - ((hdelay >> 6) & 0x0c) |
> - ((hact >> 8) & 0x03));
> + ((vact >> 4) & 0x30) |
> + ((hdelay >> 6) & 0x0c) |
> + ((hact >> 8) & 0x03));
> if (!ret)
> ret = i2c_smbus_write_byte_data(client, VDELAY_LO,
> vdelay & 0xff);
> @@ -642,8 +642,7 @@ static int tw9910_s_power(struct v4l2_subdev *sd, int on)
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> struct tw9910_priv *priv = to_tw9910(client);
>
> - return on ? tw9910_power_on(priv) :
> - tw9910_power_off(priv);
> + return on ? tw9910_power_on(priv) : tw9910_power_off(priv);
> }
>
> static int tw9910_set_frame(struct v4l2_subdev *sd, u32 *width, u32 *height)
> @@ -733,7 +732,7 @@ static int tw9910_set_frame(struct v4l2_subdev *sd, u32
> *width, u32 *height)
>
> static int tw9910_get_selection(struct v4l2_subdev *sd,
> struct v4l2_subdev_pad_config *cfg,
> - struct v4l2_subdev_selection *sel)
> + struct v4l2_subdev_selection *sel)
> {
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> struct tw9910_priv *priv = to_tw9910(client);
> @@ -758,7 +757,7 @@ static int tw9910_get_selection(struct v4l2_subdev *sd,
>
> static int tw9910_get_fmt(struct v4l2_subdev *sd,
> struct v4l2_subdev_pad_config *cfg,
> - struct v4l2_subdev_format *format)
> + struct v4l2_subdev_format *format)
> {
> struct v4l2_mbus_framefmt *mf = >format;
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> @@ -809,7 +808,7 @@ static int tw9910_s_fmt(struct v4l2_subdev *sd,
>
> static int tw9910_set_fmt(struct v4l2_subdev *sd,
> struct v4l2_subdev_pad_config *cfg,
> - struct v4l2_subdev_format *format)
> + struct v4l2_subdev_format *format)
> {
> struct v4l2_mbus_framefmt *mf = >format;
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> @@ -900,7 +899,7 @@ static const struct v4l2_subdev_core_ops
> tw9910_subdev_core_ops = {
>
> static int tw9910_enum_mbus_code(struct v4l2_subdev *sd,
>struct v4l2_subdev_pad_config *cfg,
> - struct v4l2_subdev_mbus_code_enum *code)
> + struct v4l2_subdev_mbus_code_enum *code)
> {
> if (code->pad || code->index)
> return -EINVAL;
> --
> 2.15.0
>
[PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output decoder.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/bridge/Kconfig| 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/thc63lvd1024.c | 241 ++
3 files changed, 249 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a..facf6bd 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -92,6 +92,13 @@ config DRM_SII9234
It is an I2C driver, that detects connection of MHL bridge
and starts encapsulation of HDMI signal.
+config DRM_THINE_THC63LVD1024
+ tristate "Thine THC63LVD1024 LVDS decoder bridge"
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ ---help---
+ Thine THC63LVD1024 LVDS decoder bridge driver.
+
config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..fd90b16 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_SII9234) += sii9234.o
+obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
new file mode 100644
index 000..4b059c0
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,241 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * THC63LVD1024 LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const char * const thc63_reg_names[] = {
+ "vcc", "lvcc", "pvcc", "cvcc", };
+
+struct thc63_dev {
+ struct device *dev;
+
+ struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
+
+ struct gpio_desc *pwdn;
+ struct gpio_desc *oe;
+
+ struct drm_bridge bridge;
+ struct drm_bridge *next;
+};
+
+static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct thc63_dev, bridge);
+}
+
+static int thc63_attach(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+
+ return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
+}
+
+static void thc63_enable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ struct regulator *vcc;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
+ vcc = thc63->vccs[i];
+ if (vcc) {
+ ret = regulator_enable(vcc);
+ if (ret)
+ goto error_vcc_enable;
+ }
+ }
+
+ if (thc63->pwdn)
+ gpiod_set_value(thc63->pwdn, 0);
+
+ if (thc63->oe)
+ gpiod_set_value(thc63->oe, 1);
+
+ return;
+
+error_vcc_enable:
+ dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
+}
+
+static void thc63_disable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ struct regulator *vcc;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
+ vcc = thc63->vccs[i];
+ if (vcc) {
+ ret = regulator_disable(vcc);
+ if (ret)
+ goto error_vcc_disable;
+ }
+ }
+
+ if (thc63->pwdn)
+ gpiod_set_value(thc63->pwdn, 1);
+
+ if (thc63->oe)
+ gpiod_set_value(thc63->oe, 0);
+
+ return;
+
+error_vcc_disable:
+ dev_err(thc63->dev, "Failed to disable regulator %u\n", i);
+}
+
+struct drm_bridge_funcs thc63_bridge_func = {
+ .attach = thc63_attach,
+ .enable = thc63_enable,
+ .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+ struct device_node *thc63_out;
+ struct device_node *remote;
+ int ret = 0;
+
+ thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node, 2, -1);
+ if (!thc63_out) {
+ dev_err(thc63->dev, "Missing endpoint in Port@2\n");
+ return -ENODEV;
+ }
+
+ remote = of_graph_get_remote_port_parent(thc63_out);
+ if (!remote) {
+ dev_err(thc63->dev, "E
[PATCH v3 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge
Hello, opposed to v2, this version drops the "transparent LVDS decoder" and provides support for the Thine THC63LVD1024 chip only. I removed all references to "lvds-decoder" and made driver and bindings specific for the above mentioned chip. Andrzej: Bindings now describe 2 available inputs (Port@0 mandatory, Port@1 optional) and 2 possible outputs (Port@2 mandatory, Port@3 optional). The driver still takes only Port@0 and Port@2 into account. This leaves out discussions on how support bridges with multiple input streams within the DRM framework from this series. Simon: Please drop the previous bindings proposal you marked as "deferred" as that one is superseded by this new one. I still plan to use this series to propose an API to propagate formats through bridges, which is not possible at the moment, if I got things right. Thanks j v2 -> v3: - Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific -- Rework bindings to describe multiple input/output ports -- Rename driver and remove "lvds-decoder" references -- Rework Eagle DTS to use new bindings v1 -> v2: - Drop support for THC63LVD1024 Jacopo Mondi (3): dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder drm: bridge: Add thc63lvd1024 LVDS decoder driver arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle .../bindings/display/bridge/thine,thc63lvd1024.txt | 63 ++ arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31 ++- drivers/gpu/drm/bridge/Kconfig | 10 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/thc63lvd1024.c | 239 + 5 files changed, 342 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c -- 2.7.4
[PATCH v3 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Document Thine THC63LVD1024 LVDS decoder device tree bindings.
Signed-off-by: Jacopo Mondi
---
.../bindings/display/bridge/thine,thc63lvd1024.txt | 63 ++
1 file changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..5b5afcd
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,63 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL
outputs.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024",
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry
+- pwnd-gpios: Power down GPIO signal. Active low.
+- oe-gpios: Output enable GPIO signal. Active high.
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- Port@0: First LVDS input port
+- Port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- Port@1: Second LVDS input port
+- Port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+ thc63lvd1024: lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+
+ vcc-supply = <_lvds_vcc>;
+ lvcc-supply = <_lvds_lvcc>;
+
+ pwdn-gpio = < 15 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@2{
+ reg = <2>;
+
+ lvds_dec_out_2: endpoint {
+ remote-endpoint = <_in>;
+ };
+
+ };
+
+ };
+ };
--
2.7.4
[PATCH v3 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
decoder, connected to the on-chip LVDS encoder output on one side
and to HDMI encoder ADV7511w on the other one.
As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver is available, describe it in DT
as well.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 +++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index c0fd144..69f43b8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -42,6 +42,33 @@
};
};
};
+
+ thc63lvd1024: lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ thc63lvd1024_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@2{
+ reg = <2>;
+
+ thc63lvd1024_out_2: endpoint {
+ remote-endpoint = <_in>;
+ };
+
+ };
+
+ };
+ };
};
{
@@ -98,7 +125,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
- remote-endpoint = <_out>;
+ remote-endpoint = <_out_2>;
};
};
@@ -152,8 +179,8 @@
ports {
port@1 {
- endpoint {
- remote-endpoint = <_in>;
+ lvds0_out: endpoint {
+ remote-endpoint = <_in_0>;
};
};
};
--
2.7.4
Re: [PATCH v3 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Andrzej,
sorry for the mess :(
On Wed, Mar 14, 2018 at 09:15:42AM +0100, Andrzej Hajda wrote:
> On 13.03.2018 15:30, Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > .../bindings/display/bridge/thine,thc63lvd1024.txt | 63
> > ++
> > 1 file changed, 63 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..5b5afcd
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,63 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> > streams
> > +to parallel data outputs. The chip supports single/dual input/output modes,
> > +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> > outputs.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024",
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
>
> I wonder if it wouldn't be better to make them required (at least VCC) -
> it is closer to reality.
In cases like our Eagle board, where VCC is directly connected to the
powering rail and not through a controllable regulator, I feel like
making this mandatory requires more effort (not much, I agree, just a
"fixed-regulator" more) with no additional benefits.
But I understand your point, and I'm open to whatever fits better with
the already existing DRM bridges bindings
>
> > +- pwnd-gpios: Power down GPIO signal. Active low.
>
> As I said before, specs[1] says about "/PDWN" pin. Is it your typo, or
> different docs?
I didn't notice the typo in first review, and I thought you were referring to
the initial '/' which I found weird to be part of the gpio name... Then I now
realized I badly typed in "pwnd" in place of "pwdn", which is not even correct
because it has to be "pdwn"... Sorry about this mess, I will fix in v4
> Moreover there are already bindings for THC63LVDM83D with the same
> dichotomy [2].
Seems like this is 'wrong' as well.. The chip manual says the pin is
named "pdwn" here too..
>
> Out of curiosity I have googled for "pwnd pin" and it looks like some
> vendors use this form.
> For me both forms are quite misleading: power down signal, active low,
> why they couldn't call it just 'enable, active high'.
>
It's not much the actual physical active level that bugs me, but the fact
that the GPIO name defines if it has to be set to "active" or
"inactive" logical state in enable/disable routines that I don't
like..
> [1]: http://www.thine.co.jp/files/topics/179_ext_12_0.pdf
> [2]:
> https://elixir.bootlin.com/linux/v4.16-rc5/source/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
>
> > +- oe-gpios: Output enable GPIO signal. Active high.
> > +
> > +The THC63LVD1024 video port connections are modeled according
> > +to OF graph bindings specified by
> > Documentation/devicetree/bindings/graph.txt
> > +
> > +Required video port nodes:
> > +- Port@0: First LVDS input port
> > +- Port@2: First digital CMOS/TTL parallel output
> > +
> > +Optional video port nodes:
> > +- Port@1: Second LVDS input port
> > +- Port@3: Second digital CMOS/TTL parallel output
> > +
> > +Example:
> > +
> > +
> > + thc63lvd1024: lvds-decoder {
> > + compatible = "thine,thc63lvd1024";
> > +
> > + vcc-supply = <_lvds_vcc>;
> > + lvcc-supply = <_lvds_lvcc>;
> > +
> > + pwdn-gpio = < 15 GPIO_ACTIVE_LOW>;
> And here another variation :), should be pdwn-gpios.
Next time it will be "pndw".. Is there a prize if I do insert all
permutations of the same name in a single bindings document? :)
Will fix this shortly.
Thanks
j
signature.asc
Description: PGP signature
Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Hi Andrzej,
thanks for review
On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote:
> On 13.03.2018 15:30, Jacopo Mondi wrote:
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output decoder.
>
> IMO converter suits here better, but it is just suggestion.
>
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/bridge/Kconfig| 7 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/thc63lvd1024.c | 241
> > ++
> > 3 files changed, 249 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3b99d5a..facf6bd 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -92,6 +92,13 @@ config DRM_SII9234
> > It is an I2C driver, that detects connection of MHL bridge
> > and starts encapsulation of HDMI signal.
> >
> > +config DRM_THINE_THC63LVD1024
> > + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> > + depends on OF
> > + select DRM_PANEL_BRIDGE
>
> You don't use PANEL_BRIDGE, it should be possible to drop the select.
>
Ack
> > + ---help---
> > + Thine THC63LVD1024 LVDS decoder bridge driver.
>
> Decoder to what?
> Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
> converter or bridge.
"LVDS to digital CMOS/TTL parallel data converter" as the manual
describes the chip?
>
> > +
> > config DRM_TOSHIBA_TC358767
> > tristate "Toshiba TC358767 eDP bridge"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 373eb28..fd90b16 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> > obj-$(CONFIG_DRM_SII902X) += sii902x.o
> > obj-$(CONFIG_DRM_SII9234) += sii9234.o
> > +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> > obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > new file mode 100644
> > index 000..4b059c0
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -0,0 +1,241 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> > + *
> > + * Copyright (C) 2018 Jacopo Mondi
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +static const char * const thc63_reg_names[] = {
> > + "vcc", "lvcc", "pvcc", "cvcc", };
> > +
> > +struct thc63_dev {
> > + struct device *dev;
> > +
> > + struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
> > +
> > + struct gpio_desc *pwdn;
> > + struct gpio_desc *oe;
> > +
> > + struct drm_bridge bridge;
> > + struct drm_bridge *next;
> > +};
> > +
> > +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> > +{
> > + return container_of(bridge, struct thc63_dev, bridge);
> > +}
> > +
> > +static int thc63_attach(struct drm_bridge *bridge)
> > +{
> > + struct thc63_dev *thc63 = to_thc63(bridge);
> > +
> > + return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> > +}
> > +
> > +static void thc63_enable(struct drm_bridge *bridge)
> > +{
> > + struct thc63_dev *thc63 = to_thc63(bridge);
> > + struct regulator *vcc;
> > + unsigned int i;
> > + int ret;
> > +
> > + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> > + vcc = thc63->vccs[i];
> > + if (vcc) {
> > + ret = regulator_enable(vcc);
> > + if (ret)
> > + goto error_vcc_enable;
> > + }
> > + }
> > +
> > + if (thc63->pwdn)
> > + gpiod_set_value(thc63->pwdn, 0);
> > +
> > + if (thc63->oe)
> > + gpiod_set_value(thc63->oe, 1);
> > +
> > + return;
> > +
&
Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Hi Sergei,
thanks for review
On Wed, Mar 14, 2018 at 08:09:52PM +0300, Sergei Shtylyov wrote:
> On 03/13/2018 05:30 PM, Jacopo Mondi wrote:
>
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output decoder.
> >
> > Signed-off-by: Jacopo Mondi
> [...]
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > new file mode 100644
> > index 000..4b059c0
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -0,0 +1,241 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> > + *
> > + * Copyright (C) 2018 Jacopo Mondi
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +static const char * const thc63_reg_names[] = {
> > + "vcc", "lvcc", "pvcc", "cvcc", };
>
>Your bracing style is pretty strange -- neither here nor there. Please
> place };
> on the next line...
Yeah, I had doubt about this.. The most common style I found around is
static const char * const foo[] = {
"bar",
"baz",
"...",
};
But seems really too many lines for a bunch of 4 character strings...
>
> [...]
> > +static void thc63_enable(struct drm_bridge *bridge)
> > +{
> > + struct thc63_dev *thc63 = to_thc63(bridge);
> > + struct regulator *vcc;
> > + unsigned int i;
> > + int ret;
> > +
> > + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> > + vcc = thc63->vccs[i];
> > + if (vcc) {
> > + ret = regulator_enable(vcc);
> > + if (ret)
>
>You hardly need this variable, could do a call right in this *if*.
>
> [...]
> > +error_vcc_enable:
> > + dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
> > +}
> > +
>
>Why not do this instead of *goto* before?
Well, goto breaks the loop, if I only print out the error message, the
enable sequence will go on and enable the other regulators.
I can print out and break, but I don't see that much benefit
One thing I could do instead, is not only print out the error message,
but disable the already enabled regulators if one fails to start.
>
> > +static void thc63_disable(struct drm_bridge *bridge)
> > +{
> > + struct thc63_dev *thc63 = to_thc63(bridge);
> > + struct regulator *vcc;
> > + unsigned int i;
> > + int ret;
> > +
> > + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> > + vcc = thc63->vccs[i];
> > + if (vcc) {
> > + ret = regulator_disable(vcc);
> > + if (ret)
>
>Again, no need for 'ret' whatsoever...
>
> > + goto error_vcc_disable;
> > + }
> > + }
> > +
> > + if (thc63->pwdn)
> > + gpiod_set_value(thc63->pwdn, 1);
> > +
> > + if (thc63->oe)
> > + gpiod_set_value(thc63->oe, 0);
> > +
> > + return;
> > +
> > +error_vcc_disable:
> > + dev_err(thc63->dev, "Failed to disable regulator %u\n", i);
>
>Again, why not do it instead of *goto*?
ditto
>
> [...]
> > +static int thc63_gpio_init(struct thc63_dev *thc63)
> > +{
> > + thc63->pwdn = devm_gpiod_get_optional(thc63->dev, "pwdn",
> > + GPIOD_OUT_LOW);
> > + if (IS_ERR(thc63->pwdn)) {
> > + dev_err(thc63->dev, "Unable to get GPIO \"pwdn\"\n");
>
>"pwdn-gpios" maybe?
>
> > + return PTR_ERR(thc63->pwdn);
> > + }
> > +
> > + thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
> > + if (IS_ERR(thc63->oe)) {
> > + dev_err(thc63->dev, "Unable to get GPIO \"oe\"\n");
>
>"oe-gpios" maybe?
Are you referring to the error message? I can change this, but again, I
see no standards around.
Thanks
j
>
> [...]
>
> MBR, Sergei
signature.asc
Description: PGP signature
Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
HI Andrezej,
On Thu, Mar 15, 2018 at 10:44:42AM +0100, Andrzej Hajda wrote:
> On 14.03.2018 11:09, jacopo mondi wrote:
> > Hi Andrzej,
> > thanks for review
> >
> > On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote:
> >> On 13.03.2018 15:30, Jacopo Mondi wrote:
> >>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> >>> output decoder.
> >> IMO converter suits here better, but it is just suggestion.
> >>
> >>> Signed-off-by: Jacopo Mondi
> >>> ---
> >>> drivers/gpu/drm/bridge/Kconfig| 7 +
> >>> drivers/gpu/drm/bridge/Makefile | 1 +
> >>> drivers/gpu/drm/bridge/thc63lvd1024.c | 241
> >>> ++
> >>> 3 files changed, 249 insertions(+)
> >>> create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/Kconfig
> >>> b/drivers/gpu/drm/bridge/Kconfig
> >>> index 3b99d5a..facf6bd 100644
> >>> --- a/drivers/gpu/drm/bridge/Kconfig
> >>> +++ b/drivers/gpu/drm/bridge/Kconfig
> >>> @@ -92,6 +92,13 @@ config DRM_SII9234
> >>> It is an I2C driver, that detects connection of MHL bridge
> >>> and starts encapsulation of HDMI signal.
> >>>
> >>> +config DRM_THINE_THC63LVD1024
> >>> + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> >>> + depends on OF
> >>> + select DRM_PANEL_BRIDGE
> >> You don't use PANEL_BRIDGE, it should be possible to drop the select.
> >>
> > Ack
> >
> >>> + ---help---
> >>> + Thine THC63LVD1024 LVDS decoder bridge driver.
> >> Decoder to what?
> >> Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
> >> converter or bridge.
> > "LVDS to digital CMOS/TTL parallel data converter" as the manual
> > describes the chip?
>
> Should work, unless we want some consistency in interface names, we have
> already: parallel / DPI / RGB. I am little bit confused about relations
> between them so I do not want to enforce any.
config DRM_THINE_THC63LVD1024
tristate "Thine THC63LVD1024 LVDS decoder bridge"
depends on OF
---help---
Thine THC63LVD1024 LVDS/parallel converter driver.
I guess this is consistent with other symbol descriptions I found
>
[snip]
>
> >>> +
> >>> +static int thc63_gpio_init(struct thc63_dev *thc63)
> >>> +{
> >>> + thc63->pwdn = devm_gpiod_get_optional(thc63->dev, "pwdn",
> >>> + GPIOD_OUT_LOW);
> >> Shouldn't be GPIOD_OUT_HIGH - bridge initially disabled?
> > No, the PWDN gpio is active low, it puts the chip in power down mode
> > when the physical line level is set to 0.
> >
> > That's another confusing thing, when requesting the GPIO, the actual
> > physical line value has to be provided, while when "set_value()" the
> > logical one is requested, iirc.
>
> I think it is opposite, only *raw* functions uses physical level. Other
> uses logical level.
>
> >
> > Being the GPIO defined as active low, in power enable we set it to
> > "logical inactive" == "physical 1", while during power disable it has
> > to be set to "logical active" == "physical 0"
> >
> > Not the right place to complain here, but imo that's not consistent.
> > Or have I misinterpreted the APIs? I cannot do much test, as in my setup
> > the PWDN pin is hardwired to +vcc (through a physical switch, not
> > controlled through a GPIO though).
>
> devm_gpiod_get_optional calls (indirectly) gpiod_configure_flags, which
> calls gpiod_direction_output which uses logical levels.
I clearly mis-interpreted the APIs.
I'll fix and I'm sending v4 out shortly.
Thanks
j
>
> Regards
> Andrzej
>
> >
> > Thanks
> >j
> >
> >> Regards
> >> Andrzej
> >>> + if (IS_ERR(thc63->pwdn)) {
> >>> + dev_err(thc63->dev, "Unable to get GPIO \"pwdn\"\n");
> >>> + return PTR_ERR(thc63->pwdn);
> >>> + }
> >>> +
> >>> + thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
> >>> + if (IS_ERR(thc63->oe)) {
> >>> + dev_err(thc63->dev, "Unable to get GPIO \"oe\"\n");
> >>> + return PTR_ERR(thc63->oe);
> >>&
[PATCH v4 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge
Hello, this new version fixes comments received from Andrzej and Sergei on the preceding v3. Mostly, I cleaned up the mess with the powerdown GPIO names, and I'm now using pdwn everywhere. The regulator enabling routine has been improved as suggested by Sergei and Andrzej and I've changed Kconfig symbol documentation for consistency with other ones. Also, fix gpio initialization to comply with the APIs that work on logical level even at gpio request time. Branch for testing available at git://jmondi.org v3m/v4.16-rc3/lvds-bridge-v4 Thanks j v3 -> v4: - Rename permutations of "pdwn" to just "pdwn" everywhere in the series - Improve power enable/disable routines as suggested by Andrzej and Sergei - Change "pdwn" gpio initialization to use the logical output level - Change Kconfig description v2 -> v3: - Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific -- Rework bindings to describe multiple input/output ports -- Rename driver and remove "lvds-decoder" references -- Rework Eagle DTS to use new bindings v1 -> v2: - Drop support for THC63LVD1024 Jacopo Mondi (3): dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder drm: bridge: Add thc63lvd1024 LVDS decoder driver arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle .../bindings/display/bridge/thine,thc63lvd1024.txt | 63 + arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 ++- drivers/gpu/drm/bridge/Kconfig | 6 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/thc63lvd1024.c | 255 + 5 files changed, 355 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c -- 2.7.4
[PATCH v4 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Document Thine THC63LVD1024 LVDS decoder device tree bindings.
Signed-off-by: Jacopo Mondi
---
.../bindings/display/bridge/thine,thc63lvd1024.txt | 63 ++
1 file changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..0936bde
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,63 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL
outputs.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024",
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry
+- pdwn-gpios: Power down GPIO signal. Active low.
+- oe-gpios: Output enable GPIO signal. Active high.
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- Port@0: First LVDS input port
+- Port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- Port@1: Second LVDS input port
+- Port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+ thc63lvd1024: lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+
+ vcc-supply = <_lvds_vcc>;
+ lvcc-supply = <_lvds_lvcc>;
+
+ pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@2{
+ reg = <2>;
+
+ lvds_dec_out_2: endpoint {
+ remote-endpoint = <_in>;
+ };
+
+ };
+
+ };
+ };
--
2.7.4
[PATCH v4 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/bridge/Kconfig| 6 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/thc63lvd1024.c | 255 ++
3 files changed, 262 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a..5815a20 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -92,6 +92,12 @@ config DRM_SII9234
It is an I2C driver, that detects connection of MHL bridge
and starts encapsulation of HDMI signal.
+config DRM_THINE_THC63LVD1024
+ tristate "Thine THC63LVD1024 LVDS decoder bridge"
+ depends on OF
+ ---help---
+ Thine THC63LVD1024 LVDS/parallel converter driver.
+
config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..fd90b16 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_SII9234) += sii9234.o
+obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
new file mode 100644
index 000..067f231
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * THC63LVD1024 LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+enum {
+ THC63_LVDS_IN0,
+ THC63_LVDS_IN1,
+ THC63_DIGITAL_OUT0,
+ THC63_DIGITAL_OUT1,
+};
+
+static const char * const thc63_reg_names[] = {
+ "vcc", "lvcc", "pvcc", "cvcc",
+};
+
+struct thc63_dev {
+ struct device *dev;
+
+ struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
+
+ struct gpio_desc *pdwn;
+ struct gpio_desc *oe;
+
+ struct drm_bridge bridge;
+ struct drm_bridge *next;
+};
+
+static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct thc63_dev, bridge);
+}
+
+static int thc63_attach(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+
+ return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
+}
+
+static void thc63_enable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ struct regulator *vcc;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ if (regulator_enable(vcc))
+ goto error_vcc_enable;
+ }
+
+ if (thc63->pdwn)
+ gpiod_set_value(thc63->pdwn, 0);
+
+ if (thc63->oe)
+ gpiod_set_value(thc63->oe, 1);
+
+ return;
+
+error_vcc_enable:
+ dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
+
+ for (i = i - 1; i >= 0; i--) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ regulator_disable(vcc);
+ }
+}
+
+static void thc63_disable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ struct regulator *vcc;
+ int i;
+
+ if (thc63->oe)
+ gpiod_set_value(thc63->oe, 0);
+
+ if (thc63->pdwn)
+ gpiod_set_value(thc63->pdwn, 1);
+
+ for (i = ARRAY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ if (regulator_disable(vcc))
+ dev_dbg(thc63->dev,
+ "Failed to disable regulator %u\n", i);
+ }
+}
+
+struct drm_bridge_funcs thc63_bridge_func = {
+ .attach = thc63_attach,
+ .enable = thc63_enable,
+ .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+ struct device_node *thc63_out;
+ struct device_node *remote;
+ int ret = 0;
+
+ thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+ THC63_DIGITAL_OUT0, -1);
+ if (!thc63_out) {
+ dev_err(thc63->dev, "Missing endpoin
[PATCH v4 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
decoder, connected to the on-chip LVDS encoder output on one side
and to HDMI encoder ADV7511w on the other one.
As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver is available, describe it in DT
as well.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 +++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index c0fd144..69f43b8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -42,6 +42,33 @@
};
};
};
+
+ thc63lvd1024: lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ thc63lvd1024_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@2{
+ reg = <2>;
+
+ thc63lvd1024_out_2: endpoint {
+ remote-endpoint = <_in>;
+ };
+
+ };
+
+ };
+ };
};
{
@@ -98,7 +125,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
- remote-endpoint = <_out>;
+ remote-endpoint = <_out_2>;
};
};
@@ -152,8 +179,8 @@
ports {
port@1 {
- endpoint {
- remote-endpoint = <_in>;
+ lvds0_out: endpoint {
+ remote-endpoint = <_in_0>;
};
};
};
--
2.7.4
Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Laurent,
On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> (CC'ing Rob)
>
> Thank you for the patch.
>
> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi
> > Reviewed-by: Andrzej Hajda
> > Reviewed-by: Niklas Söderlund
> > ---
> > .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++
> > 1 file changed, 66 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..8225c6a
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,66 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> > streams
> > +to parallel data outputs. The chip supports single/dual input/output modes,
> > +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> > outputs.
> > +
> > +Single or dual operation modes, output data mapping and DDR output modes
> > are
> > +configured through input signals and the chip does not expose any control
> > bus.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024"
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
>
> As explained in a comment to one of the previous versions of this series, I'm
> tempted to make vcc-supply mandatory and drop the three other power supplies
> for now, as I believe there's very little chance they will be connected to
> separately controllable regulators (all supplies use the same voltage). In the
> very unlikely event that this occurs in design we need to support in the
> future, the cvcc, lvcc and pvcc supplies can be added later as optional
> without breaking backward compatibility.
Fine, you and Andrzej both agree on this, and I actually do, as all
the supplies have the same voltage.
I'll make vcc the only and mandatory supply.
I'll keep Andrzej Reviwed-by as he suggested it, and add yours.
Thanks
j
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart
>
> > +- pdwn-gpios: Power down GPIO signal. Active low
> > +- oe-gpios: Output enable GPIO signal. Active high
> > +
> > +The THC63LVD1024 video port connections are modeled according
> > +to OF graph bindings specified by
> > Documentation/devicetree/bindings/graph.txt
> > +
> > +Required video port nodes:
> > +- Port@0: First LVDS input port
> > +- Port@2: First digital CMOS/TTL parallel output
> > +
> > +Optional video port nodes:
> > +- Port@1: Second LVDS input port
> > +- Port@3: Second digital CMOS/TTL parallel output
> > +
> > +Example:
> > +
> > +
> > + thc63lvd1024: lvds-decoder {
> > + compatible = "thine,thc63lvd1024";
> > +
> > + vcc-supply = <_lvds_vcc>;
> > + lvcc-supply = <_lvds_lvcc>;
> > +
> > + pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + lvds_dec_in_0: endpoint {
> > + remote-endpoint = <_out>;
> > + };
> > + };
> > +
> > + port@2{
> > + reg = <2>;
> > +
> > + lvds_dec_out_2: endpoint {
> > + remote-endpoint = <_in>;
> > + };
> > +
> > + };
> > +
> > + };
> > + };
>
> --
> Regards,
>
> Laurent Pinchart
>
Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
HI Vladimir,
On Tue, Mar 27, 2018 at 09:24:28AM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/16/2018 05:16 PM, Jacopo Mondi wrote:
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output converter.
> >
> > Signed-off-by: Jacopo Mondi
> > Reviewed-by: Andrzej Hajda
> > Reviewed-by: Niklas Söderlund
> > ---
> > drivers/gpu/drm/bridge/Kconfig| 6 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/thc63lvd1024.c | 255
> > ++
> > 3 files changed, 262 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3b99d5a..5815a20 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -92,6 +92,12 @@ config DRM_SII9234
> > It is an I2C driver, that detects connection of MHL bridge
> > and starts encapsulation of HDMI signal.
> >
> > +config DRM_THINE_THC63LVD1024
> > + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> > + depends on OF
> > + ---help---
> > + Thine THC63LVD1024 LVDS/parallel converter driver.
> > +
> > config DRM_TOSHIBA_TC358767
> > tristate "Toshiba TC358767 eDP bridge"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 373eb28..fd90b16 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> > obj-$(CONFIG_DRM_SII902X) += sii902x.o
> > obj-$(CONFIG_DRM_SII9234) += sii9234.o
> > +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> > obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > new file mode 100644
> > index 000..02a54c2
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -0,0 +1,255 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> > + *
> > + * Copyright (C) 2018 Jacopo Mondi
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +enum {
> > + THC63_LVDS_IN0,
> > + THC63_LVDS_IN1,
> > + THC63_DIGITAL_OUT0,
> > + THC63_DIGITAL_OUT1,
> > +};
> > +
> > +static const char * const thc63_reg_names[] = {
> > + "vcc", "lvcc", "pvcc", "cvcc",
> > +};
> > +
> > +struct thc63_dev {
> > + struct device *dev;
> > +
> > + struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
> > +
> > + struct gpio_desc *pdwn;
> > + struct gpio_desc *oe;
> > +
> > + struct drm_bridge bridge;
> > + struct drm_bridge *next;
> > +};
> > +
> > +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> > +{
> > + return container_of(bridge, struct thc63_dev, bridge);
> > +}
> > +
> > +static int thc63_attach(struct drm_bridge *bridge)
> > +{
> > + struct thc63_dev *thc63 = to_thc63(bridge);
> > +
> > + return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> > +}
> > +
> > +static void thc63_enable(struct drm_bridge *bridge)
> > +{
> > + struct thc63_dev *thc63 = to_thc63(bridge);
> > + struct regulator *vcc;
> > + int i;
>
> unsigned int i;
>
> > +
> > + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> > + vcc = thc63->vccs[i];
> > + if (!vcc)
> > + continue;
> > +
> > + if (regulator_enable(vcc))
> > + goto error_vcc_enable;
> > + }
> > +
> > + if (thc63->pdwn)
> > + gpiod_set_value(thc63->pdwn, 0);
> > +
> > + if (thc63->oe)
> > + gpiod_set_value(thc63->oe, 1);
> > +
> > + return;
> > +
> > +error_vcc_enable:
> > + dev_err(thc63->dev, "Failed to enable regulator %s\n",
> > + thc63_reg_names[i]);
> > +
> > + f
Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Andrzej,
On Tue, Mar 27, 2018 at 09:12:46AM +0200, Andrzej Hajda wrote:
> On 27.03.2018 08:15, Vladimir Zapolskiy wrote:
> > Hi Jacopo,
> >
> > On 03/27/2018 01:22 AM, Rob Herring wrote:
> >> On Tue, Mar 20, 2018 at 02:43:33PM +0200, Laurent Pinchart wrote:
> >>> Hi Jacopo,
> >>>
> >>> (CC'ing Rob)
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote:
> >>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >>>>
> >>>> Signed-off-by: Jacopo Mondi
> >>>> Reviewed-by: Andrzej Hajda
> >>>> Reviewed-by: Niklas Söderlund
> >>>> ---
> >>>> .../bindings/display/bridge/thine,thc63lvd1024.txt | 66
> >>>> +++
> >>>> 1 file changed, 66 insertions(+)
> >>>> create mode 100644
> >>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>>> new file mode 100644
> >>>> index 000..8225c6a
> >>>> --- /dev/null
> >>>> +++
> >>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>>> @@ -0,0 +1,66 @@
> >>>> +Thine Electronics THC63LVD1024 LVDS decoder
> >>>> +---
> >>>> +
> >>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
> >>>> streams
> >>>> +to parallel data outputs. The chip supports single/dual input/output
> >>>> modes,
> >>>> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
> >>>> outputs.
> >>>> +
> >>>> +Single or dual operation modes, output data mapping and DDR output modes
> >>>> are
> >>>> +configured through input signals and the chip does not expose any
> >>>> control
> >>>> bus.
> >>>> +
> >>>> +Required properties:
> >>>> +- compatible: Shall be "thine,thc63lvd1024"
> >>>> +
> >>>> +Optional properties:
> >>>> +- vcc-supply: Power supply for TTL output and digital circuitry
> >>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> >>>> +- lvcc-supply: Power supply for LVDS inputs
> >>>> +- pvcc-supply: Power supply for PLL circuitry
> >>> As explained in a comment to one of the previous versions of this series,
> >>> I'm
> >>> tempted to make vcc-supply mandatory and drop the three other power
> >>> supplies
> >>> for now, as I believe there's very little chance they will be connected to
> >>> separately controllable regulators (all supplies use the same voltage).
> >>> In the
> >>> very unlikely event that this occurs in design we need to support in the
> >>> future, the cvcc, lvcc and pvcc supplies can be added later as optional
> >>> without breaking backward compatibility.
> >> I'm okay with that.
> >>
> >>> Apart from that,
> >>>
> >>> Reviewed-by: Laurent Pinchart
> >>>
> >>>> +- pdwn-gpios: Power down GPIO signal. Active low
> >> powerdown-gpios is the semi-standard name.
> >>
> > right, I've also noticed it. If possible please avoid shortenings in
> > property names.
>
> It is not shortening, it just follow pin name from decoder's datasheet.
>
> >
> >>>> +- oe-gpios: Output enable GPIO signal. Active high
> >>>> +
> > And this one is also a not ever met property name, please consider to
> > rename it to 'enable-gpios', for instance display panels define it.
>
>
> Again, it follows datasheet naming scheme. Has something changed in DT
> conventions?
Seconded. My understanding is that the property name should reflect
what reported in the the chip manual. For THC63LVD1024 the enable and
power down pins are named 'OE' and 'PDWN' respectively.
Thanks
j
>
> Regards
> Andrzej
>
> >
> >>>> +The THC63LVD1024 video port connections are modeled according
> >>>> +to OF graph bindings specified by
> >>>> Documentation/devicetree/bindings/graph.txt
> > [snip]
> >
> >>>> +
> >>>> +port@2{
> >>>> +reg = <2>;
> >>>> +
> >>>> +lvds_dec_out_2: endpoint {
> >>>> +remote-endpoint = <_in>;
> >>>> +};
> >>>> +
> > Drop a surplus empty line above.
> >
> >>>> +};
> >>>> +
> > Drop a surplus empty line above.
> >
> >>>> +};
> >>>> +};
> > --
> > With best wishes,
> > Vladimir
> >
> >
> >
>
Re: [RFC PATCH 2/3] drm: bridge: panel: allow override of the bus format
HI Laurent, Peter,
On Mon, Mar 26, 2018 at 10:03:31PM +0300, Laurent Pinchart wrote:
> Hi Peter,
>
> (CC'ing Jacopo Mondi)
>
> On Sunday, 25 March 2018 15:01:11 EEST Peter Rosin wrote:
> > On 2018-03-20 14:56, Laurent Pinchart wrote:
> > > Hi Peter,
> > >
> > > Thank you for the patch.
> > >
> > > On Sunday, 18 March 2018 00:15:24 EET Peter Rosin wrote:
> > >> Useful if the bridge does some kind of conversion of the bus format.
> > >>
> > >> Signed-off-by: Peter Rosin
> > >> ---
> > >>
> > >> drivers/gpu/drm/bridge/panel.c | 22 +-
> > >> include/drm/drm_bridge.h | 1 +
> > >> 2 files changed, 22 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/bridge/panel.c
> > >> b/drivers/gpu/drm/bridge/panel.c index 6d99d4a3beb3..ccef0283ff41 100644
> > >> --- a/drivers/gpu/drm/bridge/panel.c
> > >> +++ b/drivers/gpu/drm/bridge/panel.c
> > >> @@ -22,6 +22,7 @@ struct panel_bridge {
> > >> struct drm_connector connector;
> > >> struct drm_panel *panel;
> > >> u32 connector_type;
> > >> +u32 bus_format;
> > >> };
> > >>
> > >> static inline struct panel_bridge *
> > >> @@ -40,8 +41,15 @@ static int panel_bridge_connector_get_modes(struct
> > >> drm_connector *connector) {
> > >> struct panel_bridge *panel_bridge =
> > >> drm_connector_to_panel_bridge(connector);
> > >>
> > >> +int ret;
> > >> +
> > >> +ret = drm_panel_get_modes(panel_bridge->panel);
> > >> +
> > >> +if (panel_bridge->bus_format)
> > >> +
> > >> drm_display_info_set_bus_formats(>display_info,
> > >> +
> > >> _bridge->bus_format, 1);
> > >
> > > While I agree with the problem statement and, to some extent, the DT
> > > bindings, I don't think this is the right implementation. You've
> > > correctly noted that display controller shouldn't blindly use the formats
> > > reported by the panel through the connector formats, and that hacking the
> > > panel driver to override the formats isn't a good idea, so I wouldn't
> > > override the formats reported by the connector. I would instead extend
> > > the drm_bridge API to report formats at bridge inputs. This would be more
> > > generic and allow each bridge to configure itself according to the next
> > > bridge in the chain.
> > >
> > > I'm not sure whether this API extension should be in the form of a new
> > > bridge function, or if the formats should be stored in the drm_bridge
> > > structure directly as done for connectors in the display info structure.
> > > I'm tempted by the former, but I'm open to discussions.
> >
> > Ok, I can look into that, but let me check if I got this right. From the
> > very little of the code that I have looked at, I have gathered that display
> > controllers handle bridges explicitly, right?
>
> That's correct, yes. Or, rather, they handle the first bridge in the chain,
> and then other bridges are handled recursively.
>
> > If so, by extending the bridge (with either a new function or new data) you
> > impose changes to all display controllers wanting to handle this new bridge
> > input-format. If so, I assume I can leave out the changes to all display
> > controllers that I do not care about. Correct?
>
> That's correct.
>
> > Also, don't hold your breath waiting for a v2, but I'll try to get to it :-)
>
> I won't hold my breath, but Jacopo might :-) He has a similar issue to solve
> (reporting the LVDS modes supported by the bridge).
>
I was not :) I jumped late on this, as I restarted the DRM bridge work
yesterday. Peter, can I summarize you my current use case? (which is
quite similar to yours actually)
At the R-Car DU (Display Unit) output, we have an LVDS encoder
connected to a 'transparent' LVDS bridge that converts the input LVDS
stream into digital RGB output to be then HDMI encoded by another
component.
The 'transparent LVDS decoder', for which I'm now writing a driver,
should report what pixel bus format it accepts as input as the DU LVDS
encoder can output an LVDS stream with several different component ordering
schemes. I was about to come up with a proposal last week but you beat
me at time, so I'm happy to base my work on what comes out from th
Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Vladimir, On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote: > Hi Sergei, > > On 03/27/2018 11:27 AM, Sergei Shtylyov wrote: > > Hello! > > > > On 3/27/2018 10:33 AM, jacopo mondi wrote: > > [...] > >>>>>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings. > >>>>>>> > >>>>>>> Signed-off-by: Jacopo Mondi > >>>>>>> Reviewed-by: Andrzej Hajda > >>>>>>> Reviewed-by: Niklas Söderlund > >>>>>>> --- > >>>>>>> .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 > >>>>>>> +++ > >>>>>>> 1 file changed, 66 insertions(+) > >>>>>>> create mode 100644 > >>>>>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>> > >>>>>>> diff --git > >>>>>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>> new file mode 100644 > >>>>>>> index 000..8225c6a > >>>>>>> --- /dev/null > >>>>>>> +++ > >>>>>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>> @@ -0,0 +1,66 @@ > >>>>>>> +Thine Electronics THC63LVD1024 LVDS decoder > >>>>>>> +--- > >>>>>>> + > >>>>>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert > >>>>>>> LVDS > >>>>>>> streams > >>>>>>> +to parallel data outputs. The chip supports single/dual input/output > >>>>>>> modes, > >>>>>>> +handling up to two two input LVDS stream and up to two digital > >>>>>>> CMOS/TTL > >>>>>>> outputs. > >>>>>>> + > >>>>>>> +Single or dual operation modes, output data mapping and DDR output > >>>>>>> modes > >>>>>>> are > >>>>>>> +configured through input signals and the chip does not expose any > >>>>>>> control > >>>>>>> bus. > >>>>>>> + > >>>>>>> +Required properties: > >>>>>>> +- compatible: Shall be "thine,thc63lvd1024" > >>>>>>> + > >>>>>>> +Optional properties: > >>>>>>> +- vcc-supply: Power supply for TTL output and digital circuitry > >>>>>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal > >>>>>>> +- lvcc-supply: Power supply for LVDS inputs > >>>>>>> +- pvcc-supply: Power supply for PLL circuitry > >>>>>> As explained in a comment to one of the previous versions of this > >>>>>> series, I'm > >>>>>> tempted to make vcc-supply mandatory and drop the three other power > >>>>>> supplies > >>>>>> for now, as I believe there's very little chance they will be > >>>>>> connected to > >>>>>> separately controllable regulators (all supplies use the same > >>>>>> voltage). In the > >>>>>> very unlikely event that this occurs in design we need to support in > >>>>>> the > >>>>>> future, the cvcc, lvcc and pvcc supplies can be added later as optional > >>>>>> without breaking backward compatibility. > >>>>> I'm okay with that. > >>>>> > >>>>>> Apart from that, > >>>>>> > >>>>>> Reviewed-by: Laurent Pinchart > >>>>>> > >>>>>>> +- pdwn-gpios: Power down GPIO signal. Active low > >>>>> powerdown-gpios is the semi-standard name. > >>>>> > >>>> right, I've also noticed it. If possible please avoid shortenings in > >>>> property names. > >>> > >>> It is not shortening, it just follow pin name from decoder's datasheet. > >>> > >>>> > >>>>>>> +- oe-gpios: Output enable GPIO signal. Active high > >>>>>>> + > >>>> And this one is also a not ever met property name, please consider to > >>>> rename it to 'enable-gpios', for instance display panels define it. > >>> > >>> > >>> Again, it follows datasheet naming scheme. Has something changed in DT > >>> conventions? > >> > >> Seconded. My understanding is that the property name should reflect > >> what reported in the the chip manual. For THC63LVD1024 the enable and > >> power down pins are named 'OE' and 'PDWN' respectively. > > > > But don't we need the vendor prefix in the prop names then, like > > "renesas,oe-gpios" then? > > > > Seconded, with a correction to "thine,oe-gpios". > mmm, okay then... A grep for that semi-standard properties names in Documentation/ returns only usage examples and no actual definitions, so I assume this is why they are semi-standard. Seems like there is some tribal knowledge involved in defining what is semi-standard and what's not, or are those properties documented somewhere? Thanks j > If vendor agnostic properties are supposed to be used, then please follow > the referenced by Rob semi-standard notations. > > -- > With best wishes, > Vladimir signature.asc Description: PGP signature
Re: [PATCH v2 2/5] drm: bridge: add API to query the expected input formats of bridges
Hi Peter,
thanks for the patches
On Mon, Mar 26, 2018 at 11:24:44PM +0200, Peter Rosin wrote:
> Bridges may affect the required bus output format of the encoder, in
> which case it may be wrong to use the output format of the panel or
> connector as is. Add infrastructure to address this problem.
Bridges not only affect the format expected by the connector at the
end of the display pipeline, they may perform encoding/decoding
between protocols and their accepted input formats may be unrelated to
the connector at the end of the pipeline as there may an arbitrary
number of bridges in between.
Eg.
ENCODERCONNECTOR
| |
|DU LVDS| ->lvds-> |THC63| ->rgb-> |ADV7511| ->hdmi-> |HDMI connector|
The fact that THC63 wants a specific LVDS input format is unrelated to
the format required by the HDMI connector at the end of the pipeline.
I would just state here that bridges need a way to report their
accepted media bus formats, and this patch extends the DRM Bridge APIs
to implement that.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/drm_bridge.c | 32
> include/drm/drm_bridge.h | 18 ++
> 2 files changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 1638bfe9627c..f85e61b7416e 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -348,6 +348,38 @@ void drm_bridge_enable(struct drm_bridge *bridge)
> }
> EXPORT_SYMBOL(drm_bridge_enable);
>
> +/**
> + * drm_bridge_input_formats - get the expected bus input format of the bridge
I may be biased by the V4L2 APIs, but this seems to me very much like
similar to g_fmt/s_fmt callbacks we have there. Bridges have an input and
an output formats, and that calls for something that takes that into
account, as well as they may have different input ports with different
accepted formats but I would for now simplify this to just 'g_fmt()'
> + * @bridge: bridge control structure
> + * @bus_formats: where to store a pointer to the bus input formats
> + *
> + * Calls the _bridge_funcs.input_formats op for the frist bridge in the
> + * chain that has registered this op.
I'm not sure passing the call down the pipeline is desirable. Each
component should make sure its output format is accepted as the next
bridge input format, passing the call to the next bridge is not
different that getting to the connector at the end of the pipeline and
return to the initial caller its supported format. Do you agree with this?
> + *
> + * Note that the bridge passed should normally be the bridge closest to the
> + * encoder, but possibly the bridge closest to an intermediate bridge in
> + * convoluted cases.
> + *
As I see this, any bridge in the arbitrary long pipeline should call
this operation on next bridge if it supports different output formats.
Ie. I would not name here the encoder nor refer to the bridge position
in the pipeline.
> + * RETURNS:
> + * The number of bus input formats the bridge accepts. Zero means that
> + * the chain of bridges are not converting the bus format and that the
> + * format of the drm_connector should be used.
How do we get to the connector format from a bridge that has maybe
other components in between in the pipeline?
If a bridge do not report any supported format, it won't implement
this callback and things will work as they work today.
> + */
> +int drm_bridge_input_formats(struct drm_bridge *bridge,
> + const u32 **bus_formats)
> +{
> + int ret = 0;
> +
> + if (!bridge)
> + return 0;
> +
> + if (bridge->funcs->input_formats)
> + ret = bridge->funcs->input_formats(bridge, bus_formats);
> +
> + return ret ?: drm_bridge_input_formats(bridge->next, bus_formats);
See my comment on the call propagation down in the pipeline.
> +}
> +EXPORT_SYMBOL(drm_bridge_input_formats);
> +
> #ifdef CONFIG_OF
> /**
> * of_drm_find_bridge - find the bridge corresponding to the device node in
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 682d01ba920c..ae8d3c4af0b8 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -220,6 +220,22 @@ struct drm_bridge_funcs {
>* The enable callback is optional.
>*/
> void (*enable)(struct drm_bridge *bridge);
> +
> + /**
> + * @input_formats:
> + *
> + * The callback reports the expected bus input formats of the bridge.
> + *
> + * The @input_formats callback is optional. The bridge is assumed to
> + * not convert the bus format if the callback is not installed.
> + *
> + * RETURNS:
> + *
> + * Zero if the bridge does not convert the bus format, otherwise the
> + * number of bus input formats returned in _formats.
> + */
> + int (*input_formats)(struct drm_bridge *bridge,
Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Vladimir, On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote: > Hi Jacopo, > > On 03/27/2018 11:57 AM, jacopo mondi wrote: > > Hi Vladimir, > > > > On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote: > >> Hi Sergei, > >> > >> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote: > >>> Hello! > >>> > >>> On 3/27/2018 10:33 AM, jacopo mondi wrote: > >>> [...] > >>>>>>>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings. > >>>>>>>>> > >>>>>>>>> Signed-off-by: Jacopo Mondi > >>>>>>>>> Reviewed-by: Andrzej Hajda > >>>>>>>>> Reviewed-by: Niklas Söderlund > >>>>>>>>> > >>>>>>>>> --- > >>>>>>>>> .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 > >>>>>>>>> +++ > >>>>>>>>> 1 file changed, 66 insertions(+) > >>>>>>>>> create mode 100644 > >>>>>>>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>>>> > >>>>>>>>> diff --git > >>>>>>>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>>>> new file mode 100644 > >>>>>>>>> index 000..8225c6a > >>>>>>>>> --- /dev/null > >>>>>>>>> +++ > >>>>>>>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>>>> @@ -0,0 +1,66 @@ > >>>>>>>>> +Thine Electronics THC63LVD1024 LVDS decoder > >>>>>>>>> +--- > >>>>>>>>> + > >>>>>>>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert > >>>>>>>>> LVDS > >>>>>>>>> streams > >>>>>>>>> +to parallel data outputs. The chip supports single/dual > >>>>>>>>> input/output modes, > >>>>>>>>> +handling up to two two input LVDS stream and up to two digital > >>>>>>>>> CMOS/TTL > >>>>>>>>> outputs. > >>>>>>>>> + > >>>>>>>>> +Single or dual operation modes, output data mapping and DDR output > >>>>>>>>> modes > >>>>>>>>> are > >>>>>>>>> +configured through input signals and the chip does not expose any > >>>>>>>>> control > >>>>>>>>> bus. > >>>>>>>>> + > >>>>>>>>> +Required properties: > >>>>>>>>> +- compatible: Shall be "thine,thc63lvd1024" > >>>>>>>>> + > >>>>>>>>> +Optional properties: > >>>>>>>>> +- vcc-supply: Power supply for TTL output and digital circuitry > >>>>>>>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal > >>>>>>>>> +- lvcc-supply: Power supply for LVDS inputs > >>>>>>>>> +- pvcc-supply: Power supply for PLL circuitry > >>>>>>>> As explained in a comment to one of the previous versions of this > >>>>>>>> series, I'm > >>>>>>>> tempted to make vcc-supply mandatory and drop the three other power > >>>>>>>> supplies > >>>>>>>> for now, as I believe there's very little chance they will be > >>>>>>>> connected to > >>>>>>>> separately controllable regulators (all supplies use the same > >>>>>>>> voltage). In the > >>>>>>>> very unlikely event that this occurs in design we need to support in > >>>>>>>> the > >>>>>>>> future, the cvcc, lvcc and pvcc supplies can be added later as > >>>>>>>> optional > >>>>>>>> without
Re: [PATCH v2 4/5] drm: bridge: lvds-encoder: allow specifying the input bus format
Hi Peter, Laurent,
thanks for the patches,
On Mon, Mar 26, 2018 at 11:24:46PM +0200, Peter Rosin wrote:
> If the bridge changes the bus format, allow this to be described in
> the bridge, instead of providing false information about the bus
> format of the connector or panel.
>
> Signed-off-by: Peter Rosin
> ---
> .../bindings/display/bridge/lvds-transmitter.txt | 6 ++
> drivers/gpu/drm/bridge/lvds-encoder.c | 25
> ++
> 2 files changed, 31 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> index 50220190c203..8d40a2069252 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> @@ -30,6 +30,12 @@ Required properties:
>device-specific version corresponding to the device first
>followed by the generic version.
>
> +Optional properties:
> +
> +- interface-pix-fmt:
> + List of valid input bus formats of the encoder. Recognized bus formats
> + are listed in ../bus-format.txt
> +
This comments applies here and to [3/5] as well.
Are we sure we want the supported bridge input format defined in DT
bindings?
Again, I may be biased, but as I see this, each bridge driver should
list its supported formats with MEDIA_BUS_FMT_ fourcc codes and return
the currently 'active' one when requested by the preceding bridge.
I understand for this driver, being compatible with both a generic lvds
encoder and a specific chip, the supported input formats are
different, but I would have used the 'of_device_id.data' field for
this and leave this out from DT bindings.
This makes the translation routine here implemented not required if
I'm not wrong...
Thanks
j
> Required nodes:
>
> This device has two video ports. Their connections are modeled using the OF
> diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
> b/drivers/gpu/drm/bridge/lvds-encoder.c
> index 75b0d3f6e4de..b78619b5560a 100644
> --- a/drivers/gpu/drm/bridge/lvds-encoder.c
> +++ b/drivers/gpu/drm/bridge/lvds-encoder.c
> @@ -9,6 +9,7 @@
>
> #include
> #include
> +#include
> #include
>
> #include
> @@ -16,6 +17,8 @@
> struct lvds_encoder {
> struct drm_bridge bridge;
> struct drm_bridge *panel_bridge;
> + int num_bus_formats;
> + u32 *bus_formats;
> };
>
> static int lvds_encoder_attach(struct drm_bridge *bridge)
> @@ -28,8 +31,22 @@ static int lvds_encoder_attach(struct drm_bridge *bridge)
>bridge);
> }
>
> +static int lvds_encoder_input_formats(struct drm_bridge *bridge,
> + const u32 **bus_formats)
> +{
> + struct lvds_encoder *lvds_encoder = container_of(bridge,
> + struct lvds_encoder,
> + bridge);
> +
> + if (lvds_encoder->num_bus_formats)
> + *bus_formats = lvds_encoder->bus_formats;
> +
> + return lvds_encoder->num_bus_formats;
> +}
> +
> static struct drm_bridge_funcs funcs = {
> .attach = lvds_encoder_attach,
> + .input_formats = lvds_encoder_input_formats,
> };
>
> static int lvds_encoder_probe(struct platform_device *pdev)
> @@ -39,6 +56,7 @@ static int lvds_encoder_probe(struct platform_device *pdev)
> struct device_node *panel_node;
> struct drm_panel *panel;
> struct lvds_encoder *lvds_encoder;
> + int ret;
>
> lvds_encoder = devm_kzalloc(>dev, sizeof(*lvds_encoder),
> GFP_KERNEL);
> @@ -79,6 +97,12 @@ static int lvds_encoder_probe(struct platform_device *pdev)
> if (IS_ERR(lvds_encoder->panel_bridge))
> return PTR_ERR(lvds_encoder->panel_bridge);
>
> + ret = drm_of_bus_formats(pdev->dev.of_node, "interface-pix-fmt",
> + _encoder->bus_formats);
> + if (ret < 0)
> + return ret;
> + lvds_encoder->num_bus_formats = ret;
> +
> /* The panel_bridge bridge is attached to the panel's of_node,
>* but we need a bridge attached to our of_node for our user
>* to look up.
> @@ -96,6 +120,7 @@ static int lvds_encoder_remove(struct platform_device
> *pdev)
> {
> struct lvds_encoder *lvds_encoder = platform_get_drvdata(pdev);
>
> + kfree(lvds_encoder->bus_formats);
> drm_bridge_remove(_encoder->bridge);
>
> return 0;
> --
> 2.11.0
>
signature.asc
Description: PGP signature
Re: [PATCH v2 2/5] drm: bridge: add API to query the expected input formats of bridges
Hi Peter, On Tue, Mar 27, 2018 at 02:12:42PM +0200, Peter Rosin wrote: > Hi Jacopo, > > Thanks for the feedback! > > On 2018-03-27 11:47, jacopo mondi wrote: > > Hi Peter, > >thanks for the patches > > > > On Mon, Mar 26, 2018 at 11:24:44PM +0200, Peter Rosin wrote: > >> Bridges may affect the required bus output format of the encoder, in > >> which case it may be wrong to use the output format of the panel or > >> connector as is. Add infrastructure to address this problem. > > > > Bridges not only affect the format expected by the connector at the > > end of the display pipeline, they may perform encoding/decoding > > between protocols and their accepted input formats may be unrelated to > > the connector at the end of the pipeline as there may an arbitrary > > number of bridges in between. > > > > Eg. > > > > ENCODERCONNECTOR > > | | > > |DU LVDS| ->lvds-> |THC63| ->rgb-> |ADV7511| ->hdmi-> |HDMI connector| > > > > The fact that THC63 wants a specific LVDS input format is unrelated to > > the format required by the HDMI connector at the end of the pipeline. > > > > I would just state here that bridges need a way to report their > > accepted media bus formats, and this patch extends the DRM Bridge APIs > > to implement that. > > Yes, I can add some words, but I would like to clear up the naming > before re-spinning. > > >> > >> Signed-off-by: Peter Rosin > >> --- > >> drivers/gpu/drm/drm_bridge.c | 32 > >> include/drm/drm_bridge.h | 18 ++ > >> 2 files changed, 50 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > >> index 1638bfe9627c..f85e61b7416e 100644 > >> --- a/drivers/gpu/drm/drm_bridge.c > >> +++ b/drivers/gpu/drm/drm_bridge.c > >> @@ -348,6 +348,38 @@ void drm_bridge_enable(struct drm_bridge *bridge) > >> } > >> EXPORT_SYMBOL(drm_bridge_enable); > >> > >> +/** > >> + * drm_bridge_input_formats - get the expected bus input format of the > >> bridge > > > > I may be biased by the V4L2 APIs, but this seems to me very much like > > similar to g_fmt/s_fmt callbacks we have there. Bridges have an input and > > g_fmt/s_fmt says nothing to me. Graphics format? Source Format? I have > no idea if those guesses are even close? So, that seems like poor naming > to me. The only reason I see to go that way is for the sake of consistency. > Sorry, I wasn't clear here. To me this operation seems like a "get format" and I see space for future implementation of "set format" operations and also "enum_formats" to implement format negotiation between bridges... > > an output formats, and that calls for something that takes that into > > account, as well as they may have different input ports with different > > accepted formats but I would for now simplify this to just 'g_fmt()' > > You mean rename the function to drm_bridge_g_fmt(), right? Yeah, something like "drm_bridge_get_format(next_bridge)" > > As indicated above, I'm not that fond of it, but don't really care > either. Maintainers? > I do not care much about the name too ofc, I think the real meat is below... > >> + * @bridge: bridge control structure > >> + * @bus_formats: where to store a pointer to the bus input formats > >> + * > >> + * Calls the _bridge_funcs.input_formats op for the frist bridge in > >> the > >> + * chain that has registered this op. > > > > I'm not sure passing the call down the pipeline is desirable. Each > > component should make sure its output format is accepted as the next > > bridge input format, passing the call to the next bridge is not > > different that getting to the connector at the end of the pipeline and > > return to the initial caller its supported format. Do you agree with this? > > Not passing down the call does one of two things. Either all bridges have > to implement the call or all users have to walk the pipeline "manually". > I don't like either or those options, so I still think it is good to > pass the call down the pipeline. > > *time passes* > > Oh, you do not think it is useful for the bridge to have a callback but > still report "no format change", and that the call down to pipeline > should only happen for bridges that have not implemented the op. But I > do think
Re: [PATCH 04/15] pinctrl: sh-pfc: Initial R-Car M3-N support
Hi Geert,
thanks for review
On Wed, Feb 14, 2018 at 02:37:08PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Tue, Feb 13, 2018 at 10:45 AM, Jacopo Mondi
> wrote:
> > Add initial PFC support for R-Car M3-N (r8a77965) SoC.
> > No groups or functions defined, just pin and registers enumeration.
> >
> > Signed-off-by: Jacopo Mondi
>
> Thanks for your patch!
>
> Looks mostly OK to me.
> You do want to compare with pfc-r8a7796.c: all differences not related to
> SATA_DEVSL, FSCLK, DU_DOTCLKIN2/3, and PRESET are issues that were fixed
> recently in pfc-r8a7796.c, and should apply to pfc-r8a77965.c, too.
>
I have used the M3-W tables with the exception of the pins/groups you
mentioned, that are clearly marked as different in the datasheet. At
least, this was my intention :)
I used v4.15 M3-W PFC tables, should I look in v4.16-rc1 or in
renesas-drivers for updates?
> That leaves us with very few differences only, but it won't be trivial to have
> a combined M3-W/N PFC driver, I'm afraid.
>
Takes a certain degree of grep-foo to clearly highlight differences
between the two version. Do you have any script/tools you use to
compare PFC tables a bit more easily?
Thanks
j
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH 2/2] media: Add a driver for the ov7251 camera sensor
Hi Todor,
thanks for the patch.
Is the datsheet for this sensor public? I failed to find any reference
to it online, am I wrong?
On Thu, Feb 08, 2018 at 10:53:38AM +0200, Todor Tomov wrote:
> The ov7251 sensor is a 1/7.5-Inch B VGA (640x480) CMOS Digital Image
> Sensor from Omnivision.
>
> The driver supports the following modes:
> - 640x480 30fps
> - 640x480 60fps
> - 640x480 90fps
>
> Output format is MIPI RAW 10.
>
> The driver supports configuration via user controls for:
> - exposure and gain;
> - horizontal and vertical flip;
> - test pattern.
>
> Signed-off-by: Todor Tomov
> ---
> drivers/media/i2c/Kconfig | 13 +
> drivers/media/i2c/Makefile |1 +
> drivers/media/i2c/ov7251.c | 1523
>
> 3 files changed, 1537 insertions(+)
> create mode 100644 drivers/media/i2c/ov7251.c
>
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 9f18cd2..bfa9aab 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -645,6 +645,19 @@ config VIDEO_OV5670
> To compile this driver as a module, choose M here: the
> module will be called ov5670.
>
> +config VIDEO_OV7251
> + tristate "OmniVision OV7251 sensor support"
> + depends on OF
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CAMERA_SUPPORT
> + select V4L2_FWNODE
> + ---help---
> + This is a Video4Linux2 sensor-level driver for the OmniVision
> + OV7251 camera.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ov7251.
> +
> config VIDEO_OV7640
> tristate "OmniVision OV7640 sensor support"
> depends on I2C && VIDEO_V4L2
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index c0f94cd..be6b3d3 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -66,6 +66,7 @@ obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
> obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
> obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
> obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
> +obj-$(CONFIG_VIDEO_OV7251) += ov7251.o
> obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
> obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
> obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
> diff --git a/drivers/media/i2c/ov7251.c b/drivers/media/i2c/ov7251.c
> new file mode 100644
> index 000..f217177
> --- /dev/null
> +++ b/drivers/media/i2c/ov7251.c
> @@ -0,0 +1,1523 @@
> +/*
> + * Driver for the OV7251 camera sensor.
> + *
> + * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2017-2018, Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only 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.
> + */
Please use SPDX identifiers instead of the license text
// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define OV7251_VOLTAGE_ANALOG 280
> +#define OV7251_VOLTAGE_DIGITAL_CORE 150
> +#define OV7251_VOLTAGE_DIGITAL_IO 180
> +
> +#define OV7251_SC_MODE_SELECT0x0100
> +#define OV7251_SC_MODE_SELECT_SW_STANDBY 0x0
> +#define OV7251_SC_MODE_SELECT_STREAMING 0x1
> +
> +#define OV7251_CHIP_ID_HIGH 0x300a
> +#define OV7251_CHIP_ID_HIGH_BYTE0x77
> +#define OV7251_CHIP_ID_LOW 0x300b
> +#define OV7251_CHIP_ID_LOW_BYTE 0x50
> +#define OV7251_SC_GP_IO_IN1 0x3029
> +#define OV7251_AEC_EXPO_00x3500
> +#define OV7251_AEC_EXPO_10x3501
> +#define OV7251_AEC_EXPO_20x3502
> +#define OV7251_AEC_AGC_ADJ_0 0x350a
> +#define OV7251_AEC_AGC_ADJ_1 0x350b
> +#define OV7251_TIMING_FORMAT10x3820
> +#define OV7251_SENSOR_VFLIP BIT(2)
> +#define OV7251_TIMING_FORMAT20x3821
> +#define OV7251_SENSOR_MIRRORBIT(2)
> +#define OV7251_PRE_ISP_000x5e00
> +#define OV7251_TEST_PATTERN_BAR_ENABLE BIT(7)
Are those tabs between the define and the macro name there by purpose?
If they are bits in the register address defined above them, wouldn't
it be better to capture there in the name?
Eg.
OV7251_TIMING_FMT1 0x3820
OV7251_TIMING_FMT1_VFLIPBIT(2)
> +
> +struct reg_value {
> + u16 reg;
> + u8 val;
> +};
> +
> +struct ov7251_mode_info {
> + u32
Re: [PATCH v2 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
Hi Sergei,
On Fri, Mar 09, 2018 at 08:30:36PM +0300, Sergei Shtylyov wrote:
> On 03/09/2018 04:51 PM, Jacopo Mondi wrote:
>
> > The R-Car V3M Eagle board includes a transparent LVDS decoder, connected
> > to the on-chip LVDS encoder output on one side and to HDMI encoder
> > ADV7511w on the other one.
> >
> > As the decoder does not need any configuration it has been so-far
> > omitted from DTS. Now that a driver for transparent LVDS decoder is
> > available, describe it in DT as well.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31
> > --
> > 1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > index c0fd144..0a95c20 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > @@ -42,6 +42,33 @@
> > };
> > };
> > };
> > +
> > + lvds,decoder {
>
>I said hyphen (-), not comma (,)! :-)
Ahah ok, my bad, I somehow confused the two :)
It looked weird to me, but I thought you were pointing me to some
convention I didn't know about!
I'll change this in v3
Thanks
j
>
> [...]
>
> MBR, Sergei
Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge
Hello Archit,
On Sat, Mar 10, 2018 at 11:23:19AM +0530, Archit Taneja wrote:
> Hi,
>
> On Friday 09 March 2018 07:21 PM, Jacopo Mondi wrote:
> >Hello,
> >after some discussion on the proposed bindings for generic lvds decoder
> > and
> >Thine THC63LVD1024, I decided to drop the THC63 specific part and just live
> >with
> >a transparent decoder that does not support any configuration from DT.
> >
> >Dropping THC63 support to avoid discussion on how to better implement support
> >for a DRM bridge with 2 input ports and focus on LVDS mode propagation
> >through
> >bridges as explained in v1 cover letter (for DRM people: please see [1] as
> >why
> >I find difficult to implement support for bridges with multiple input
> >endpoints)
> >
> >Same base branch as v1, with same patches for V3M Eagle applied on top.
> >git://jmondi.org/linux v3m/v4.16-rc3/base
> >
> >Thanks
> >j
> >
> >v1 -> v2:
> >- Drop support for THC63LVD1024
> >
> >[1] I had a quick at how to model a DRM bridge with multiple input
> >ports, and I see a blocker in how DRM identifies and matches bridges using
> >the devices node in place of the endpoint nodes.
> >
> >As THC63LVD1024 supports up to 2 LVDS inputs and 2 LVDS outputs, I see only
> >a few ways to support that:
> > 1) register 2 drm bridges from the same driver (one for each input/output
> > pair)
> > but they would both be matches on the same device node when the
> > preceding
> > bridge calls "of_drm_find_bridge()".
>
> I think this is the way to go. DRM doesn't say anywhere that we can't have 2
> drm_bridge-s contained in a single device. About the issue with
> of_drm_find_bridge(), if you set the 2 bridge's 'of_node' field to
> the bridge1 and bridge2 nodes as shown below, wouldn't that suffice. From
> what I know, we don't necessarily need to set the bridge's of_node
> to the device (i.e, thschip) itself.
That's fine, but this implies that the preceding bridge (or encoder) in the
DRM pipeline has then to collect the "port" node and match on it
specifically when it attaches this driver. This introduces an ad-hoc
policy that prevents this driver from being easily integrated in
existing pipelines (where bridges are matched on the device node).
Also, I don't know much about the DRM framework, but it seems to me
that the helper function designed to find the next component to attach
to in the DRM pipeline is:
drm_of_find_panel_or_bridge():
remote = of_graph_get_remote_node();
ep = of_graph_get_endpoint_by_regs();
return of_graph_get_remote_port_parent(); <-- This returns the
device node
of_drm_find_panel(remote);
of_drm_find_bridge(remote);
I so dare to say matching on device node is kind of the intended way
to do things in DRM, and this driver with two endpoints that wants to
be matched on port nodes would be kind of special one that does not
work as other driver expects to.
Is my understanding correct, or have I misinterpreted something?
Thanks
j
>
> thschip {
> ...
> ports {
> bridge1: port@0 {
> ...
> };
>
> bridge2: port@1 {
> ...
> };
> };
> };
>
>
> Thanks,
> Archit
>
> > 2) register a single bridge with multiple "next bridges", but when the
> > bridge
> > gets attached I don't see a way on how to identify on which next bridge
> > "drm_bridge_attach()" on, as it depends on the endpoint the current
> > bridge
> > has been attached on first, and we don't have that information.
> > 3) Register more instances of the same chip in DTS, one for each
> > input/output
> > pair. They gonna share supplies and gpios, and I don't like that.
> >
> >I had a quick look at the currently in mainline bridges and none of them has
> >multiple input endpoints, except for HDMI audio endpoint, which I haven't
> >found
> >in use in any DTS. I guess the problem has been already debated and maybe
> >solved
> >in the past, so feel free to point me to other sources.
> >
> >Jacopo Mondi (3):
> > dt-bindings: display: bridge: Document LVDS to parallel decoder
> > drm: bridge: Add LVDS decoder driver
> > arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
> >
> > .../bindings/display/bridge/lvds-decoder.txt | 42 ++
> > arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31 +++-
> > drivers/gpu/drm/bridge/Kconfig | 8 ++
> > drivers/gpu/drm/bridge/Makefile| 1 +
> > drivers/gpu/drm/bridge/lvds-decoder.c | 157
> > +
> > 5 files changed, 237 insertions(+), 2 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/lvds-decoder.txt
> > create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c
> >
> >--
> >2.7.4
> >
Re: [PATCH 0/5] Renesas CEU: SH7724 ECOVEC + Aptina mt9t112
Hi Hans, On Sat, Mar 10, 2018 at 06:57:17PM +0100, Hans Verkuil wrote: > Hi Jacopo, > > On 02/03/18 17:35, Jacopo Mondi wrote: > > Hello, > >now that CEU has been picked up for inclusion in v4.17, we can start > > moving > > users of old sh_mobile_ceu_camera driver to use the newly introduced one. > > > > Migo-R has been first, now it's SH7724 ECOVEC board turn. > > > > ECOVEC has a camera board with two MT9T112 image sensor and one TW9910 video > > decoder input. This series moves the mt9t112 driver away from soc_camera > > framework and remove dependencies on it in mach-ecovec board code. > > > > As per Migo-R, memory for CEU is reserved using memblocks APIs and declared > > as DMA-capable in board code, power up/down routines have been removed from > > board code, and GPIOs lookup table registered for sensor drivers. > > > > As in the previous series, still no code has been removed or changed in > > drivers/media/i2c/soc_camera/ until we do not remove all dependencies on it > > in all board files. > > > > Hans, since you asked me to add frame rate interval support for ov772x I > > expect > > to receive the same request for mt9t112. Unfortunately I do not have access > > to > > register level documentation, nor can perform any testing as I don't have > > the > > camera modules. For the same reason I cannot run any v4l2-compliance test on > > that driver, but just make sure the ECOVEC boots cleanly with the new board > > file. I'm in favour of moving the driver to staging if you think that's the > > case. > > > > Series based on media-tree master, and as per Migo-R I would ask SH arch/ > > changes to go through media tree as SH maintainers are un-responsive. > > When compiling this series I get this error: > > drivers/media/i2c/soc_camera/mt9t112.c: In function ‘mt9t112_init_pll’: > drivers/media/i2c/soc_camera/mt9t112.c:426:16: error: dereferencing pointer > to incomplete type ‘struct mt9t112_camera_info’ > priv->info->divider.m, > ^~ > > Can you take a look? Ups, changing the driver interface ofc breaks the soc_camera version of the driver (I didn't notice as I've compiled soc_camera out in my tests). As the old driver is the only user of that interface this series doesn't touch[1] I'll rename the old 'struct mt9t112_camera_info' to the newly introduced 'struct mt9t112_platform_data' (and I've made sure nobody uses the flag definitions I have removed). I'll pile another patch on top of the one just sent to add the TODO note at driver's beginning. Sorry about that j [1] $git grep "media/i2c/mt9t112.h" . MAINTAINERS:F: include/media/i2c/mt9t112.h arch/sh/boards/mach-ecovec24/setup.c:#include drivers/media/i2c/mt9t112.c:#include drivers/media/i2c/soc_camera/mt9t112.c:#include > > Regards, > > Hans > > > > > Thanks > > j > > > > Jacopo Mondi (5): > > media: i2c: Copy mt9t112 soc_camera sensor driver > > media: i2c: mt9t112: Remove soc_camera dependencies > > media: i2c: mt9t112: Fix code style issues > > arch: sh: ecovec: Use new renesas-ceu camera driver > > media: MAINTAINERS: Add entry for Aptina MT9T112 > > > > MAINTAINERS|7 + > > arch/sh/boards/mach-ecovec24/setup.c | 338 +- > > arch/sh/kernel/cpu/sh4a/clock-sh7724.c |4 +- > > drivers/media/i2c/Kconfig | 11 + > > drivers/media/i2c/Makefile |1 + > > drivers/media/i2c/mt9t112.c| 1136 > > > > include/media/i2c/mt9t112.h| 17 +- > > 7 files changed, 1333 insertions(+), 181 deletions(-) > > create mode 100644 drivers/media/i2c/mt9t112.c > > > > -- > > 2.7.4 > > >
Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge
Hi Andrzej, On Mon, Mar 12, 2018 at 10:07:27AM +0100, Andrzej Hajda wrote: > On 09.03.2018 14:51, Jacopo Mondi wrote: > > Hello, > >after some discussion on the proposed bindings for generic lvds decoder > > and > > Thine THC63LVD1024, I decided to drop the THC63 specific part and just live > > with > > a transparent decoder that does not support any configuration from DT. > > > > Dropping THC63 support to avoid discussion on how to better implement > > support > > for a DRM bridge with 2 input ports and focus on LVDS mode propagation > > through > > bridges as explained in v1 cover letter (for DRM people: please see [1] as > > why > > I find difficult to implement support for bridges with multiple input > > endpoints) > > > > Same base branch as v1, with same patches for V3M Eagle applied on top. > > git://jmondi.org/linux v3m/v4.16-rc3/base > > > > Thanks > >j > > > > v1 -> v2: > > - Drop support for THC63LVD1024 > > > > [1] I had a quick at how to model a DRM bridge with multiple input > > ports, and I see a blocker in how DRM identifies and matches bridges using > > the devices node in place of the endpoint nodes. > > > > As THC63LVD1024 supports up to 2 LVDS inputs and 2 LVDS outputs, I see only > > a few ways to support that: > > 1) register 2 drm bridges from the same driver (one for each input/output > > pair) > > but they would both be matches on the same device node when the > > preceding > > bridge calls "of_drm_find_bridge()". > > 2) register a single bridge with multiple "next bridges", but when the > > bridge > > gets attached I don't see a way on how to identify on which next bridge > > "drm_bridge_attach()" on, as it depends on the endpoint the current > > bridge > > has been attached on first, and we don't have that information. > > 3) Register more instances of the same chip in DTS, one for each > > input/output > > pair. They gonna share supplies and gpios, and I don't like that. > > > > I had a quick look at the currently in mainline bridges and none of them has > > multiple input endpoints, except for HDMI audio endpoint, which I haven't > > found > > in use in any DTS. I guess the problem has been already debated and maybe > > solved > > in the past, so feel free to point me to other sources. > > I think this is is a step in wrong direction, IMHO. Your previous > patchset was quite OK, at least bindings, IMHO. Few things needed only > polishing. > Here we have unmanaged/transparent bridge, which is totally different, > what happened to regulators and gpios from previous iteration. > I do not have schematics of the board, but I guess respective pins of > the bridge must be connected somehow. > I think the problem you want to avoid (double bridge) should not be a > problem at all. > I suppose the most important is to have correct bindings - as they need > to be stable. > If you really must to do hacks better is to put them into driver. > I understand. The "transparent bridge" is of no actual use, but I don't see how the "double bridge" thing is not an issue if I were to develop support for the actual Thine chip. Please see my reply from yesterday to Archit. I still think having two bridges is somehow an issue... While we clarify that, would it be fine an initial driver version for the actualt Thine chip with a single input support[1]? I would ditch this transparent bridge and resume working on a THC63LVD1024 driver from comments received on v1. Thanks j [1] Single input support implies a single input port in DT bindings even if the chip supports two, and my understanding was that you didn't like this. > Regards > Andrzej > > > > > Jacopo Mondi (3): > > dt-bindings: display: bridge: Document LVDS to parallel decoder > > drm: bridge: Add LVDS decoder driver > > arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle > > > > .../bindings/display/bridge/lvds-decoder.txt | 42 ++ > > arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31 +++- > > drivers/gpu/drm/bridge/Kconfig | 8 ++ > > drivers/gpu/drm/bridge/Makefile| 1 + > > drivers/gpu/drm/bridge/lvds-decoder.c | 157 > > + > > 5 files changed, 237 insertions(+), 2 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/lvds-decoder.txt > > create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c > > > > -- > > 2.7.4 > > > > > > > > > signature.asc Description: PGP signature
[PATCH v2 3/4] arch: sh: ecovec: Use new renesas-ceu camera driver
SH4 7724 Ecovec platform uses sh_mobile_ceu camera driver, which is now
being replaced by a proper V4L2 camera driver named 'renesas-ceu'.
Get rid of soc_camera defined components used to register sensor drivers
and of platform specific enable/disable routines.
Register GPIOs for sensor drivers and declare memory reserved with
memblock APIs as dma capable to be used for CEU buffers.
While at there re-order include directives to respect alphabetical
ordering.
Signed-off-by: Jacopo Mondi
---
arch/sh/boards/mach-ecovec24/setup.c | 338 -
arch/sh/kernel/cpu/sh4a/clock-sh7724.c | 4 +-
2 files changed, 171 insertions(+), 171 deletions(-)
diff --git a/arch/sh/boards/mach-ecovec24/setup.c
b/arch/sh/boards/mach-ecovec24/setup.c
index 6f929ab..adc61d1 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -7,44 +7,47 @@
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*/
-
-#include
+#include
+#include
+#include
+#include
+#include
#include
-#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
#include
#include
-#include
#include
-#include
-#include
-#include
+#include
+#include
+#include
+#include
#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
#include
#include
+#include
+#include
+#include
+#include
+#include
#include
-#include
+
+#include
+#include
+#include
+
#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
+
+#include
/*
* Address InterfaceBusWidth
@@ -81,6 +84,10 @@
* amixer set 'Out Mixer Right DAC Right' on
*/
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu0_dma_membase;
+static phys_addr_t ceu1_dma_membase;
+
/* Heartbeat */
static unsigned char led_pos[] = { 0, 1, 2, 3 };
@@ -382,8 +389,24 @@ static struct platform_device gpio_backlight_device = {
};
/* CEU0 */
-static struct sh_mobile_ceu_info sh_mobile_ceu0_info = {
- .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_platform_data ceu0_pdata = {
+ .num_subdevs= 2,
+ .subdevs = {
+ { /* [0] = mt9t112 */
+ .flags = 0,
+ .bus_width = 8,
+ .bus_shift = 0,
+ .i2c_adapter_id = 0,
+ .i2c_address= 0x3c,
+ },
+ { /* [1] = tw9910 */
+ .flags = 0,
+ .bus_width = 8,
+ .bus_shift = 0,
+ .i2c_adapter_id = 0,
+ .i2c_address= 0x45,
+ },
+ },
};
static struct resource ceu0_resources[] = {
@@ -397,24 +420,30 @@ static struct resource ceu0_resources[] = {
.start = evt2irq(0x880),
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* place holder for contiguous memory */
- },
};
static struct platform_device ceu0_device = {
- .name = "sh_mobile_ceu",
- .id = 0, /* "ceu0" clock */
+ .name = "renesas-ceu",
+ .id = 0, /* ceu.0 */
.num_resources = ARRAY_SIZE(ceu0_resources),
.resource = ceu0_resources,
.dev= {
- .platform_data = _mobile_ceu0_info,
+ .platform_data = _pdata,
},
};
/* CEU1 */
-static struct sh_mobile_ceu_info sh_mobile_ceu1_info = {
- .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_platform_data ceu1_pdata = {
+ .num_subdevs= 1,
+ .subdevs = {
+ { /* [0] = mt9t112 */
+ .flags = 0,
+ .bus_width = 8,
+ .bus_shift = 0,
+ .i2c_adapter_id = 1,
+ .i2c_address= 0x3c,
+ },
+ },
};
static struct resource ceu1_resources[] = {
@@ -428,26 +457,71 @@ static struct resource ceu1_resources[] = {
.start = evt2irq(0x9e0),
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* place holder for contiguous memory */
- },
};
static struct platform_device ceu1_device = {
- .name = "sh_mobile_ceu",
- .id = 1, /* "ceu1" clock */
+ .name = "renesas-ceu",
+ .id = 1, /* ceu.1 */
.num_resources = ARRAY_SIZE(ceu1_resources),
.resource = ceu1_resources,
.dev= {
- .platform_data = _mobile_ceu1_info,
+ .platform_data = _
[PATCH v2 2/4] media: i2c: mt9t112: Remove soc_camera dependencies
Remove soc_camera framework dependencies from mt9t112 sensor driver.
- Handle clk, gpios and power routines
- Register async subdev
- Remove deprecated g/s_mbus_config operations
- Remove driver flags
- Change driver interface and add kernel doc
- Adjust build system
- Fix code style issues reported by checkpatch in strict mode
This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera framework.
As I don't have access to a working camera module, this change has only
been compile tested.
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/mt9t112.c| 403 -
drivers/media/i2c/soc_camera/mt9t112.c | 2 +-
include/media/i2c/mt9t112.h| 17 +-
5 files changed, 210 insertions(+), 224 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index d7bba0e..541f0d28 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -788,6 +788,17 @@ config VIDEO_MT9T001
This is a Video4Linux2 sensor-level driver for the Aptina
(Micron) mt0t001 3 Mpixel camera.
+config VIDEO_MT9T112
+ tristate "Aptina MT9T111/MT9T112 support"
+ depends on I2C && VIDEO_V4L2
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the Aptina
+ (Micron) MT9T111 and MT9T112 3 Mpixel camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mt9t112.
+
config VIDEO_MT9V011
tristate "Micron mt9v011 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index cc30178..ea34aee 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
obj-$(CONFIG_VIDEO_MT9M111) += mt9m111.o
obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o
+obj-$(CONFIG_VIDEO_MT9T112) += mt9t112.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
index 297d22e..af8cca9 100644
--- a/drivers/media/i2c/mt9t112.c
+++ b/drivers/media/i2c/mt9t112.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* mt9t112 Camera Driver
*
+ * Copyright (C) 2018 Jacopo Mondi
+ *
* Copyright (C) 2009 Renesas Solutions Corp.
* Kuninori Morimoto
*
@@ -12,12 +15,14 @@
* Copyright (C) 2008 Magnus Damm
* Copyright (C) 2008, Guennadi Liakhovetski
*
- * 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.
+ * TODO: This driver lacks support for frame rate control due to missing
+ * register level documentation and suitable hardware for testing.
+ * v4l-utils compliance tools will report errors.
*/
+#include
#include
+#include
#include
#include
#include
@@ -26,17 +31,16 @@
#include
#include
-#include
-#include
#include
#include
+#include
/* you can check PLL/clock info */
/* #define EXT_CLOCK 2400 */
/
- macro
-/
+ * macro
+ ***/
/*
* frame size
*/
@@ -74,8 +78,8 @@
#define VAR8(id, offset) _VAR(id, offset, 0x8000)
/
- struct
-/
+ * struct
+ ***/
struct mt9t112_format {
u32 code;
enum v4l2_colorspace colorspace;
@@ -85,21 +89,19 @@ struct mt9t112_format {
struct mt9t112_priv {
struct v4l2_subdev subdev;
- struct mt9t112_camera_info *info;
+ struct mt9t112_platform_data*info;
struct i2c_client *client;
struct v4l2_rect frame;
- struct v4l2_clk *clk;
+ struct clk *clk;
+ struct gpio_desc*standby_gpio;
const struct mt9t112_format *format;
int num_formats;
- u32 flags;
-/* for flags */
-#define INIT_DONE (1 << 0)
-#define PCLK_RISING(1 << 1)
+ bool init_done;
};
/*
[PATCH v2 1/4] media: i2c: Copy mt9t112 soc_camera sensor driver
Copy the soc_camera based driver in v4l2 sensor driver directory.
This commit just copies the original file without modifying it.
No modification to KConfig and Makefile as soc_camera framework
dependencies need to be removed first in next commit.
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/mt9t112.c | 1163 +++
1 file changed, 1163 insertions(+)
create mode 100644 drivers/media/i2c/mt9t112.c
diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
new file mode 100644
index 000..297d22e
--- /dev/null
+++ b/drivers/media/i2c/mt9t112.c
@@ -0,0 +1,1163 @@
+/*
+ * mt9t112 Camera Driver
+ *
+ * Copyright (C) 2009 Renesas Solutions Corp.
+ * Kuninori Morimoto
+ *
+ * Based on ov772x driver, mt9m111 driver,
+ *
+ * Copyright (C) 2008 Kuninori Morimoto
+ * Copyright (C) 2008, Robert Jarzmik
+ * Copyright 2006-7 Jonathan Corbet
+ * Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008, Guennadi Liakhovetski
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+/* you can check PLL/clock info */
+/* #define EXT_CLOCK 2400 */
+
+/
+ macro
+/
+/*
+ * frame size
+ */
+#define MAX_WIDTH 2048
+#define MAX_HEIGHT 1536
+
+/*
+ * macro of read/write
+ */
+#define ECHECKER(ret, x) \
+ do {\
+ (ret) = (x);\
+ if ((ret) < 0) \
+ return (ret); \
+ } while (0)
+
+#define mt9t112_reg_write(ret, client, a, b) \
+ ECHECKER(ret, __mt9t112_reg_write(client, a, b))
+#define mt9t112_mcu_write(ret, client, a, b) \
+ ECHECKER(ret, __mt9t112_mcu_write(client, a, b))
+
+#define mt9t112_reg_mask_set(ret, client, a, b, c) \
+ ECHECKER(ret, __mt9t112_reg_mask_set(client, a, b, c))
+#define mt9t112_mcu_mask_set(ret, client, a, b, c) \
+ ECHECKER(ret, __mt9t112_mcu_mask_set(client, a, b, c))
+
+#define mt9t112_reg_read(ret, client, a) \
+ ECHECKER(ret, __mt9t112_reg_read(client, a))
+
+/*
+ * Logical address
+ */
+#define _VAR(id, offset, base) (base | (id & 0x1f) << 10 | (offset & 0x3ff))
+#define VAR(id, offset) _VAR(id, offset, 0x)
+#define VAR8(id, offset) _VAR(id, offset, 0x8000)
+
+/
+ struct
+/
+struct mt9t112_format {
+ u32 code;
+ enum v4l2_colorspace colorspace;
+ u16 fmt;
+ u16 order;
+};
+
+struct mt9t112_priv {
+ struct v4l2_subdev subdev;
+ struct mt9t112_camera_info *info;
+ struct i2c_client *client;
+ struct v4l2_rect frame;
+ struct v4l2_clk *clk;
+ const struct mt9t112_format *format;
+ int num_formats;
+ u32 flags;
+/* for flags */
+#define INIT_DONE (1 << 0)
+#define PCLK_RISING(1 << 1)
+};
+
+/
+ supported format
+/
+
+static const struct mt9t112_format mt9t112_cfmts[] = {
+ {
+ .code = MEDIA_BUS_FMT_UYVY8_2X8,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .fmt= 1,
+ .order = 0,
+ }, {
+ .code = MEDIA_BUS_FMT_VYUY8_2X8,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .fmt= 1,
+ .order = 1,
+ }, {
+ .code = MEDIA_BUS_FMT_YUYV8_2X8,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .fmt= 1,
+ .order = 2,
+ }, {
+ .code = MEDIA_BUS_FMT_YVYU8_2X8,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .fmt= 1,
+ .order = 3,
+ }, {
+ .code = MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .fmt= 8,
+ .order = 2,
+ }, {
+ .code = MEDIA_BUS_FMT_RGB565_2X8_LE,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .fmt= 4,
+
[PATCH v2 4/4] media: MAINTAINERS: Add entry for Aptina MT9T112
Add entry for Aptina/Micron MT9T112 camera sensor. The driver is maintained by me for "Odd Fixes" only due to lack of suitable hardware for testing. Signed-off-by: Jacopo Mondi --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 91ed6ad..ed95cad 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9385,6 +9385,14 @@ S: Maintained F: drivers/media/i2c/mt9t001.c F: include/media/i2c/mt9t001.h +MT9T112 APTINA CAMERA SENSOR +M: Jacopo Mondi +L: linux-me...@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Odd Fixes +F: drivers/media/i2c/mt9t112.c +F: include/media/i2c/mt9t112.h + MT9V032 APTINA CAMERA SENSOR M: Laurent Pinchart L: linux-me...@vger.kernel.org -- 2.7.4
[PATCH v2 0/4] Renesas CEU: SH7724 ECOVEC + Aptina mt9t112
Hello Hans, I have squashed in the two patches I sent on top of v1 in this series, one fix for the build error you reported me, and reduced the patch count fixing the style changes on the patch that removes the soc_camera dependencies. No frame rate control, but now a TODO note makes clear that is expected v4l2 compliance tool to report errors. v1 -> v2: - Fix soc_camera driver build error - Add TODO note for missing frame rate control - Reduce patch count Jacopo Mondi (4): media: i2c: Copy mt9t112 soc_camera sensor driver media: i2c: mt9t112: Remove soc_camera dependencies arch: sh: ecovec: Use new renesas-ceu camera driver media: MAINTAINERS: Add entry for Aptina MT9T112 MAINTAINERS|7 + arch/sh/boards/mach-ecovec24/setup.c | 338 +- arch/sh/kernel/cpu/sh4a/clock-sh7724.c |4 +- drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9t112.c| 1140 drivers/media/i2c/soc_camera/mt9t112.c |2 +- include/media/i2c/mt9t112.h| 17 +- 8 files changed, 1338 insertions(+), 182 deletions(-) create mode 100644 drivers/media/i2c/mt9t112.c -- 2.7.4
Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge
Hi Andrzej, thanks for the detailed reply, much appreciated :) On Mon, Mar 12, 2018 at 02:47:20PM +0100, Andrzej Hajda wrote: > On 12.03.2018 13:30, jacopo mondi wrote: > > Hi Andrzej, > > > > On Mon, Mar 12, 2018 at 10:07:27AM +0100, Andrzej Hajda wrote: > >> [snip] > > I understand. The "transparent bridge" is of no actual use, but I don't see > > how the "double bridge" thing is not an issue if I were to develop > > support for the actual Thine chip. > > What is exactly your configuration: single/dual input, single/dual output? > Current bindings suggests single/single, am I right? In such case you do > not need to implement dual link functionality in the driver - since you > even do not have possibility to test it. Correct, I'm running in single/single mode. > But the bindings should support all modes of operation, or at least > should be easy to extend them in the future with backward compatibility. > And here is where I always get lost. For sake of being compatible with future extensions, bindings shall describe hardware, not what is currently supported in driver. One day I'll get this right! > > > > Please see my reply from yesterday to Archit. I still think having two > > bridges is somehow an issue... > > Yes, I agree. But do we have such case? If no - no problem ATM :), if > yes - lets try to implement it and see where is the problem, as Archit > already suggested it would be just a matter of assigning bridge to port > node, instead of device node. > Again, I've been fooled by the idea that if bindings describe something, the driver should implement it (but I'm still not sure that "just assign the port node to the bridge" is the right thing to do here, but let's leave this out for now :) > > > > While we clarify that, would it be fine an initial driver version for > > the actualt Thine chip with a single input support[1]? I would ditch this > > transparent bridge and resume working on a THC63LVD1024 driver from > > comments received on v1. > > I think, yes: driver with only single input, and full or extend-able > bindings. > > > > > Thanks > > j > > > > [1] Single input support implies a single input port in DT bindings > > even if the chip supports two, and my understanding was that you > > didn't like this. > > I am sorry if I was not clear enough, only thing I wanted was complete > or at least consistent/extend-able binding. > So when I saw word "multiple LVDS streams" in bindings I was looking > further to see how these multiple LVDS bindings are defined, and found > nothing :) No worries, you're right here, again it's me confused by bindings description vs driver features... > Btw I think it may be better to use "Dual Link" instead of "Multiple > streams", it is more precise and quite well established in docs. Ack, I will follow up with a v3 where I'll get rid of generic LVDS decoder and target the actual chip. Thanks j > > Regards > Andrzej > > > > > > >> Regards > >> Andrzej > >> > >>> Jacopo Mondi (3): > >>> dt-bindings: display: bridge: Document LVDS to parallel decoder > >>> drm: bridge: Add LVDS decoder driver > >>> arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle > >>> > >>> .../bindings/display/bridge/lvds-decoder.txt | 42 ++ > >>> arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31 +++- > >>> drivers/gpu/drm/bridge/Kconfig | 8 ++ > >>> drivers/gpu/drm/bridge/Makefile| 1 + > >>> drivers/gpu/drm/bridge/lvds-decoder.c | 157 > >>> + > >>> 5 files changed, 237 insertions(+), 2 deletions(-) > >>> create mode 100644 > >>> Documentation/devicetree/bindings/display/bridge/lvds-decoder.txt > >>> create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c > >>> > >>> -- > >>> 2.7.4 > >>> > >>> > >>> > >>> > signature.asc Description: PGP signature
Re: [PATCH 5/5] media: MAINTAINERS: Add entry for Aptina MT9T112
Hi Sakari, On Sun, Mar 11, 2018 at 10:15:14PM +0200, Sakari Ailus wrote: > Hi Jacopo, > > On Fri, Mar 02, 2018 at 05:35:41PM +0100, Jacopo Mondi wrote: > > Add entry for Aptina/Micron MT9T112 camera sensor. The driver is > > currently orphaned. > > > > Signed-off-by: Jacopo Mondi > > --- > > MAINTAINERS | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 91ed6ad..1d8be25 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -9385,6 +9385,13 @@ S: Maintained > > F: drivers/media/i2c/mt9t001.c > > F: include/media/i2c/mt9t001.h > > > > +MT9T112 APTINA CAMERA SENSOR > > +L: linux-me...@vger.kernel.org > > +T: git git://linuxtv.org/media_tree.git > > +S: Orphan > > I don't like adding a driver which is in orphaned state to begin with. I don't as well :) > > Would you like to maintain it? :-) I would, but I currently have no camera module to test with... Maybe just for "Odd Fixes"? > > > +F: drivers/media/i2c/mt9t112.c > > +F: include/media/i2c/mt9t112.h > > + > > MT9V032 APTINA CAMERA SENSOR > > M: Laurent Pinchart > > L: linux-me...@vger.kernel.org > > -- > Regards, > > Sakari Ailus > e-mail: sakari.ai...@iki.fi
Re: [PATCH 09/11] media: vsp1: Provide support for extended command pools
Hi Kieran,
just one small thing I noticed below...
On Fri, Mar 09, 2018 at 10:04:07PM +, Kieran Bingham wrote:
> VSPD and VSP-DL devices can provide extended display lists supporting
> extended command display list objects.
>
> These extended commands require their own dma memory areas for a header
> and body specific to the command type.
>
> Implement a command pool to allocate all necessary memory in a single
> DMA allocation to reduce pressure on the TLB, and provide convenvient
> re-usable command objects for the entities to utilise.
>
> Signed-off-by: Kieran Bingham
> ---
> drivers/media/platform/vsp1/vsp1_dl.c | 189 +++-
> drivers/media/platform/vsp1/vsp1_dl.h | 3 +-
> 2 files changed, 192 insertions(+)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c
> index 36440a2a2c8b..6d17b8bfa21c 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -121,6 +121,30 @@ struct vsp1_dl_body_pool {
> };
>
> /**
> + * struct vsp1_cmd_pool - display list body pool
> + * @dma: DMA address of the entries
> + * @size: size of the full DMA memory pool in bytes
> + * @mem: CPU memory pointer for the pool
> + * @bodies: Array of DLB structures for the pool
> + * @free: List of free DLB entries
> + * @lock: Protects the pool and free list
> + * @vsp1: the VSP1 device
> + */
> +struct vsp1_dl_cmd_pool {
> + /* DMA allocation */
> + dma_addr_t dma;
> + size_t size;
> + void *mem;
> +
> + struct vsp1_dl_ext_cmd *cmds;
> + struct list_head free;
> +
> + spinlock_t lock;
> +
> + struct vsp1_device *vsp1;
> +};
> +
> +/**
> * struct vsp1_dl_list - Display list
> * @list: entry in the display list manager lists
> * @dlm: the display list manager
> @@ -176,6 +200,7 @@ struct vsp1_dl_manager {
> struct vsp1_dl_list *pending;
>
> struct vsp1_dl_body_pool *pool;
> + struct vsp1_dl_cmd_pool *autfld_cmds;
> };
>
> /*
> -
> @@ -339,6 +364,139 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32
> reg, u32 data)
> }
>
> /*
> -
> + * Display List Extended Command Management
> + */
> +
> +enum vsp1_extcmd_type {
> + VSP1_EXTCMD_AUTODISP,
> + VSP1_EXTCMD_AUTOFLD,
> +};
> +
> +struct vsp1_extended_command_info {
> + u16 opcode;
> + size_t body_size;
> +} vsp1_extended_commands[] = {
> + [VSP1_EXTCMD_AUTODISP] = { 0x02, 96 },
> + [VSP1_EXTCMD_AUTOFLD] = { 0x03, 160 },
> +};
How about making this one static and const, since it does not get
modified?
Thanks
j
signature.asc
Description: PGP signature
Re: [PATCH v8 13/13] [media] v4l: Document explicit synchronization behavior
Hi Gustavo, a very small comment below On Fri, Mar 09, 2018 at 02:49:20PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Add section to VIDIOC_QBUF and VIDIOC_QUERY_BUF about it > > v6: - Close some gaps in the docs (Hans) > > v5: > - Remove V4L2_CAP_ORDERED > - Add doc about V4L2_FMT_FLAG_UNORDERED > > v4: > - Document ordering behavior for in-fences > - Document V4L2_CAP_ORDERED capability > - Remove doc about OUT_FENCE event > - Document immediate return of out-fence in QBUF > > v3: > - make the out_fence refer to the current buffer (Hans) > - Note what happens when the IN_FENCE is not set (Hans) > > v2: > - mention that fences are files (Hans) > - rework for the new API > > Signed-off-by: Gustavo Padovan > --- > Documentation/media/uapi/v4l/vidioc-qbuf.rst | 55 > +++- > Documentation/media/uapi/v4l/vidioc-querybuf.rst | 12 -- > 2 files changed, 63 insertions(+), 4 deletions(-) > [snip] > +Note the the same `fence_fd` field is used for both sending the in-fence as > +input argument to receive the out-fence as a return argument. A buffer can > +have both in-fence ond out-fence. I feel like an "and" is missing here... the same `fence_fd` field is used for both sending the in-fence as input argument to receive the out-fence as a return argument the same `fence_fd` field is used for both sending the in-fence as input argument *and* to receive the out-fence as a return argument I'm not a native speaker so I might be wrong though. Thanks j signature.asc Description: PGP signature
Re: [v2,2/2] media: Add a driver for the ov7251 camera sensor
posure = v4l2_ctrl_new_std(>ctrls, _ctrl_ops, > + V4L2_CID_EXPOSURE, 1, 32, 1, 32); > + ov7251->gain = v4l2_ctrl_new_std(>ctrls, _ctrl_ops, > + V4L2_CID_GAIN, 16, 1023, 1, 16); > + v4l2_ctrl_new_std_menu_items(>ctrls, _ctrl_ops, > + V4L2_CID_TEST_PATTERN, > + ARRAY_SIZE(ov7251_test_pattern_menu) - 1, > + 0, 0, ov7251_test_pattern_menu); > + ov7251->pixel_clock = v4l2_ctrl_new_std(>ctrls, > +
Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Vladimir, On Tue, Mar 27, 2018 at 02:03:25PM +0300, Vladimir Zapolskiy wrote: > Hi Jacopo, > > On 03/27/2018 01:10 PM, jacopo mondi wrote: > > Hi Vladimir, > > > > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote: > >> Hi Jacopo, > >> > >> On 03/27/2018 11:57 AM, jacopo mondi wrote: > >>> Hi Vladimir, > >>> > >>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote: > >>>> Hi Sergei, > >>>> > >>>> On 03/27/2018 11:27 AM, Sergei Shtylyov wrote: > >>>>> Hello! > >>>>> > >>>>> On 3/27/2018 10:33 AM, jacopo mondi wrote: > >>>>> [...] > >>>>>>>>>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings. > >>>>>>>>>>> > >>>>>>>>>>> Signed-off-by: Jacopo Mondi > >>>>>>>>>>> Reviewed-by: Andrzej Hajda > >>>>>>>>>>> Reviewed-by: Niklas Söderlund > >>>>>>>>>>> > >>>>>>>>>>> --- > >>>>>>>>>>> .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 > >>>>>>>>>>> +++ > >>>>>>>>>>> 1 file changed, 66 insertions(+) > >>>>>>>>>>> create mode 100644 > >>>>>>>>>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>>>>>> > >>>>>>>>>>> diff --git > >>>>>>>>>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>>>>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>>>>>> new file mode 100644 > >>>>>>>>>>> index 000..8225c6a > >>>>>>>>>>> --- /dev/null > >>>>>>>>>>> +++ > >>>>>>>>>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt > >>>>>>>>>>> @@ -0,0 +1,66 @@ > >>>>>>>>>>> +Thine Electronics THC63LVD1024 LVDS decoder > >>>>>>>>>>> +--- > >>>>>>>>>>> + > >>>>>>>>>>> +The THC63LVD1024 is a dual link LVDS receiver designed to > >>>>>>>>>>> convert LVDS > >>>>>>>>>>> streams > >>>>>>>>>>> +to parallel data outputs. The chip supports single/dual > >>>>>>>>>>> input/output modes, > >>>>>>>>>>> +handling up to two two input LVDS stream and up to two digital > >>>>>>>>>>> CMOS/TTL > >>>>>>>>>>> outputs. > >>>>>>>>>>> + > >>>>>>>>>>> +Single or dual operation modes, output data mapping and DDR > >>>>>>>>>>> output modes > >>>>>>>>>>> are > >>>>>>>>>>> +configured through input signals and the chip does not expose > >>>>>>>>>>> any control > >>>>>>>>>>> bus. > >>>>>>>>>>> + > >>>>>>>>>>> +Required properties: > >>>>>>>>>>> +- compatible: Shall be "thine,thc63lvd1024" > >>>>>>>>>>> + > >>>>>>>>>>> +Optional properties: > >>>>>>>>>>> +- vcc-supply: Power supply for TTL output and digital circuitry > >>>>>>>>>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal > >>>>>>>>>>> +- lvcc-supply: Power supply for LVDS inputs > >>>>>>>>>>> +- pvcc-supply: Power supply for PLL circuitry > >>>>>>>>>> As explained in a comment to one of the previous versions of this > >>>>>>>>>> series, I'm > >>>>>>>>>> tempted to make vcc-supply mandatory and drop the three other
Re: [PATCH v3 6/8] DT: arm: Add Renesas RZ/N1 SoC base device tree file
Hi Michel
The subject of all your patches for arch/arm should start with:
ARM: dts:
A git log on that directory clearly shows that's the preferred one.
I would also say that you are missing a symbol definition in
arch/arm/mach-shmobile/Kconfig
(even if you got rid of any board file)
I would expect a symbol to select in menuconfig, with your
dependencies listed there (ie, the serial interface driver)
Something like this (I left the 'xx' out from the part name on purpose)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 280e731..9a519330 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -114,4 +114,8 @@ config ARCH_SH73A0
bool "SH-Mobile AG5 (R8A73A00)"
select ARCH_RMOBILE
select RENESAS_INTC_IRQPIN
+
+config ARCH_R9A06G0
+ bool "RZ/N1 (R9A06G0)"
+ select SERIAL_8250_DW
endif
But please wait for others (preferibly Geert or Simon) to confim this.
On Thu, Mar 29, 2018 at 08:47:02AM +0100, Michel Pollet wrote:
> This adds the Renesas RZ/N1 Family (Part #R9A06G0xx) SoC
> bare bone support.
>
> This currently only handles generic parts (gic, architected timer)
> and a UART.
> For simplicity sake, this also relies on the bootloader to set the
> pinctrl and clocks.
>
> Signed-off-by: Michel Pollet
> ---
> arch/arm/boot/dts/r9a06g0xx.dtsi | 96
>
> 1 file changed, 96 insertions(+)
> create mode 100644 arch/arm/boot/dts/r9a06g0xx.dtsi
>
> diff --git a/arch/arm/boot/dts/r9a06g0xx.dtsi
> b/arch/arm/boot/dts/r9a06g0xx.dtsi
> new file mode 100644
> index 000..c63
> --- /dev/null
> +++ b/arch/arm/boot/dts/r9a06g0xx.dtsi
> @@ -0,0 +1,96 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Base Device Tree Source for the Renesas RZ/N1 SoC Family of devices
> + *
> + * Copyright (C) 2018 Renesas Electronics Europe Limited
> + *
> + */
> +
> +#include
> +
> +/ {
> + compatible = "renesas,rzn1";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0>;
> + };
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <1>;
> + };
> + };
I see you don't like empy lines, that's fine, it is not a strict
requiremen afaik, but I find a few empty lines here and there more
redable, expecially if the file is going to grow, as it will be.
> + clocks {
> + /*
> + * this is fixed clock for now,
> + * until the clock driver is merged
> + */
> + clkuarts: clkuarts {
You can remove the node lable if it's the same as the node name afaik
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <47619047>;
> + };
> + };
Grouping clock nodes under a "clocks" one is now deprecated.
Please see, ie.
"ARM: dts: r7s72100: stop grouping clocks under a "clocks" subnode"
Thanks
j
> + arch-timer {
> + compatible = "arm,cortex-a7-timer",
> + "arm,armv7-timer";
> + interrupt-parent = <>;
> + arm,cpu-registers-not-fw-configured;
> + interrupts =
> + + IRQ_TYPE_LEVEL_LOW)>,
> + + IRQ_TYPE_LEVEL_LOW)>,
> + + IRQ_TYPE_LEVEL_LOW)>,
> + + IRQ_TYPE_LEVEL_LOW)>;
> + };
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-parent = <>;
> + ranges;
> +
> + gic: gic@44101000 {
> + compatible = "arm,cortex-a7-gic", "arm,gic-400";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + reg = <0x44101000 0x1000>, /* Distributer */
> + <0x44102000 0x2000>, /* CPU interface */
> + <0x44104000 0x2000>, /* Virt interface control */
> + <0x44106000 0x2000>; /* Virt CPU interface */
> + interrupts =
> + + IRQ_TYPE_LEVEL_HIGH)>;
> + };
> + sysctrl: sysctrl@4000c000 {
> + compatible = "renesas,rzn1-sysctrl", "syscon",
> + "simple-mfd";
> + reg = <0x4000c000 0x1000>;
> +
> + reboot {
> +
Re: [v2,2/2] media: Add a driver for the ov7251 camera sensor
Hi Todor, On Thu, Mar 29, 2018 at 10:50:10AM +0300, Todor Tomov wrote: > Hi Jacopo, > > > > > > With the above nits clarified, and as you addressed my v1 comments: > > > > Reviewed-by: Jacopo Mondi > > Would you like to see the corrections or I can add the tag before sending > them? > I don't have any more comment, feel free to add it :) Thanks j signature.asc Description: PGP signature
[PATCH 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Document Thine THC63LVD1024 LVDS decoder.
Signed-off-by: Jacopo Mondi
---
.../bindings/display/bridge/thine,thc63lvd1024.txt | 59 ++
1 file changed, 59 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..53b6453
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,59 @@
+THine Electronics THC63LVD1024 LVDS receiver
+
+
+The THC63LVD1024 is an LVDS receiver designed to convert multiple LVDS streams
+to digital CMOS/TTL parallel data.
+
+Required properties:
+- compatible: Shall be one of the following:
+ "thine,thc63lvd1024",
+ "lvds-decoder"
+
+Optional properties:
+- supply-vcc: Power supply for TTL output and digital circuitry
+- supply-cvcc: Power supply for TTL CLOCKOUT signal
+- supply-lvcc: Power supply for LVDS inputs
+- supply-pvcc: Power supply for PLL circuitry
+- pwnd-gpio: Power down GPIO signal. Active low.
+- oe-gpio: Output enable GPIO signal. Active high.
+
+The THC63LVD1024 has two video ports, whose connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+- Port@0: LVDS input port
+- Port@1: Digital CMOS/TTL parallel output
+
+Example:
+---
+
+ lvds_decoder: decoder-0 {
+ compatible = "thine,thc63lvd1024";
+
+ vcc-supply = <_lvds_vcc>;
+ lvcc-supply = <_lvds_lvcc>;
+
+ pwdn-gpio = < 15 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1{
+ reg = <1>;
+
+ lvds_dec_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+
+ };
+
+ };
+ };
--
2.7.4
[PATCH 2/3] drm: bridge: Add LVDS decoder driver
Add transparent LVDS decoder driver.
A transparent LVDS decoder is a DRM bridge device that does not require
any configuration and converts LVDS input to digital CMOS/TTL parallel
data output. The driver is compatible with Thine THC63LVD1024 device
that can control a few power supplies and a few enable GPIOs.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/bridge/Kconfig| 8 ++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/lvds-decoder.c | 239 ++
3 files changed, 248 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a..e52a5af 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -32,6 +32,14 @@ config DRM_DUMB_VGA_DAC
help
Support for RGB to VGA DAC based bridges
+config DRM_LVDS_DECODER
+ tristate "Transparent LVDS to parallel decoder support"
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ help
+ Support for transparent LVDS to parallel decoders that don't require
+ any configuration.
+
config DRM_LVDS_ENCODER
tristate "Transparent parallel to LVDS encoder support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..edc2332 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
+obj-$(CONFIG_DRM_LVDS_DECODER) += lvds-decoder.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lvds-decoder.c
b/drivers/gpu/drm/bridge/lvds-decoder.c
new file mode 100644
index 000..3aada7e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lvds-decoder.c
@@ -0,0 +1,239 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+struct lvds_decoder {
+ struct device *dev;
+
+ struct regulator *vccs[4];
+
+ struct gpio_desc *pwdn;
+ struct gpio_desc *oe;
+
+ struct drm_bridge bridge;
+ struct drm_bridge *next;
+ struct drm_encoder *bridge_encoder;
+};
+
+static inline struct lvds_decoder *to_lvds_decoder(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct lvds_decoder, bridge);
+}
+
+static int lvds_decoder_attach(struct drm_bridge *bridge)
+{
+ struct lvds_decoder *lvds = to_lvds_decoder(bridge);
+
+ return drm_bridge_attach(bridge->encoder, lvds->next, bridge);
+}
+
+static void lvds_decoder_enable(struct drm_bridge *bridge)
+{
+ struct lvds_decoder *lvds = to_lvds_decoder(bridge);
+ struct regulator *vcc;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(lvds->vccs); i++) {
+ vcc = lvds->vccs[i];
+ if (vcc) {
+ ret = regulator_enable(vcc);
+ if (ret)
+ goto error_vcc_enable;
+ }
+ }
+
+ if (lvds->pwdn)
+ gpiod_set_value(lvds->pwdn, 0);
+
+ if (lvds->oe)
+ gpiod_set_value(lvds->oe, 1);
+
+ return;
+
+error_vcc_enable:
+ dev_err(lvds->dev, "Failed to enable regulator %u\n", i);
+}
+
+static void lvds_decoder_disable(struct drm_bridge *bridge)
+{
+ struct lvds_decoder *lvds = to_lvds_decoder(bridge);
+ struct regulator *vcc;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < ARRAY_SIZE(lvds->vccs); i++) {
+ vcc = lvds->vccs[i];
+ if (vcc) {
+ ret = regulator_disable(vcc);
+ if (ret)
+ goto error_vcc_disable;
+ }
+ }
+
+ if (lvds->pwdn)
+ gpiod_set_value(lvds->pwdn, 1);
+
+ if (lvds->oe)
+ gpiod_set_value(lvds->oe, 0);
+
+ return;
+
+error_vcc_disable:
+ dev_err(lvds->dev, "Failed to enable regulator %u\n", i);
+}
+
+struct drm_bridge_funcs lvds_dec_bridge_func = {
+ .attach = lvds_decoder_attach,
+ .enable = lvds_decoder_enable,
+ .disable = lvds_decoder_disable,
+};
+
+static int lvds_decoder_parse_dt(struct lvds_decoder *lvds)
+{
+ struct device_node *lvds_output;
+ struct device_node *remote;
+ int ret = 0;
+
+ lvds_output = of_graph_get_endpoint_by_regs(lvds->dev->of_node, 1, -1);
+ if (!lvds_output) {
+ dev_err(lvds->dev, "Missing endpoint
[PATCH 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
The R-Car V3M Eagle board includes a transparent LVDS decoder, connected
to the on-chip LVDS encoder output on one side and to HDMI encoder
ADV7511w on the other one.
As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver for transparent LVDS decoder is
available, describe it in DT as well.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31 --
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index c0fd144..0d62b40 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -42,6 +42,33 @@
};
};
};
+
+ lvds_decoder {
+ compatible = "thine,thc63lvd1024";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1{
+ reg = <1>;
+
+ lvds_dec_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+
+ };
+
+ };
+ };
};
{
@@ -98,7 +125,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
- remote-endpoint = <_out>;
+ remote-endpoint = <_dec_out>;
};
};
@@ -153,7 +180,7 @@
ports {
port@1 {
endpoint {
- remote-endpoint = <_in>;
+ remote-endpoint = <_dec_in>;
};
};
};
--
2.7.4
[PATCH 0/3] drm: Add LVDS decoder bridge
Hello, this small series add a driver for transparent LVDS decoders, as Thine THC63LVD1024 device. The R-Car Gen3 V3M Eagle board feature such a converter, that has been so far not described as part of the display output pipeline. Now that a driver has been added, the Eagle DTS file has been updated to include the transparent decoder chip. So far so good, but currently the current DRM Bridge API do not provide support to query a mode from another bridge as it is possible to do on panel devices. In our case the LVDS decoder is connected to the output of R-Car DU lvds encoder (drivers/gpu/drm/rcar-du/rcar_lvds.c). As its 'mode_set' function shows, LVDS modes cannot be propagated from bridge to another bridge, but are instead inferred from the bus_format field of the panel's connector. It is my intention to propose an API extension to allow formats to be propagated through bridges, but knowing the DRM/KMS subsystem very superficially I would appreciate any pointer from more experienced developers. For Renesas side: The series is based on Laurent's drm/next/du branch with patches on top for: - Sergei: Enable PFC, I2c, GPIOs for r8a77970 - Sergei: Add support for r8a77970 in DU and add display device nodes in r8a77970 DTSI - Niklas: Connect DU LVDS output to HDMI bridge adv7511w in Eagle DTS - Sergei: fix video output on R8A77970 A base branch with these patches applied is available at git://jmondi.org/linux v3m/v4.16-rc3/base Tested on Eagle board, making sure DU probes and testing all available output modes (of which only a few are actually working, I suspect due to faulty mode propagation through DRM bridges). Thanks j Jacopo Mondi (3): dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder drm: bridge: Add LVDS decoder driver arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle .../bindings/display/bridge/thine,thc63lvd1024.txt | 59 + arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31 ++- drivers/gpu/drm/bridge/Kconfig | 8 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/lvds-decoder.c | 239 + 5 files changed, 336 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c -- 2.7.4
Re: [PATCH 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Andrzej,
On Fri, Mar 09, 2018 at 09:01:24AM +0100, Andrzej Hajda wrote:
> On 08.03.2018 16:24, Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > .../bindings/display/bridge/thine,thc63lvd1024.txt | 59
> > ++
> > 1 file changed, 59 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..53b6453
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,59 @@
> > +THine Electronics THC63LVD1024 LVDS receiver
> > +
> > +
> > +The THC63LVD1024 is an LVDS receiver designed to convert multiple LVDS
> > streams
> > +to digital CMOS/TTL parallel data.
>
>You say multiple streams, but bindings describe only one stream.
I'm always confused by the fact that "bindings should describe
hardware" even when the driver does not support some features the
hardware provides.
In this case, the driver and its bindigns does not expose "MODE1/2"
pins that are used to control single/double stream mode, assuming they
are hard-wired and single/double stream mode is not controllable by
the SoC.
I should have reserved two more ports for one (optional) additional input and
one (optional) additional output, as chip can be configured to work in
that mode even if MODE1/2 are not hardwired.
Will add them in v2.
> > +
> > +Required properties:
> > +- compatible: Shall be one of the following:
> > + "thine,thc63lvd1024",
> > + "lvds-decoder"
> > +
> > +Optional properties:
> > +- supply-vcc: Power supply for TTL output and digital circuitry
> > +- supply-cvcc: Power supply for TTL CLOCKOUT signal
> > +- supply-lvcc: Power supply for LVDS inputs
> > +- supply-pvcc: Power supply for PLL circuitry
> > +- pwnd-gpio: Power down GPIO signal. Active low.
>
> Specs [1] uses "/PDWN" name for the pin, moreover gpios suffix is preferred.
>
> Another issue I see is two possibly contradicting conventions:
> 1. Properties should be named according to specs - so here it should be
> named pdwn-gpios.
> 2. The bindings tries to be generic for lvds decoders, in such case
> probably preferred name should be more generic, maybe power-gpios.
>
> Personally I would prefer 1, in such case generic lvds-decoder driver
> should look for gpio names according to compatible string.
>
I will go for 1 and associate the power control gpio name to the
matched compatible string.
"thine,thc63lvd1024" will look for "pwnd-gpios"
"lvds,decoder" will look for "power-gpios"
> [1]: http://www.thine.co.jp/files/topics/179_ext_12_0.pdf
>
> > +- oe-gpio: Output enable GPIO signal. Active high.
>
> oe-gpios
>
> > +
> > +The THC63LVD1024 has two video ports, whose connections are modeled
> > according
> > +to OF graph bindings specified by
> > Documentation/devicetree/bindings/graph.txt
> > +
> > +- Port@0: LVDS input port
> > +- Port@1: Digital CMOS/TTL parallel output
>
> According to specs it has two lvds input and two parallel output ports,
> maybe it would be good to describe all here.
I will in v2.
Thanks
j
>
> Regards
> Andrzej
>
> > +
> > +Example:
> > +---
> > +
> > + lvds_decoder: decoder-0 {
> > + compatible = "thine,thc63lvd1024";
> > +
> > + vcc-supply = <_lvds_vcc>;
> > + lvcc-supply = <_lvds_lvcc>;
> > +
> > + pwdn-gpio = < 15 GPIO_ACTIVE_LOW>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + lvds_dec_in: endpoint {
> > + remote-endpoint = <_out>;
> > + };
> > + };
> > +
> > + port@1{
> > + reg = <1>;
> > +
> > + lvds_dec_out: endpoint {
> > + remote-endpoint = <_in>;
> > + };
> > +
> > + };
> > +
> > + };
> > + };
>
>
Re: [PATCH 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Geert,
thanks for review
On Fri, Mar 09, 2018 at 09:10:55AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Mar 8, 2018 at 4:24 PM, Jacopo Mondi
> wrote:
> > Document Thine THC63LVD1024 LVDS decoder.
> >
> > Signed-off-by: Jacopo Mondi
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,59 @@
> > +THine Electronics THC63LVD1024 LVDS receiver
>
> Thine
>
> > +
> > +
> > +The THC63LVD1024 is an LVDS receiver designed to convert multiple LVDS
> > streams
> > +to digital CMOS/TTL parallel data.
> > +
> > +Required properties:
> > +- compatible: Shall be one of the following:
> > + "thine,thc63lvd1024",
> > + "lvds-decoder"
>
> What's the purpose of the second compatible value?
> When should it be used?
It is probably my bad having started with a generic LVDS decoder in
mind and having then added properties specific to THC63LVD1024 to the
driver and its bindings.
"lvds,decoder" can be used when the chip is completely transparent to
the SoC and none of the optional properties I have described in the
bindings are specified (a generic "power-gpios" apart, see Andrzej
comments on "pwdn-gpios" property).
Also, I should make the driver behavior depend on the matched compatible
string. When "lvds-decoder" is matched, it will just look for an
optional power down gpio, when "thc63lvd1024" is matched, all of its
Vcc supplies, pwdn gpio and oe gpios will be queried and, if present,
eventually used in enable/disable routines.
I'm just not sure how to describe that in bindings. Would something
like the following work?
Optional properties for "lvds,decoder"
- power-gpios: Power control GPIOs
Optional properties for "thine,thc63lvd1024"
- pwdn-gpios: ...
- oe-gpios: ...
- supply-vcc: ...
- supply-cvcc: ...
- supply-pvcc: ...
- supply-lvcc: ...
Thanks
j
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Hi Geert,
On Fri, Mar 09, 2018 at 10:22:39AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Fri, Mar 9, 2018 at 10:04 AM, jacopo mondi wrote:
> > On Fri, Mar 09, 2018 at 09:10:55AM +0100, Geert Uytterhoeven wrote:
> >> On Thu, Mar 8, 2018 at 4:24 PM, Jacopo Mondi
> >> wrote:
> >> > Document Thine THC63LVD1024 LVDS decoder.
> >> >
> >> > Signed-off-by: Jacopo Mondi
> >>
> >> Thanks for your patch!
> >>
> >> > --- /dev/null
> >> > +++
> >> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >> > @@ -0,0 +1,59 @@
> >> > +THine Electronics THC63LVD1024 LVDS receiver
> >>
> >> Thine
> >>
> >> > +
> >> > +
> >> > +The THC63LVD1024 is an LVDS receiver designed to convert multiple LVDS
> >> > streams
> >> > +to digital CMOS/TTL parallel data.
> >> > +
> >> > +Required properties:
> >> > +- compatible: Shall be one of the following:
> >> > + "thine,thc63lvd1024",
> >> > + "lvds-decoder"
> >>
> >> What's the purpose of the second compatible value?
> >> When should it be used?
> >
> > It is probably my bad having started with a generic LVDS decoder in
> > mind and having then added properties specific to THC63LVD1024 to the
> > driver and its bindings.
> >
> > "lvds,decoder" can be used when the chip is completely transparent to
> > the SoC and none of the optional properties I have described in the
> > bindings are specified (a generic "power-gpios" apart, see Andrzej
> > comments on "pwdn-gpios" property).
> >
> > Also, I should make the driver behavior depend on the matched compatible
> > string. When "lvds-decoder" is matched, it will just look for an
> > optional power down gpio, when "thc63lvd1024" is matched, all of its
> > Vcc supplies, pwdn gpio and oe gpios will be queried and, if present,
> > eventually used in enable/disable routines.
> >
> > I'm just not sure how to describe that in bindings. Would something
> > like the following work?
> >
> > Optional properties for "lvds,decoder"
>
> "lvds-decoder"?
>
Yes, sorry
> > - power-gpios: Power control GPIOs
> >
> > Optional properties for "thine,thc63lvd1024"
> > - pwdn-gpios: ...
> > - oe-gpios: ...
> > - supply-vcc: ...
> > - supply-cvcc: ...
> > - supply-pvcc: ...
> > - supply-lvcc: ...
>
> Sounds like you need a (separate) generic lvds-decoder DT bindings document,
> which you can extend/refer to from the THC63LVD1024-specific bindings.
Ok, I'll go with two bindings document then and see how it looks.
Thanks
j
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
[PATCH v2 0/3] drm: Add LVDS decoder bridge
Hello, after some discussion on the proposed bindings for generic lvds decoder and Thine THC63LVD1024, I decided to drop the THC63 specific part and just live with a transparent decoder that does not support any configuration from DT. Dropping THC63 support to avoid discussion on how to better implement support for a DRM bridge with 2 input ports and focus on LVDS mode propagation through bridges as explained in v1 cover letter (for DRM people: please see [1] as why I find difficult to implement support for bridges with multiple input endpoints) Same base branch as v1, with same patches for V3M Eagle applied on top. git://jmondi.org/linux v3m/v4.16-rc3/base Thanks j v1 -> v2: - Drop support for THC63LVD1024 [1] I had a quick at how to model a DRM bridge with multiple input ports, and I see a blocker in how DRM identifies and matches bridges using the devices node in place of the endpoint nodes. As THC63LVD1024 supports up to 2 LVDS inputs and 2 LVDS outputs, I see only a few ways to support that: 1) register 2 drm bridges from the same driver (one for each input/output pair) but they would both be matches on the same device node when the preceding bridge calls "of_drm_find_bridge()". 2) register a single bridge with multiple "next bridges", but when the bridge gets attached I don't see a way on how to identify on which next bridge "drm_bridge_attach()" on, as it depends on the endpoint the current bridge has been attached on first, and we don't have that information. 3) Register more instances of the same chip in DTS, one for each input/output pair. They gonna share supplies and gpios, and I don't like that. I had a quick look at the currently in mainline bridges and none of them has multiple input endpoints, except for HDMI audio endpoint, which I haven't found in use in any DTS. I guess the problem has been already debated and maybe solved in the past, so feel free to point me to other sources. Jacopo Mondi (3): dt-bindings: display: bridge: Document LVDS to parallel decoder drm: bridge: Add LVDS decoder driver arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle .../bindings/display/bridge/lvds-decoder.txt | 42 ++ arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31 +++- drivers/gpu/drm/bridge/Kconfig | 8 ++ drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/lvds-decoder.c | 157 + 5 files changed, 237 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-decoder.txt create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c -- 2.7.4
[PATCH v2 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
The R-Car V3M Eagle board includes a transparent LVDS decoder, connected
to the on-chip LVDS encoder output on one side and to HDMI encoder
ADV7511w on the other one.
As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver for transparent LVDS decoder is
available, describe it in DT as well.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31 --
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index c0fd144..0a95c20 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -42,6 +42,33 @@
};
};
};
+
+ lvds,decoder {
+ compatible = "lvds-decoder";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1{
+ reg = <1>;
+
+ lvds_dec_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+
+ };
+
+ };
+ };
};
{
@@ -98,7 +125,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
- remote-endpoint = <_out>;
+ remote-endpoint = <_dec_out>;
};
};
@@ -153,7 +180,7 @@
ports {
port@1 {
endpoint {
- remote-endpoint = <_in>;
+ remote-endpoint = <_dec_in>;
};
};
};
--
2.7.4
[PATCH v2 2/3] drm: bridge: Add LVDS decoder driver
Add transparent LVDS decoder driver.
A transparent LVDS decoder is a DRM bridge device that does not require
any configuration and converts LVDS input to digital CMOS/TTL parallel
data output.
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/bridge/Kconfig| 8 +++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/lvds-decoder.c | 129 ++
3 files changed, 138 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a..e52a5af 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -32,6 +32,14 @@ config DRM_DUMB_VGA_DAC
help
Support for RGB to VGA DAC based bridges
+config DRM_LVDS_DECODER
+ tristate "Transparent LVDS to parallel decoder support"
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ help
+ Support for transparent LVDS to parallel decoders that don't require
+ any configuration.
+
config DRM_LVDS_ENCODER
tristate "Transparent parallel to LVDS encoder support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..edc2332 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
+obj-$(CONFIG_DRM_LVDS_DECODER) += lvds-decoder.o
obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lvds-decoder.c
b/drivers/gpu/drm/bridge/lvds-decoder.c
new file mode 100644
index 000..319f4d5
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lvds-decoder.c
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+
+#include
+
+struct lvds_decoder {
+ struct device *dev;
+
+ struct drm_bridge bridge;
+ struct drm_bridge *next;
+ struct drm_encoder *bridge_encoder;
+};
+
+static inline struct lvds_decoder *to_lvds_decoder(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct lvds_decoder, bridge);
+}
+
+static int lvds_decoder_attach(struct drm_bridge *bridge)
+{
+ struct lvds_decoder *lvds = to_lvds_decoder(bridge);
+
+ return drm_bridge_attach(bridge->encoder, lvds->next, bridge);
+}
+
+struct drm_bridge_funcs lvds_dec_bridge_func = {
+ .attach = lvds_decoder_attach,
+};
+
+static int lvds_decoder_parse_dt(struct lvds_decoder *lvds)
+{
+ struct device_node *lvds_output;
+ struct device_node *remote;
+ int ret = 0;
+
+ lvds_output = of_graph_get_endpoint_by_regs(lvds->dev->of_node, 1, -1);
+ if (!lvds_output) {
+ dev_err(lvds->dev, "Missing endpoint in Port@1\n");
+ return -ENODEV;
+ }
+
+ remote = of_graph_get_remote_port_parent(lvds_output);
+ if (!remote) {
+ dev_err(lvds->dev, "Endpoint in Port@1 unconnected\n");
+ ret = -ENODEV;
+ goto error_put_lvds_node;
+ }
+
+ if (!of_device_is_available(remote)) {
+ dev_err(lvds->dev, "Port@1 remote endpoint is disabled\n");
+ ret = -ENODEV;
+ goto error_put_remote_node;
+ }
+
+ lvds->next = of_drm_find_bridge(remote);
+ if (!lvds->next)
+ ret = -EPROBE_DEFER;
+
+error_put_remote_node:
+ of_node_put(remote);
+error_put_lvds_node:
+ of_node_put(lvds_output);
+
+ return ret;
+}
+
+static int lvds_decoder_probe(struct platform_device *pdev)
+{
+ struct lvds_decoder *lvds;
+ int ret;
+
+ lvds = devm_kzalloc(>dev, sizeof(*lvds), GFP_KERNEL);
+ if (!lvds)
+ return -ENOMEM;
+
+ lvds->dev = >dev;
+ platform_set_drvdata(pdev, lvds);
+
+ ret = lvds_decoder_parse_dt(lvds);
+ if (ret)
+ return ret;
+
+ lvds->bridge.driver_private = lvds;
+ lvds->bridge.of_node = pdev->dev.of_node;
+ lvds->bridge.funcs = _dec_bridge_func;
+
+ drm_bridge_add(>bridge);
+
+ return 0;
+}
+
+static int lvds_decoder_remove(struct platform_device *pdev)
+{
+ struct lvds_decoder *lvds = platform_get_drvdata(pdev);
+
+ drm_bridge_remove(>bridge);
+
+ return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id lvds_decoder_match[] = {
+ { .compatible = "lvds-decoder", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, lvds_decoder_match);
+#endif
+
+static struct platform_driver lvds_decoder_driver = {
+
[PATCH v2 1/3] dt-bindings: display: bridge: Document LVDS to parallel decoder
Document transparent LVDS to CMOS/TTL decoder that do not require any
configuration.
Signed-off-by: Jacopo Mondi
---
.../bindings/display/bridge/lvds-decoder.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-decoder.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-decoder.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-decoder.txt
new file mode 100644
index 000..a9b1d9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-decoder.txt
@@ -0,0 +1,42 @@
+LVDS to Parallel CMOS/TTL decoder
+-
+
+Bindings for transparent LVDS to CMOS/TTL parallel data decoder that don't
+require any configuration.
+
+Required properties:
+- compatible: shall be "lvds-decoder"
+
+The LVDS decoder has two video ports, whose connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+- Port@0: LVDS input port
+- Port@1: Digital CMOS/TTL parallel output
+
+Example:
+---
+
+ lvds,decoder: decoder-0 {
+ compatible = "lvds-decoder";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1{
+ reg = <1>;
+
+ lvds_dec_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+ };
--
2.7.4
Re: [PATCH v2 1/4] media: i2c: Copy mt9t112 soc_camera sensor driver
Hi Sakari,
thanks for looking into this!
On Thu, Mar 15, 2018 at 01:35:34PM +0200, Sakari Ailus wrote:
> Hi Jacopo,
>
> I wonder if it'd make sense to just make all the changes to the driver and
> then have it reviewed; I'm not sure the old driver can be said to have been
> in a known-good state that'd be useful to compare against. I think you did
> that with another driver as well.
>
Well, I understand this is still debated, and I see your point.
As far as I can tell the driver had been developed to work with SH4
Ecovec boards and there tested.
I'm not sure I fully got you here though. Are you proposing to
squash my next patch that cleans up the driver into this one and
propose it as a completely new driver to be reviewed from scratch?
In the two previous driver I touched in this "remove soc_camera"
journey (ov772x and tw9910) I have followed this same pattern: copy
the soc_camera driver without removing the existing one, and pile on
top my changes/cleanups in another patch. Then port the board code to
use the new sensor driver, and the new CEU driver as well.
Also, how would you like to proceed here? Hans sent a pull request for
the series, should I go with incremental changes on top of this?
> On Mon, Mar 12, 2018 at 02:43:02PM +0100, Jacopo Mondi wrote:
> > Copy the soc_camera based driver in v4l2 sensor driver directory.
> > This commit just copies the original file without modifying it.
> > No modification to KConfig and Makefile as soc_camera framework
> > dependencies need to be removed first in next commit.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/media/i2c/mt9t112.c | 1163
> > +++
> > 1 file changed, 1163 insertions(+)
> > create mode 100644 drivers/media/i2c/mt9t112.c
> >
> > diff --git a/drivers/media/i2c/mt9t112.c b/drivers/media/i2c/mt9t112.c
> > new file mode 100644
> > index 000..297d22e
> > --- /dev/null
> > +++ b/drivers/media/i2c/mt9t112.c
> > @@ -0,0 +1,1163 @@
> > +/*
> > + * mt9t112 Camera Driver
> > + *
> > + * Copyright (C) 2009 Renesas Solutions Corp.
> > + * Kuninori Morimoto
> > + *
> > + * Based on ov772x driver, mt9m111 driver,
> > + *
> > + * Copyright (C) 2008 Kuninori Morimoto
> > + * Copyright (C) 2008, Robert Jarzmik
> > + * Copyright 2006-7 Jonathan Corbet
> > + * Copyright (C) 2008 Magnus Damm
> > + * Copyright (C) 2008, Guennadi Liakhovetski
> > + *
> > + * 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.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* you can check PLL/clock info */
> > +/* #define EXT_CLOCK 2400 */
> > +
> > +/
> > + macro
> > +/
> > +/*
> > + * frame size
> > + */
> > +#define MAX_WIDTH 2048
> > +#define MAX_HEIGHT 1536
> > +
> > +/*
> > + * macro of read/write
> > + */
> > +#define ECHECKER(ret, x) \
> > + do {\
> > + (ret) = (x);\
> > + if ((ret) < 0) \
> > + return (ret); \
>
> I think the code would be easier to follow without macros like this one.
>
Yes, I agree, but again, not my code and already in mainline, so I
felt uncomfortable chopping away pieces with an axe just because "I didn't
like it". But if we're going for a major review I can be a bit more
aggressive and address your comments.
> > + } while (0)
> > +
> > +#define mt9t112_reg_write(ret, client, a, b) \
> > + ECHECKER(ret, __mt9t112_reg_write(client, a, b))
> > +#define mt9t112_mcu_write(ret, client, a, b) \
> > + ECHECKER(ret, __mt9t112_mcu_write(client, a, b))
> > +
> > +#define mt9t112_reg_mask_set(ret, client, a, b, c) \
> > + ECHECKER(ret, __mt9t112_reg_mask_set(client, a, b, c))
> > +#define mt9t112_mcu_mask_set(ret, client, a, b, c) \
> > + ECHECKER(ret, __mt9t112_mcu_mask_set(client, a, b, c))
> > +
> > +#define mt9t112_reg_read(ret, client, a) \
> > + ECHECKER(ret, __mt9t112_reg_read(client, a))
> > +
> > +/*
> > + * Logical address
Re: [PATCH v4 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Hi Andrzej,
thanks for your patience in reviewing this series
On Thu, Mar 15, 2018 at 02:37:00PM +0100, Andrzej Hajda wrote:
> On 15.03.2018 11:56, Jacopo Mondi wrote:
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output converter.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/bridge/Kconfig| 6 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/thc63lvd1024.c | 255
> > ++
> > 3 files changed, 262 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3b99d5a..5815a20 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -92,6 +92,12 @@ config DRM_SII9234
> > It is an I2C driver, that detects connection of MHL bridge
> > and starts encapsulation of HDMI signal.
> >
> > +config DRM_THINE_THC63LVD1024
> > + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> > + depends on OF
> > + ---help---
> > + Thine THC63LVD1024 LVDS/parallel converter driver.
> > +
> > config DRM_TOSHIBA_TC358767
> > tristate "Toshiba TC358767 eDP bridge"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 373eb28..fd90b16 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> > obj-$(CONFIG_DRM_SII902X) += sii902x.o
> > obj-$(CONFIG_DRM_SII9234) += sii9234.o
> > +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> > obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > new file mode 100644
> > index 000..067f231
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -0,0 +1,255 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> > + *
> > + * Copyright (C) 2018 Jacopo Mondi
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +enum {
> > + THC63_LVDS_IN0,
> > + THC63_LVDS_IN1,
> > + THC63_DIGITAL_OUT0,
> > + THC63_DIGITAL_OUT1,
> > +};
> > +
> > +static const char * const thc63_reg_names[] = {
> > + "vcc", "lvcc", "pvcc", "cvcc",
> > +};
> > +
> > +struct thc63_dev {
> > + struct device *dev;
> > +
> > + struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
> > +
> > + struct gpio_desc *pdwn;
> > + struct gpio_desc *oe;
> > +
> > + struct drm_bridge bridge;
> > + struct drm_bridge *next;
> > +};
> > +
> > +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> > +{
> > + return container_of(bridge, struct thc63_dev, bridge);
> > +}
> > +
> > +static int thc63_attach(struct drm_bridge *bridge)
> > +{
> > + struct thc63_dev *thc63 = to_thc63(bridge);
> > +
> > + return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> > +}
> > +
> > +static void thc63_enable(struct drm_bridge *bridge)
> > +{
> > + struct thc63_dev *thc63 = to_thc63(bridge);
> > + struct regulator *vcc;
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> > + vcc = thc63->vccs[i];
> > + if (!vcc)
> > + continue;
> > +
> > + if (regulator_enable(vcc))
> > + goto error_vcc_enable;
> > + }
> > +
> > + if (thc63->pdwn)
> > + gpiod_set_value(thc63->pdwn, 0);
> > +
> > + if (thc63->oe)
> > + gpiod_set_value(thc63->oe, 1);
> > +
> > + return;
> > +
> > +error_vcc_enable:
> > + dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
>
> It would be better to use supply or regulator name instead of index.
>
Yeah, now it's easy as I have the array with names in the driver
g
[PATCH v5 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge
Hi, v5 with a few small changes compared to v4 and with Andrzej tag added to all patches in the series. I fixed punctuation in the bindings and added a statement to clarify the chip does not expose any control bus but it is instead configured by input signals. Minor changes in the driver, with the regulator name printed out in error path of enable/disable routines instead of its index. Branch for testing available at git://jmondi.org v3m/v4.16-rc3/lvds-bridge-v5 Thanks j v4 -> v5: - Fix punctuation in bindings documentation - Add small statement to bindings document to clarify the chip has no control bus - Print regulator name in enable/disable routines error path - Add Andrzej Reviewed-by tag v3 -> v4: - Rename permutations of "pdwn" to just "pdwn" everywhere in the series - Improve power enable/disable routines as suggested by Andrzej and Sergei - Change "pdwn" gpio initialization to use the logical output level - Change Kconfig description v2 -> v3: - Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific -- Rework bindings to describe multiple input/output ports -- Rename driver and remove "lvds-decoder" references -- Rework Eagle DTS to use new bindings v1 -> v2: - Drop support for THC63LVD1024 Jacopo Mondi (3): dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder drm: bridge: Add thc63lvd1024 LVDS decoder driver arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 ++ arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 ++- drivers/gpu/drm/bridge/Kconfig | 6 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/thc63lvd1024.c | 257 + 5 files changed, 360 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c -- 2.7.4
[PATCH v5 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Document Thine THC63LVD1024 LVDS decoder device tree bindings.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
---
.../bindings/display/bridge/thine,thc63lvd1024.txt | 66 ++
1 file changed, 66 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..8225c6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,66 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL
outputs.
+
+Single or dual operation modes, output data mapping and DDR output modes are
+configured through input signals and the chip does not expose any control bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry
+- pdwn-gpios: Power down GPIO signal. Active low
+- oe-gpios: Output enable GPIO signal. Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- Port@0: First LVDS input port
+- Port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- Port@1: Second LVDS input port
+- Port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+ thc63lvd1024: lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+
+ vcc-supply = <_lvds_vcc>;
+ lvcc-supply = <_lvds_lvcc>;
+
+ pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@2{
+ reg = <2>;
+
+ lvds_dec_out_2: endpoint {
+ remote-endpoint = <_in>;
+ };
+
+ };
+
+ };
+ };
--
2.7.4
[PATCH v5 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/Kconfig| 6 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/thc63lvd1024.c | 257 ++
3 files changed, 264 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a..5815a20 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -92,6 +92,12 @@ config DRM_SII9234
It is an I2C driver, that detects connection of MHL bridge
and starts encapsulation of HDMI signal.
+config DRM_THINE_THC63LVD1024
+ tristate "Thine THC63LVD1024 LVDS decoder bridge"
+ depends on OF
+ ---help---
+ Thine THC63LVD1024 LVDS/parallel converter driver.
+
config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..fd90b16 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_SII9234) += sii9234.o
+obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
new file mode 100644
index 000..36069a0
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * THC63LVD1024 LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+enum {
+ THC63_LVDS_IN0,
+ THC63_LVDS_IN1,
+ THC63_DIGITAL_OUT0,
+ THC63_DIGITAL_OUT1,
+};
+
+static const char * const thc63_reg_names[] = {
+ "vcc", "lvcc", "pvcc", "cvcc",
+};
+
+struct thc63_dev {
+ struct device *dev;
+
+ struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
+
+ struct gpio_desc *pdwn;
+ struct gpio_desc *oe;
+
+ struct drm_bridge bridge;
+ struct drm_bridge *next;
+};
+
+static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct thc63_dev, bridge);
+}
+
+static int thc63_attach(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+
+ return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
+}
+
+static void thc63_enable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ struct regulator *vcc;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ if (regulator_enable(vcc))
+ goto error_vcc_enable;
+ }
+
+ if (thc63->pdwn)
+ gpiod_set_value(thc63->pdwn, 0);
+
+ if (thc63->oe)
+ gpiod_set_value(thc63->oe, 1);
+
+ return;
+
+error_vcc_enable:
+ dev_err(thc63->dev, "Failed to enable regulator %s\n",
+ thc63_reg_names[i]);
+
+ for (i = i - 1; i >= 0; i--) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ regulator_disable(vcc);
+ }
+}
+
+static void thc63_disable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ struct regulator *vcc;
+ int i;
+
+ if (thc63->oe)
+ gpiod_set_value(thc63->oe, 0);
+
+ if (thc63->pdwn)
+ gpiod_set_value(thc63->pdwn, 1);
+
+ for (i = ARRAY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ if (regulator_disable(vcc))
+ dev_dbg(thc63->dev,
+ "Failed to disable regulator %s\n",
+ thc63_reg_names[i]);
+ }
+}
+
+struct drm_bridge_funcs thc63_bridge_func = {
+ .attach = thc63_attach,
+ .enable = thc63_enable,
+ .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+ struct device_node *thc63_out;
+ struct device_node *remote;
+ int ret = 0;
+
+ thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+
[PATCH v5 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
decoder, connected to the on-chip LVDS encoder output on one side
and to HDMI encoder ADV7511w on the other one.
As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver is available, describe it in DT
as well.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 +++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index c0fd144..69f43b8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -42,6 +42,33 @@
};
};
};
+
+ thc63lvd1024: lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ thc63lvd1024_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@2{
+ reg = <2>;
+
+ thc63lvd1024_out_2: endpoint {
+ remote-endpoint = <_in>;
+ };
+
+ };
+
+ };
+ };
};
{
@@ -98,7 +125,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
- remote-endpoint = <_out>;
+ remote-endpoint = <_out_2>;
};
};
@@ -152,8 +179,8 @@
ports {
port@1 {
- endpoint {
- remote-endpoint = <_in>;
+ lvds0_out: endpoint {
+ remote-endpoint = <_in_0>;
};
};
};
--
2.7.4
Re: [PATCH v2 1/4] media: i2c: Copy mt9t112 soc_camera sensor driver
Hi Hans, On Thu, Mar 15, 2018 at 08:30:21AM -0700, Hans Verkuil wrote: > On 03/15/2018 07:38 AM, jacopo mondi wrote: > > Hi Sakari, > >thanks for looking into this! > > > > On Thu, Mar 15, 2018 at 01:35:34PM +0200, Sakari Ailus wrote: > >> Hi Jacopo, > >> > >> I wonder if it'd make sense to just make all the changes to the driver and > >> then have it reviewed; I'm not sure the old driver can be said to have been > >> in a known-good state that'd be useful to compare against. I think you did > >> that with another driver as well. > >> > > > > Well, I understand this is still debated, and I see your point. > > As far as I can tell the driver had been developed to work with SH4 > > Ecovec boards and there tested. > > > > I'm not sure I fully got you here though. Are you proposing to > > squash my next patch that cleans up the driver into this one and > > propose it as a completely new driver to be reviewed from scratch? > > > > In the two previous driver I touched in this "remove soc_camera" > > journey (ov772x and tw9910) I have followed this same pattern: copy > > the soc_camera driver without removing the existing one, and pile on > > top my changes/cleanups in another patch. Then port the board code to > > use the new sensor driver, and the new CEU driver as well. > > > > Also, how would you like to proceed here? Hans sent a pull request for > > the series, should I go with incremental changes on top of this? > > I don't want to postpone this conversion. The i2c/mt9t112.c is bug-compatible > with i2c/soc-camera/mt9t112.c which is good enough for me. Being able to > remove soc-camera in the (hopefully very) near future is the most important > thing here. > > Once Jacopo can actually test the sensor, then that's a good time to review > the driver in more detail. > > This reminded me that I actually started testing this sensor a year > ago (I bought the same sensor on ebay, I completely forgot about that!). > > My attempt is here: > > https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=mt9t112 > > I never finished it because I had no documentation on the pinout and never > got around to hooking my oscilloscope up to it to figure this out. I was > testing this with the atmel-isc.c driver. > > This might be of some use to you, Jacopo, once you have the sensor. Thanks for the info. I'll see what I can do. I don't have register level document, and if the module is the same you have neither a pinout description. This is going to be fun :/ I'll then refrain from sending more patches for this series/driver until we cannot actually test the sensor, fixes apart, if any, of course. Thanks j > > Regards, > > Hans signature.asc Description: PGP signature
Re: [PATCH v5 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
Hi Niklas,
thanks for review,
On Fri, Mar 16, 2018 at 01:00:04AM +0100, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your patch.
>
> This one must depend on '[PATCH v2 0/5] arm64: dts: renesas: r8a77970:
> enable HDMI output' or something similar not yet in renesas-drivers
> repository correct?
Yes, I have listed dependencies of this series in my v1 cover letter:
---
The series is based on Laurent's drm/next/du branch with patches on top for:
- Sergei: Enable PFC, I2c, GPIOs for r8a77970
- Sergei: Add support for r8a77970 in DU and add display device nodes in
r8a77970 DTSI
- Niklas: Connect DU LVDS output to HDMI bridge adv7511w in Eagle DTS
- Sergei: fix video output on R8A77970
A base branch with these patches applied is available at
git://jmondi.org/linux v3m/v4.16-rc3/base
---
My bad I have not reported this in all cover letters (and I have not
reported the full name of the series)
PFC, GPIO and I2c support I have listed as dependencies seems to have
landed in renesas-drivers, while I don't see yet:
Sergei:
[PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support
whose patches for r8a77970 dtsi are included in yours:
[PATCH v2 0/5] arm64: dts: renesas: r8a77970: enable HDMI output
On top I also have Sergei's/Laurent's:
[PATCH v4] v4l: vsp1: Fix video output on R8A77970
>
> In the next version would you care to include the LVDS commit from the
> dependency series and squash this change into that one or in some other
> good manger stack to two? Laurent told me he did not like 5/5 in that
> patch-set as it did not yet have the LVDS decoder node due to no driver
> existed at that time when I posted that even if it's not strictly needed
> to get the display working :-)
I'll let Simon suggest how he preferes to handle this, if he wants me
to re-submit your series with this patch squashed on top or he prefers
to deal with this himself.
>
> I also think you should split this last patch out to a separate series
> as it should go in Simon's tree while the driver and documentation is
> going in earlier in a different tree right?
I assume bindings and driver go through DRM and Simon is to pick up
the Eagle changes.
>
> On a side note, do you plan to update the Gen2 boards DTS files which
> also have a decoder which are not yet described in DT?
Actually I'm not aware of Gen2 boards with this chip and similar
display pipelines. Can you point me to which one needs to have its
DTS brushed?
Thanks
j
>
> On 2018-03-15 17:11:56 +0100, Jacopo Mondi wrote:
> > The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
> > decoder, connected to the on-chip LVDS encoder output on one side
> > and to HDMI encoder ADV7511w on the other one.
> >
> > As the decoder does not need any configuration it has been so-far
> > omitted from DTS. Now that a driver is available, describe it in DT
> > as well.
> >
> > Signed-off-by: Jacopo Mondi
> > Reviewed-by: Andrzej Hajda
> > ---
> > arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33
> > +++---
> > 1 file changed, 30 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > index c0fd144..69f43b8 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> > @@ -42,6 +42,33 @@
> > };
> > };
> > };
> > +
> > + thc63lvd1024: lvds-decoder {
> > + compatible = "thine,thc63lvd1024";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + thc63lvd1024_in_0: endpoint {
> > + remote-endpoint = <_out>;
> > + };
> > + };
> > +
> > + port@2{
> > + reg = <2>;
> > +
> > + thc63lvd1024_out_2: endpoint {
> > + remote-endpoint = <_in>;
> > + };
> > +
> > + };
> > +
> > + };
> > + };
> > };
> >
> > {
> > @@ -98,7 +125,7 @@
> > port@0 {
> > reg = <0&g
Re: [RFC 2/4] sh: ecovec24: conditionally register backlight device
Hello Dmitry
FYI I am brushing the ecovec board these days as well
https://www.spinics.net/lists/linux-sh/msg52536.html
And I have a board to test with but without any display panel, I'm
afraid.
On Thu, Mar 15, 2018 at 03:42:00PM -0700, Dmitry Torokhov wrote:
> Commit fe79f919f47e ("sh: ecovec24: Use gpio-backlight") removed custom
> backlight support and switched over to generic gpio-backlight driver. The
> comment when we run with DVI states "no backlight", but setting
> gpio_backlight_data.fbdev to NULL actually makes gpio-backlight to react to
> events from any framebuffer device, not ignore them.
>
> We want to get rid of platform data in favor of generic device properties
> in gpio_backlight driver, so we can not have kernel pointers passed around
> to tie the framebuffer device to backlight. Assuming that the intent of the
> above referenced commit was to indeed not export backlight when using DVI,
> let's switch to conditionally registering backlight device so it is not
> present at all in DVI case.
>
> Signed-off-by: Dmitry Torokhov
> ---
> arch/sh/boards/mach-ecovec24/setup.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/arch/sh/boards/mach-ecovec24/setup.c
> b/arch/sh/boards/mach-ecovec24/setup.c
> index 6f929abe0b50f..67633d2d42390 100644
> --- a/arch/sh/boards/mach-ecovec24/setup.c
> +++ b/arch/sh/boards/mach-ecovec24/setup.c
> @@ -368,7 +368,6 @@ static struct platform_device lcdc_device = {
> };
>
> static struct gpio_backlight_platform_data gpio_backlight_data = {
> - .fbdev = _device.dev,
> .gpio = GPIO_PTR1,
> .def_value = 1,
> .name = "backlight",
> @@ -987,7 +986,6 @@ static struct platform_device *ecovec_devices[]
> __initdata = {
> _common_device,
> _device,
> _device,
> - _backlight_device,
> _device,
> _device,
> _device,
> @@ -1077,6 +1075,8 @@ static int __init arch_setup(void)
> {
> struct clk *clk;
> bool cn12_enabled = false;
> + bool use_backlight = false;
> + int error;
>
> /* register board specific self-refresh code */
> sh_mobile_register_self_refresh(SUSP_SH_STANDBY | SUSP_SH_SF |
> @@ -1193,9 +1193,6 @@ static int __init arch_setup(void)
> lcdc_info.ch[0].lcd_modes = ecovec_dvi_modes;
> lcdc_info.ch[0].num_modes =
> ARRAY_SIZE(ecovec_dvi_modes);
>
> - /* No backlight */
> - gpio_backlight_data.fbdev = NULL;
> -
> gpio_set_value(GPIO_PTA2, 1);
> gpio_set_value(GPIO_PTU1, 1);
> } else {
> @@ -1217,6 +1214,8 @@ static int __init arch_setup(void)
> /* enable TouchScreen */
> i2c_register_board_info(0, _i2c_clients, 1);
> irq_set_irq_type(IRQ0, IRQ_TYPE_LEVEL_LOW);
> +
> + use_backlight = true;
> }
>
> /* enable CEU0 */
> @@ -1431,8 +1430,19 @@ static int __init arch_setup(void)
> gpio_set_value(GPIO_PTG4, 1);
> #endif
>
> - return platform_add_devices(ecovec_devices,
> - ARRAY_SIZE(ecovec_devices));
> + error = platform_add_devices(ecovec_devices,
> + ARRAY_SIZE(ecovec_devices));
I would invert this.
Register the backlight first, then all other devices.
> + if (error)
> + return error;
> +
> + if (use_backlight) {
> + error = platform_device_add(_backlight_device);
> + if (error)
> + pr_warn("%s: failed to register backlight: %d\n",
> + error);
Could you use dev_warn here? Also the format is wrong, I assume you
are missing a '__func__' as second function argument.
Also, you may want to return error.
Thanks
j
> + }
> +
> + return 0;
> }
> arch_initcall(arch_setup);
>
> --
> 2.16.2.804.g6dcf76e118-goog
>
signature.asc
Description: PGP signature
Re: [RFC 3/4] sh: ecovec24: convert backlight to use device properties
Hi Dmitry,
On Thu, Mar 15, 2018 at 03:42:01PM -0700, Dmitry Torokhov wrote:
> Instead of backlight legacy platform data, let's switch to using device
> properties and GPIO lookup tables.
>
> Signed-off-by: Dmitry Torokhov
> ---
> arch/sh/boards/mach-ecovec24/setup.c | 23 +++
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/arch/sh/boards/mach-ecovec24/setup.c
> b/arch/sh/boards/mach-ecovec24/setup.c
> index 67633d2d42390..ad3d48b3ead19 100644
> --- a/arch/sh/boards/mach-ecovec24/setup.c
> +++ b/arch/sh/boards/mach-ecovec24/setup.c
> @@ -11,11 +11,13 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -30,7 +32,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -367,17 +368,21 @@ static struct platform_device lcdc_device = {
> },
> };
>
> -static struct gpio_backlight_platform_data gpio_backlight_data = {
> - .gpio = GPIO_PTR1,
> - .def_value = 1,
> - .name = "backlight",
> +static struct gpiod_lookup_table gpio_backlight_gpios_table = {
> + .dev_id = "gpio-backlight.0",
> + .table = {
> + GPIO_LOOKUP_IDX("sh7724_pfc", GPIO_PTR1, NULL, 0,
> GPIO_ACTIVE_HIGH);
> + { }
I understand this is an RFC, but this bit does not even compile.
../arch/sh/boards/mach-ecovec24/setup.c:374:70: error: expected '}'
before ';' token
Thanks
j
> + },
> +};
> +
> +static struct property_entry gpio_backlight_properties[] = {
> + PROPERTY_ENTRY_BOOL("default-on"),
> + { }
> };
>
> static struct platform_device gpio_backlight_device = {
> .name = "gpio-backlight",
> - .dev = {
> - .platform_data = _backlight_data,
> - },
> };
>
> /* CEU0 */
> @@ -1436,6 +1441,8 @@ static int __init arch_setup(void)
> return error;
>
> if (use_backlight) {
> + device_add_properties(_backlight_device.dev,
> + gpio_backlight_properties);
> error = platform_device_add(_backlight_device);
> if (error)
> pr_warn("%s: failed to register backlight: %d\n",
> --
> 2.16.2.804.g6dcf76e118-goog
>
signature.asc
Description: PGP signature
[PATCH v6 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge
Hi, (hopefully) last iteration, with Niklas' Reviewed-by tags. Simply drop an un-necessary #ifdef guard for CONFIG_OF in driver's code as suggested by Niklas. Time to talk how this series will go in? I assume bindings and driver through DRM tree, while Simon is to pick up the Eagle DTS update once the first two patches will get in. Is this ok for both DRM and Renesas side? Also I assume before bindings gets accepted someone from devicetree list should ack them, correct? Simon: as Niklas suggested, I have now listed the series dependencies below the commit message. It is my understanding that is not necessary to resend his series with that commit squashed on top (which I also prefer not to). Thanks j v5 -> v6: - Drop check for CONFIG_OF as it is a Kconfig dependency - Add Niklas Reviewed-by tags - List [3/3] depenencies below commit message to ease integration v4 -> v5: - Fix punctuation in bindings documentation - Add small statement to bindings document to clarify the chip has no control bus - Print regulator name in enable/disable routines error path - Add Andrzej Reviewed-by tag v3 -> v4: - Rename permutations of "pdwn" to just "pdwn" everywhere in the series - Improve power enable/disable routines as suggested by Andrzej and Sergei - Change "pdwn" gpio initialization to use the logical output level - Change Kconfig description v2 -> v3: - Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific -- Rework bindings to describe multiple input/output ports -- Rename driver and remove "lvds-decoder" references -- Rework Eagle DTS to use new bindings v1 -> v2: - Drop support for THC63LVD1024 Jacopo Mondi (3): dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder drm: bridge: Add thc63lvd1024 LVDS decoder driver arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 ++ arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 ++- drivers/gpu/drm/bridge/Kconfig | 6 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/thc63lvd1024.c | 255 + 5 files changed, 358 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c -- 2.7.4
[PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Document Thine THC63LVD1024 LVDS decoder device tree bindings.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
Reviewed-by: Niklas Söderlund
---
.../bindings/display/bridge/thine,thc63lvd1024.txt | 66 ++
1 file changed, 66 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..8225c6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,66 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL
outputs.
+
+Single or dual operation modes, output data mapping and DDR output modes are
+configured through input signals and the chip does not expose any control bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry
+- pdwn-gpios: Power down GPIO signal. Active low
+- oe-gpios: Output enable GPIO signal. Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- Port@0: First LVDS input port
+- Port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- Port@1: Second LVDS input port
+- Port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+ thc63lvd1024: lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+
+ vcc-supply = <_lvds_vcc>;
+ lvcc-supply = <_lvds_lvcc>;
+
+ pdwn-gpio = < 15 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@2{
+ reg = <2>;
+
+ lvds_dec_out_2: endpoint {
+ remote-endpoint = <_in>;
+ };
+
+ };
+
+ };
+ };
--
2.7.4
[PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
Reviewed-by: Niklas Söderlund
---
drivers/gpu/drm/bridge/Kconfig| 6 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/thc63lvd1024.c | 255 ++
3 files changed, 262 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a..5815a20 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -92,6 +92,12 @@ config DRM_SII9234
It is an I2C driver, that detects connection of MHL bridge
and starts encapsulation of HDMI signal.
+config DRM_THINE_THC63LVD1024
+ tristate "Thine THC63LVD1024 LVDS decoder bridge"
+ depends on OF
+ ---help---
+ Thine THC63LVD1024 LVDS/parallel converter driver.
+
config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..fd90b16 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_SII9234) += sii9234.o
+obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
new file mode 100644
index 000..02a54c2
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * THC63LVD1024 LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+enum {
+ THC63_LVDS_IN0,
+ THC63_LVDS_IN1,
+ THC63_DIGITAL_OUT0,
+ THC63_DIGITAL_OUT1,
+};
+
+static const char * const thc63_reg_names[] = {
+ "vcc", "lvcc", "pvcc", "cvcc",
+};
+
+struct thc63_dev {
+ struct device *dev;
+
+ struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
+
+ struct gpio_desc *pdwn;
+ struct gpio_desc *oe;
+
+ struct drm_bridge bridge;
+ struct drm_bridge *next;
+};
+
+static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct thc63_dev, bridge);
+}
+
+static int thc63_attach(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+
+ return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
+}
+
+static void thc63_enable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ struct regulator *vcc;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ if (regulator_enable(vcc))
+ goto error_vcc_enable;
+ }
+
+ if (thc63->pdwn)
+ gpiod_set_value(thc63->pdwn, 0);
+
+ if (thc63->oe)
+ gpiod_set_value(thc63->oe, 1);
+
+ return;
+
+error_vcc_enable:
+ dev_err(thc63->dev, "Failed to enable regulator %s\n",
+ thc63_reg_names[i]);
+
+ for (i = i - 1; i >= 0; i--) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ regulator_disable(vcc);
+ }
+}
+
+static void thc63_disable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ struct regulator *vcc;
+ int i;
+
+ if (thc63->oe)
+ gpiod_set_value(thc63->oe, 0);
+
+ if (thc63->pdwn)
+ gpiod_set_value(thc63->pdwn, 1);
+
+ for (i = ARRAY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ if (regulator_disable(vcc))
+ dev_dbg(thc63->dev,
+ "Failed to disable regulator %s\n",
+ thc63_reg_names[i]);
+ }
+}
+
+struct drm_bridge_funcs thc63_bridge_func = {
+ .attach = thc63_attach,
+ .enable = thc63_enable,
+ .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+ struct device_node *thc63_out;
+ struct device_node *remote;
+ int ret = 0;
+
+ thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+
[PATCH v6 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
decoder, connected to the on-chip LVDS encoder output on one side
and to HDMI encoder ADV7511w on the other one.
As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver is available, describe it in DT
as well.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
---
List of patch dependencies, as of renesas-drivers-2018-03-13-v4.16-rc5:
- [PATCH v2 0/5] arm64: dts: renesas: r8a77970: enable HDMI output
which includes DU, LVDS and FCPD enablement from:
[PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support
- [PATCH v4] v4l: vsp1: Fix video output on R8A77970
Patches to be applied on top of
"arm64: dts: renesas: eagle: add HDMI output using the ADV7511W"
Thanks
j
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 +++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index c0fd144..69f43b8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -42,6 +42,33 @@
};
};
};
+
+ thc63lvd1024: lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ thc63lvd1024_in_0: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@2{
+ reg = <2>;
+
+ thc63lvd1024_out_2: endpoint {
+ remote-endpoint = <_in>;
+ };
+
+ };
+
+ };
+ };
};
{
@@ -98,7 +125,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
- remote-endpoint = <_out>;
+ remote-endpoint = <_out_2>;
};
};
@@ -152,8 +179,8 @@
ports {
port@1 {
- endpoint {
- remote-endpoint = <_in>;
+ lvds0_out: endpoint {
+ remote-endpoint = <_in_0>;
};
};
};
--
2.7.4
Re: [RFC 2/4] sh: ecovec24: conditionally register backlight device
Hi Dmitry,
On Fri, Mar 16, 2018 at 04:38:00PM -0700, Dmitry Torokhov wrote:
> Hi Jacopo,
>
> On Fri, Mar 16, 2018 at 11:07:48AM +0100, jacopo mondi wrote:
> > Hello Dmitry
> >
> > FYI I am brushing the ecovec board these days as well
> > https://www.spinics.net/lists/linux-sh/msg52536.html
> >
>
> What is the ecovec board BTW? Is it some devkit or what? It seems quite
> old to me.
Yes, it is a SuperH 4 based development board. It is old for sure. I'm
also working on removing some stuff the ecovec board file is the only
user of...
> > And I have a board to test with but without any display panel, I'm
> > afraid.
> >
> > On Thu, Mar 15, 2018 at 03:42:00PM -0700, Dmitry Torokhov wrote:
> > > Commit fe79f919f47e ("sh: ecovec24: Use gpio-backlight") removed custom
> > > backlight support and switched over to generic gpio-backlight driver. The
> > > comment when we run with DVI states "no backlight", but setting
> > > gpio_backlight_data.fbdev to NULL actually makes gpio-backlight to react
> > > to
> > > events from any framebuffer device, not ignore them.
> > >
> > > We want to get rid of platform data in favor of generic device properties
> > > in gpio_backlight driver, so we can not have kernel pointers passed around
> > > to tie the framebuffer device to backlight. Assuming that the intent of
> > > the
> > > above referenced commit was to indeed not export backlight when using DVI,
> > > let's switch to conditionally registering backlight device so it is not
> > > present at all in DVI case.
> > >
> > > Signed-off-by: Dmitry Torokhov
> > > ---
> > > arch/sh/boards/mach-ecovec24/setup.c | 24 +---
> > > 1 file changed, 17 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/sh/boards/mach-ecovec24/setup.c
> > > b/arch/sh/boards/mach-ecovec24/setup.c
> > > index 6f929abe0b50f..67633d2d42390 100644
> > > --- a/arch/sh/boards/mach-ecovec24/setup.c
> > > +++ b/arch/sh/boards/mach-ecovec24/setup.c
> > > @@ -368,7 +368,6 @@ static struct platform_device lcdc_device = {
> > > };
> > >
> > > static struct gpio_backlight_platform_data gpio_backlight_data = {
> > > - .fbdev = _device.dev,
> > > .gpio = GPIO_PTR1,
> > > .def_value = 1,
> > > .name = "backlight",
> > > @@ -987,7 +986,6 @@ static struct platform_device *ecovec_devices[]
> > > __initdata = {
> > > _common_device,
> > > _device,
> > > _device,
> > > - _backlight_device,
> > > _device,
> > > _device,
> > > _device,
> > > @@ -1077,6 +1075,8 @@ static int __init arch_setup(void)
> > > {
> > > struct clk *clk;
> > > bool cn12_enabled = false;
> > > + bool use_backlight = false;
> > > + int error;
> > >
> > > /* register board specific self-refresh code */
> > > sh_mobile_register_self_refresh(SUSP_SH_STANDBY | SUSP_SH_SF |
> > > @@ -1193,9 +1193,6 @@ static int __init arch_setup(void)
> > > lcdc_info.ch[0].lcd_modes = ecovec_dvi_modes;
> > > lcdc_info.ch[0].num_modes =
> > > ARRAY_SIZE(ecovec_dvi_modes);
> > >
> > > - /* No backlight */
> > > - gpio_backlight_data.fbdev = NULL;
> > > -
> > > gpio_set_value(GPIO_PTA2, 1);
> > > gpio_set_value(GPIO_PTU1, 1);
> > > } else {
> > > @@ -1217,6 +1214,8 @@ static int __init arch_setup(void)
> > > /* enable TouchScreen */
> > > i2c_register_board_info(0, _i2c_clients, 1);
> > > irq_set_irq_type(IRQ0, IRQ_TYPE_LEVEL_LOW);
> > > +
> > > + use_backlight = true;
> > > }
> > >
> > > /* enable CEU0 */
> > > @@ -1431,8 +1430,19 @@ static int __init arch_setup(void)
> > > gpio_set_value(GPIO_PTG4, 1);
> > > #endif
> > >
> > > - return platform_add_devices(ecovec_devices,
> > > - ARRAY_SIZE(ecovec_devices));
> > > + error = platform_add_devices(ecovec_devices,
> > > + ARRAY_SIZE(ecovec_devices));
> >
> > I would invert this.
> > Register the backlight first, then all other devices.
>
> We could do that, but why would that be better?
>
That if backlight device registration fails we do not register all
other devices. But yes that may be a bit t
[PATCH v2 10/19] dt-bindings: dmaengine: rcar-dmac: document R8A77965 support
Add documentation for r8a77965 compatible string to rcar-dmac device tree bindings documentation. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman --- Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt index 2f5167d..b7f3e60 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt @@ -25,6 +25,7 @@ Required Properties: - "renesas,dmac-r8a7794" (R-Car E2) - "renesas,dmac-r8a7795" (R-Car H3) - "renesas,dmac-r8a7796" (R-Car M3-W) + - "renesas,dmac-r8a77965" (R-Car M3-N) - "renesas,dmac-r8a77970" (R-Car V3M) - "renesas,dmac-r8a77980" (R-Car V3H) -- 2.7.4
[PATCH v2 08/19] ARM64: dts: Add Renesas R8A77965 SoC support
Basic support for the Gen 3 R-Car M3-N SoC.
Based on original work from:
Takeshi Kihara
Magnus Damm
Signed-off-by: Jacopo Mondi
---
v1 -> v2:
- Split r8a77965.dtsi from patch v1 [5/15]
- Replace all PD_ and CLK_ defines with numeric entries
- Move timer and pmu nodes outside of soc node and replace their
"interrupt" property with "interrupt-extended" one
- Fix license header
---
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 490 ++
1 file changed, 490 insertions(+)
create mode 100644 arch/arm64/boot/dts/renesas/r8a77965.dtsi
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
new file mode 100644
index 000..6b6ec65
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -0,0 +1,490 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the r8a77965 SoC
+ *
+ * Copyright (C) 2018 Jacopo Mondi
+ *
+ * Based on r8a7796.dtsi
+ * Copyright (C) 2016 Renesas Electronics Corp.
+ */
+
+#include
+#include
+
+#define CPG_AUDIO_CLK_I10
+
+/ {
+ compatible = "renesas,r8a77965";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ psci {
+ compatible = "arm,psci-1.0", "arm,psci-0.2";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ a57_0: cpu@0 {
+ compatible = "arm,cortex-a57", "arm,armv8";
+ reg = <0x0>;
+ device_type = "cpu";
+ power-domains = < 0>;
+ next-level-cache = <_CA57>;
+ enable-method = "psci";
+ };
+
+ a57_1: cpu@1 {
+ compatible = "arm,cortex-a57","arm,armv8";
+ reg = <0x1>;
+ device_type = "cpu";
+ power-domains = < 1>;
+ next-level-cache = <_CA57>;
+ enable-method = "psci";
+ };
+
+ L2_CA57: cache-controller-0 {
+ compatible = "cache";
+ reg = <0>;
+ power-domains = < 12>;
+ cache-unified;
+ cache-level = <2>;
+ };
+ };
+
+ extal_clk: extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board */
+ clock-frequency = <0>;
+ };
+
+ extalr_clk: extalr {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board */
+ clock-frequency = <0>;
+ };
+
+ /*
+* The external audio clocks are configured as 0 Hz fixed frequency
+* clocks by default.
+* Boards that provide audio clocks should override them.
+*/
+ audio_clk_a: audio_clk_a {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ audio_clk_b: audio_clk_b {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ audio_clk_c: audio_clk_c {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ /* External CAN clock - to be overridden by boards that provide it */
+ can_clk: can {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ /* External SCIF clock - to be overridden by boards that provide it */
+ scif_clk: scif {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ /* External PCIe clock - can be overridden by the board */
+ pcie_bus_clk: pcie_bus {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ /* External USB clocks - can be overridden by the board */
+ usb3s0_clk: usb3s0 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ usb_extal_clk: usb_extal {
+ compatible = "fixed-clock";
+
[PATCH v2 09/19] ARM64: dts: Add R-Car Salvator-x M3-N support
Add basic support for R-Car Salvator-X M3-N (R8A77965) board.
Based on original work from:
Takeshi Kihara
Magnus Damm
Signed-off-by: Jacopo Mondi
---
v1 -> v2:
- split from patch v1 [05/15]
- Remove "aliases" and "chosen" as they are defined already
- Fix license header
---
arch/arm64/boot/dts/renesas/Makefile| 1 +
arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts | 21 +
2 files changed, 22 insertions(+)
create mode 100644 arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
diff --git a/arch/arm64/boot/dts/renesas/Makefile
b/arch/arm64/boot/dts/renesas/Makefile
index 2186d01..3680ecd 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -7,5 +7,6 @@ dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-es1-h3ulcb-kf.dtb
dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb
dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-m3ulcb-kf.dtb
dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
+dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb
dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
dtb-$(CONFIG_ARCH_R8A77995) += r8a77995-draak.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
new file mode 100644
index 000..75d890d
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Salvator-X board with R-Car M3-N
+ *
+ * Copyright (C) 2018 Jacopo Mondi
+ */
+
+/dts-v1/;
+#include "r8a77965.dtsi"
+#include "salvator-x.dtsi"
+
+/ {
+ model = "Renesas Salvator-X board based on r8a77965";
+ compatible = "renesas,salvator-x", "renesas,r8a77965";
+
+ memory@4800 {
+ device_type = "memory";
+ /* first 128MB is reserved for secure area. */
+ reg = <0x0 0x4800 0x0 0x7800>;
+ };
+};
--
2.7.4
[PATCH v2 06/19] dt-bindings: arm: Document R-Car M3-N SoC DT bindings
Add device tree bindings documentation for Renesas R-Car M3-N (r8a77965) SoC. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index 41d3920..67889a9 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -39,6 +39,8 @@ SoCs: compatible = "renesas,r8a7795" - R-Car M3-W (R8A77960) compatible = "renesas,r8a7796" + - R-Car M3-N (R8A77965) +compatible = "renesas,r8a77965" - R-Car V3M (R8A77970) compatible = "renesas,r8a77970" - R-Car V3H (R8A77980) -- 2.7.4
Re: [PATCH v2 19/19] ARM64: dts: r8a77965: Add EtherAVB device node
Hi Sergei,
On Tue, Feb 20, 2018 at 06:30:56PM +0300, Sergei Shtylyov wrote:
> On 02/20/2018 06:12 PM, Jacopo Mondi wrote:
>
> > Populate the ethernet@e680 device node to enable Ethernet interface
> > for R-Car M3-N (r8a77965) SoC.
> >
> > Signed-off-by: Jacopo Mondi
> > Reviewed-by: Geert Uytterhoeven
> >
> > ---
> > v1 -> v2:
> > - Replace ALWAYS_ON power area identifier with numeric constant
> > ---
> > arch/arm64/boot/dts/renesas/r8a77965.dtsi | 43
> > ++-
> > 1 file changed, 42 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > index 55f05f7..c249895 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> > @@ -520,7 +520,48 @@
> > };
> >
> > avb: ethernet@e680 {
> > - /* placeholder */
> > + compatible = "renesas,etheravb-r8a77965",
> > +"renesas,etheravb-rcar-gen3";
> > + reg = <0 0xe680 0 0x800>, <0 0xe6a0 0 0x1>;
> > + interrupts = ,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +;
> > + interrupt-names = "ch0", "ch1", "ch2", "ch3",
> > + "ch4", "ch5", "ch6", "ch7",
> > + "ch8", "ch9", "ch10", "ch11",
> > + "ch12", "ch13", "ch14", "ch15",
> > + "ch16", "ch17", "ch18", "ch19",
> > + "ch20", "ch21", "ch22", "ch23",
> > + "ch24";
> > + clocks = < CPG_MOD 812>;
> > + power-domains = < 32>;
> > + resets = < 812>;
> > + phy-mode = "rgmii-txid";
>
>Why not just "rgmii"? TX delay is a board specific detail, no?
>
I admit I took this one straight from r8a7796 dtsi.
Would you like to me resend and change this?
Thanks
j
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "disabled";
> > };
> >
> > csi20: csi2@fea8 {
> >
>
> MBR, Sergei
Re: [PATCH v9 07/11] media: i2c: ov772x: Support frame interval handling
Hi Hans,
On Wed, Feb 21, 2018 at 01:12:14PM +0100, Hans Verkuil wrote:
[snip]
> > +static int ov772x_g_frame_interval(struct v4l2_subdev *sd,
> > + struct v4l2_subdev_frame_interval *ival)
> > +{
> > + struct ov772x_priv *priv = to_ov772x(sd);
> > + struct v4l2_fract *tpf = >interval;
> > +
> > + memset(ival->reserved, 0, sizeof(ival->reserved));
>
> This memset...
>
> > + tpf->numerator = 1;
> > + tpf->denominator = priv->fps;
> > +
> > + return 0;
> > +}
> > +
> > +static int ov772x_s_frame_interval(struct v4l2_subdev *sd,
> > + struct v4l2_subdev_frame_interval *ival)
> > +{
> > + struct ov772x_priv *priv = to_ov772x(sd);
> > + struct v4l2_fract *tpf = >interval;
> > +
> > + memset(ival->reserved, 0, sizeof(ival->reserved));
>
> ... and this memset can be dropped. The core code will memset this for you.
>
>
I see! Ok, I'll drop them in v10
> > +
> > + return ov772x_set_frame_rate(priv, tpf, priv->cfmt, priv->win);
> > +}
> > +
> > static int ov772x_s_ctrl(struct v4l2_ctrl *ctrl)
> > {
> > struct ov772x_priv *priv = container_of(ctrl->handler,
> > @@ -757,6 +905,7 @@ static int ov772x_set_params(struct ov772x_priv *priv,
> > const struct ov772x_win_size *win)
> > {
> > struct i2c_client *client = v4l2_get_subdevdata(>subdev);
> > + struct v4l2_fract tpf;
> > int ret;
> > u8 val;
> >
> > @@ -885,6 +1034,13 @@ static int ov772x_set_params(struct ov772x_priv *priv,
> > if (ret < 0)
> > goto ov772x_set_fmt_error;
> >
> > + /* COM4, CLKRC: Set pixel clock and framerate. */
> > + tpf.numerator = 1;
> > + tpf.denominator = priv->fps;
> > + ret = ov772x_set_frame_rate(priv, , cfmt, win);
> > + if (ret < 0)
> > + goto ov772x_set_fmt_error;
> > +
> > /*
> > * set COM8
> > */
> > @@ -1043,6 +1199,24 @@ static const struct v4l2_subdev_core_ops
> > ov772x_subdev_core_ops = {
> > .s_power= ov772x_s_power,
> > };
> >
> > +static int ov772x_enum_frame_interval(struct v4l2_subdev *sd,
> > + struct v4l2_subdev_pad_config *cfg,
> > + struct v4l2_subdev_frame_interval_enum
> > *fie)
> > +{
> > + if (fie->pad || fie->index >= OV772X_N_FRAME_INTERVALS)
> > + return -EINVAL;
> > +
> > + if (fie->width != VGA_WIDTH && fie->width != QVGA_WIDTH)
> > + return -EINVAL;
> > + if (fie->height != VGA_HEIGHT && fie->height != QVGA_HEIGHT)
> > + return -EINVAL;
> > +
> > + fie->interval.numerator = 1;
> > + fie->interval.denominator = ov772x_frame_intervals[fie->index];
> > +
> > + return 0;
> > +}
> > +
> > static int ov772x_enum_mbus_code(struct v4l2_subdev *sd,
> > struct v4l2_subdev_pad_config *cfg,
> > struct v4l2_subdev_mbus_code_enum *code)
> > @@ -1055,14 +1229,17 @@ static int ov772x_enum_mbus_code(struct v4l2_subdev
> > *sd,
> > }
> >
> > static const struct v4l2_subdev_video_ops ov772x_subdev_video_ops = {
> > - .s_stream = ov772x_s_stream,
> > + .s_stream = ov772x_s_stream,
> > + .s_frame_interval = ov772x_s_frame_interval,
> > + .g_frame_interval = ov772x_g_frame_interval,
> > };
> >
> > static const struct v4l2_subdev_pad_ops ov772x_subdev_pad_ops = {
> > - .enum_mbus_code = ov772x_enum_mbus_code,
> > - .get_selection = ov772x_get_selection,
> > - .get_fmt= ov772x_get_fmt,
> > - .set_fmt= ov772x_set_fmt,
> > + .enum_frame_interval= ov772x_enum_frame_interval,
> > + .enum_mbus_code = ov772x_enum_mbus_code,
> > + .get_selection = ov772x_get_selection,
> > + .get_fmt= ov772x_get_fmt,
> > + .set_fmt= ov772x_set_fmt,
>
> Shouldn't these last four ops be added in the previous patch?
> They don't have anything to do with the frame interval support.
>
If you look closely you'll notice I have just re-aligned them, since I
was at there to add enum_frame_interval operation
> Anyway, after taking care of the memsets and these four ops you can add
> my:
>
> Acked-by: Hans Verkuil
Thanks
j
Re: [PATCH v9 11/11] media: i2c: ov7670: Fully set mbus frame fmt
Hello again, On Tue, Feb 20, 2018 at 09:58:57AM +0100, jacopo mondi wrote: > Hi Laurent, > > On Mon, Feb 19, 2018 at 09:19:32PM +0200, Laurent Pinchart wrote: > > Hi Jacopo, > > > > Thank you for the patch. > > > > On Monday, 19 February 2018 18:59:44 EET Jacopo Mondi wrote: > > > The sensor driver sets mbus format colorspace information and sizes, > > > but not ycbcr encoding, quantization and xfer function. When supplied > > > with an badly initialized mbus frame format structure, those fields > > > need to be set explicitly not to leave them uninitialized. This is > > > tested by v4l2-compliance, which supplies a mbus format description > > > structure and checks for all fields to be properly set. > > > > > > Without this commit, v4l2-compliance fails when testing formats with: > > > fail: v4l2-test-formats.cpp(335): ycbcr_enc >= 0xff > > > > > > Signed-off-by: Jacopo Mondi > > > --- > > > drivers/media/i2c/ov7670.c | 4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c > > > index 25b26d4..61c472e 100644 > > > --- a/drivers/media/i2c/ov7670.c > > > +++ b/drivers/media/i2c/ov7670.c > > > @@ -996,6 +996,10 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev > > > *sd, fmt->height = wsize->height; > > > fmt->colorspace = ov7670_formats[index].colorspace; > > > > On a side note, if I'm not mistaken the colorspace field is set to SRGB for > > all entries. Shouldn't you hardcode it here and remove the field ? > > > > > + fmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT; > > > + fmt->quantization = V4L2_QUANTIZATION_DEFAULT; > > > + fmt->xfer_func = V4L2_XFER_FUNC_DEFAULT; > > > > How about setting the values explicitly instead of relying on defaults ? > > That > > would be V4L2_YCBCR_ENC_601, V4L2_QUANTIZATION_LIM_RANGE and > > V4L2_XFER_FUNC_SRGB. And could you then check a captured frame to see if the > > sensor outputs limited or full range ? > > > > This actually makes me wonder if those informations (ycbcb_enc, > quantization and xfer_func) shouldn't actually be part of the > supported format list... I blindly added those default fields in the > try_fmt function, but I doubt they applies to all supported formats. > > Eg. the sensor supports YUYV as well as 2 RGB encodings (RGB444 and > RGB 565) and 1 raw format (BGGR). I now have a question here: > > 1) ycbcr_enc transforms non-linear R'G'B' to Y'CbCr: does this > applies to RGB and raw formats? I don't think so, and what value is > the correct one for the ycbcr_enc field in this case? I assume > xfer_func and quantization applies to all formats instead.. > What if I repropose this as separate patch not part of the CEU series in order not to hold back v10 (which I hope will be the last CEU iteration)? > Thanks >j > > > > info->format = *fmt; > > > > > > return 0; > > > > -- > > Regards, > > > > Laurent Pinchart > >
Re: [PATCH v9 03/11] media: platform: Add Renesas CEU driver
Hi Laurent, Hans,
On Wed, Feb 21, 2018 at 02:02:59PM +0100, Hans Verkuil wrote:
> On 02/21/18 13:29, Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Wednesday, 21 February 2018 14:03:24 EET Hans Verkuil wrote:
> >> On 02/19/18 17:59, Jacopo Mondi wrote:
> >>> Add driver for Renesas Capture Engine Unit (CEU).
> >>>
> >>> The CEU interface supports capturing 'data' (YUV422) and 'images'
> >>> (NV[12|21|16|61]).
> >>>
> >>> This driver aims to replace the soc_camera-based sh_mobile_ceu one.
> >>>
> >>> Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ
> >>> platform GR-Peach.
> >>>
> >>> Tested with ov7725 camera sensor on SH4 platform Migo-R.
> >>>
> >>> Signed-off-by: Jacopo Mondi
> >>> Reviewed-by: Laurent Pinchart
> >>> ---
> >>>
> >>> drivers/media/platform/Kconfig |9 +
> >>> drivers/media/platform/Makefile |1 +
> >>> drivers/media/platform/renesas-ceu.c | 1661 +
> >>> 3 files changed, 1671 insertions(+)
> >>> create mode 100644 drivers/media/platform/renesas-ceu.c
> >>
> >>
> >>
> >>> +static int ceu_s_input(struct file *file, void *priv, unsigned int i)
> >>> +{
> >>> + struct ceu_device *ceudev = video_drvdata(file);
> >>> + struct ceu_subdev *ceu_sd_old;
> >>> + int ret;
> >>> +
> >>> + if (i >= ceudev->num_sd)
> >>> + return -EINVAL;
> >>> +
> >>> + if (vb2_is_streaming(>vb2_vq))
> >>> + return -EBUSY;
> >>> +
> >>> + if (i == ceudev->sd_index)
> >>> + return 0;
> >>> +
> >>> + ceu_sd_old = ceudev->sd;
> >>> + ceudev->sd = >subdevs[i];
> >>> +
> >>> + /* Make sure we can generate output image formats. */
> >>> + ret = ceu_init_formats(ceudev);
> >>
> >> Why is this done for every s_input? I would expect that this is done only
> >> once for each subdev.
> >>
> >> I also expect to see a ceu_set_default_fmt() call here. Or that the
> >> v4l2_pix
> >> is kept in ceu_subdev (i.e. per subdev) instead of a single fmt in cuedev.
> >> I think I prefer that over configuring a new default format every time you
> >> switch inputs.
> >
> > What does userspace expect today ? I don't think we document anywhere that
> > formats are stored per-input in drivers. The VIDIOC_S_INPUT documentation is
> > very vague:
> >
> > "To select a video input applications store the number of the desired input
> > in
> > an integer and call the VIDIOC_S_INPUT ioctl with a pointer to this integer.
> > Side effects are possible. For example inputs may support different video
> > standards, so the driver may implicitly switch the current standard. Because
> > of these possible side effects applications must select an input before
> > querying or negotiating any other parameters."
> >
> > I understand that as meaning "anything can happen when you switch inputs, so
> > be prepared to reconfigure everything explicitly without assuming any
> > particular parameter to have a sane value".
> >
> >> This code will work for two subdevs with exactly the same
> >> formats/properties. But switching between e.g. a sensor and a video
> >> receiver will leave things in an inconsistent state as far as I can see.
> >>
> >> E.g. if input 1 is the video receiver then switching to that input and
> >> running 'v4l2-ctl -V' will show the sensor format, not the video receiver
> >> format.
> >
> > I agree that the format should be consistent with the selected input, as
> > calling VIDIOC_S_INPUT immediately followed by a stream start sequence
> > without
> > configuring formats should work (but produce a format that is not known to
> > userspace). My question is whether we should reset to a default format for
> > the
> > newly select input, or switch back to the previously set format. I'd tend to
> > go for the former to keep as little state as possible, but I'm open to
> > counter-proposals.
>
> What to do is up to the driver. My personal preference is to make it
> persistent
> per input, but that's just me. I won't block the other approach (resetting it
> to a default). Be aware that for video receivers the format depends on the
[PATCH v10 01/10] dt-bindings: media: Add Renesas CEU bindings
Add bindings documentation for Renesas Capture Engine Unit (CEU).
Signed-off-by: Jacopo Mondi
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
.../devicetree/bindings/media/renesas,ceu.txt | 81 ++
1 file changed, 81 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt
b/Documentation/devicetree/bindings/media/renesas,ceu.txt
new file mode 100644
index 000..3fc66df
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
@@ -0,0 +1,81 @@
+Renesas Capture Engine Unit (CEU)
+--
+
+The Capture Engine Unit is the image capture interface found in the Renesas
+SH Mobile and RZ SoCs.
+
+The interface supports a single parallel input with data bus width of 8 or 16
+bits.
+
+Required properties:
+- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1H
+ and RZ/A1M SoCs.
+- reg: Registers address base and size.
+- interrupts: The interrupt specifier.
+
+The CEU supports a single parallel input and should contain a single 'port'
+subnode with a single 'endpoint'. Connection to input devices are modeled
+according to the video interfaces OF bindings specified in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Optional endpoint properties applicable to parallel input bus described in
+the above mentioned "video-interfaces.txt" file are supported.
+
+- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH
respectively.
+ If property is not present, default is active high.
+- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH
respectively.
+ If property is not present, default is active high.
+
+Example:
+
+The example describes the connection between the Capture Engine Unit and an
+OV7670 image sensor connected to i2c1 interface.
+
+ceu: ceu@e821 {
+ reg = <0xe821 0x209c>;
+ compatible = "renesas,r7s72100-ceu";
+ interrupts = ;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+
+ port {
+ ceu_in: endpoint {
+ remote-endpoint = <_out>;
+
+ hsync-active = <1>;
+ vsync-active = <0>;
+ };
+ };
+};
+
+i2c1: i2c@fcfee400 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+
+ clock-frequency = <10>;
+
+ ov7670: camera@21 {
+ compatible = "ovti,ov7670";
+ reg = <0x21>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ reset-gpios = < 11 GPIO_ACTIVE_LOW>;
+ powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov7670_out: endpoint {
+ remote-endpoint = <_in>;
+
+ hsync-active = <1>;
+ vsync-active = <0>;
+ };
+ };
+ };
+};
--
2.7.4
[PATCH v10 00/10] Renesas Capture Engine Unit (CEU) V4L2 driver
Hello, 10th round, one step closer to finalize CEU inclusion (hopefully). I have dropped patch 11/11 of v9 as it is still a debated topic and I would like to have it clarified without blocking this series. In patch [3/10] Hans noticed that after changing input, format should be set on CEU again to make sure userspace can start streaming operations. While there's no clear preference if applying default formats to the newly selected input is the best option, I went for this one. While at there I renamed the "ceu_init_formats()" function to "ceu_init_mbus_fmt()" and moved field selection to "ceu_set[_default]_fmt()" functions. In patch [7/10] I have dropped two redundant memsets and closed a few warnings received from 0-day running sparse on the patch. I have declared two fields as static, and transformed an "if" clause in a "switch" one, to catch all possible cases with a "default" one and while at there replaced the frame interval array size definition with an explicit ARRAY_SIZE(). Apart from that, all patches are now acked/reviewed, apart from 03/10 that has Hans' ack still pending. Diff from v9 is so short, I captured it here for the interested ones: https://paste.debian.net/hidden/91567755 Thanks j v9->v10: - Close 0-days warning on ov772x frame interval - Set default format on CEU after input change - Drop ov7670 mbus frame format set not to block this series while topic gets clarified v8->v9: - Address Laurent's review of ov772x frame rate - Address Sergei comment on ceu node name v7->v8: - Calculate PLL divider/multiplier and do not use static tables - Change RZ/A1-H to RZ/A1H (same for L) in bindings documentation - Use rounded clock rate in Migo-R board code as SH clk_set_clk() implementation does not perform rounding - Set ycbcr_enc and other fields of v4l2_mbus_format for ov772x as patch [11/11] does for ov7670 v6->v7: - Add patch to handle ycbr_enc and other fields of v4l2_mbus_format for ov7670 - Add patch to handle frame interval for ov772x - Rebased on Hans' media-tree/parm branch with v4l2_g/s_parm_cap - Drop const modifier in CEU releated fields of Migo-R setup.c board file to silence complier warnings. v5->v6: - Add Hans' Acked-by to most patches - Fix a bad change in ov772x get_selection - Add .buf_prepare callack to CEU and verify plane sizes there - Remove VB2_USERPTR from supported io_modes in CEU driver - Remove read() fops in CEU driver v4->v5: - Added Rob's and Laurent's Reviewed-by tag to DT bindings - Change CEU driver module license to "GPL v2" to match SPDX identifier as suggested by Philippe Ombredanne - Make struct ceu_data static as suggested by Laurent and add his Reviewed-by to CEU driver. v3->v4: - Drop generic fallback compatible string "renesas,ceu" - Addressed Laurent's comments on [3/9] - Fix error messages on irq get/request - Do not leak ceudev if irq_get fails - Make irq_mask a const field v2->v3: - Improved DT bindings removing standard properties (pinctrl- ones and remote-endpoint) not specific to this driver and improved description of compatible strings - Remove ov772x's xlkc_rate property and set clock rate in Migo-R board file - Made 'xclk' clock private to ov772x driver in Migo-R board file - Change 'rstb' GPIO active output level and changed ov772x and tw9910 drivers accordingly as suggested by Fabio - Minor changes in CEU driver to address Laurent's comments - Moved Migo-R setup patch to the end of the series to silence 0-day bot - Renamed tw9910 clock to 'xti' as per video decoder manual - Changed all SPDX identifiers to GPL-2.0 from previous GPL-2.0+ v1->v2: - DT -- Addressed Geert's comments and added clocks for CEU to mstp6 clock source -- Specified supported generic video iterfaces properties in dt-bindings and simplified example - CEU driver -- Re-worked interrupt handler, interrupt management, reset(*) and capture start operation -- Re-worked querycap/enum_input/enum_frameintervals to fix some v4l2_compliance failures -- Removed soc_camera legacy operations g/s_mbus_format -- Update to new notifier implementation -- Fixed several comments from Hans, Laurent and Sakari - Migo-R -- Register clocks and gpios for sensor drivers in Migo-R setup -- Updated sensors (tw9910 and ov772x) drivers headers and drivers to close remarks from Hans and Laurent: --- Removed platform callbacks and handle clocks and gpios from sensor drivers --- Remove g/s_mbus_config operations Jacopo Mondi (10): dt-bindings: media: Add Renesas CEU bindings include: media: Add Renesas CEU driver interface media: platform: Add Renesas CEU driver ARM: dts: r7s72100: Add Capture Engine Unit (CEU) media: i2c: Copy ov772x soc_camera sensor driver media: i2c: ov772x: Remove soc_camera dependencies media: i2c: ov772x: Support frame interval handling media: i2c: Copy tw9910 soc_camera senso
[PATCH v10 03/10] media: platform: Add Renesas CEU driver
Add driver for Renesas Capture Engine Unit (CEU). The CEU interface supports capturing 'data' (YUV422) and 'images' (NV[12|21|16|61]). This driver aims to replace the soc_camera-based sh_mobile_ceu one. Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ platform GR-Peach. Tested with ov7725 camera sensor on SH4 platform Migo-R. Signed-off-by: Jacopo Mondi Reviewed-by: Laurent Pinchart --- drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile |1 + drivers/media/platform/renesas-ceu.c | 1670 ++ 3 files changed, 1680 insertions(+) create mode 100644 drivers/media/platform/renesas-ceu.c diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 614fbef..f9cc058 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI To compile this driver as a module, choose M here: the module will be called stm32-dcmi. +config VIDEO_RENESAS_CEU + tristate "Renesas Capture Engine Unit (CEU) driver" + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA + depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST + select VIDEOBUF2_DMA_CONTIG + select V4L2_FWNODE + ---help--- + This is a v4l2 driver for the Renesas CEU Interface + source "drivers/media/platform/soc_camera/Kconfig" source "drivers/media/platform/exynos4-is/Kconfig" source "drivers/media/platform/am437x/Kconfig" diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 7f30804..85e1121 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -62,6 +62,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)+= sh_vou.o obj-$(CONFIG_SOC_CAMERA) += soc_camera/ obj-$(CONFIG_VIDEO_RCAR_DRIF) += rcar_drif.o +obj-$(CONFIG_VIDEO_RENESAS_CEU)+= renesas-ceu.o obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o obj-$(CONFIG_VIDEO_RENESAS_FDP1) += rcar_fdp1.o obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o diff --git a/drivers/media/platform/renesas-ceu.c b/drivers/media/platform/renesas-ceu.c new file mode 100644 index 000..6624fba --- /dev/null +++ b/drivers/media/platform/renesas-ceu.c @@ -0,0 +1,1670 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface + * Copyright (C) 2017-2018 Jacopo Mondi + * + * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c" + * Copyright (C) 2008 Magnus Damm + * + * Based on V4L2 Driver for PXA camera host - "pxa_camera.c", + * Copyright (C) 2006, Sascha Hauer, Pengutronix + * Copyright (C) 2008, Guennadi Liakhovetski + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define DRIVER_NAME"renesas-ceu" + +/* CEU registers offsets and masks. */ +#define CEU_CAPSR 0x00 /* Capture start register */ +#define CEU_CAPCR 0x04 /* Capture control register*/ +#define CEU_CAMCR 0x08 /* Capture interface control register */ +#define CEU_CAMOR 0x10 /* Capture interface offset register */ +#define CEU_CAPWR 0x14 /* Capture interface width register*/ +#define CEU_CAIFR 0x18 /* Capture interface input format register */ +#define CEU_CRCNTR 0x28 /* CEU register control register */ +#define CEU_CRCMPR 0x2c /* CEU register forcible control register */ +#define CEU_CFLCR 0x30 /* Capture filter control register */ +#define CEU_CFSZR 0x34 /* Capture filter size clip register */ +#define CEU_CDWDR 0x38 /* Capture destination width register */ +#define CEU_CDAYR 0x3c /* Capture data address Y register */ +#define CEU_CDACR 0x40 /* Capture data address C register */ +#define CEU_CFWCR 0x5c /* Firewall operation control register */ +#define CEU_CDOCR 0x64 /* Capture data output control register*/ +#define CEU_CEIER 0x70 /* Capture event interrupt enable register */ +#define CEU_CETCR 0x74 /* Capture event flag clear register */ +#define CEU_CSTSR 0x7c /* Capture status register */ +#define CEU_CSRTR 0x80 /* Capture software reset register */ + +/* Data synchronous fetch mode. */ +#define CEU_CAMCR_JPEG BIT(4) + +/* Input components ordering: CEU_CAMCR.DTARY field. */ +#define CEU_CAMCR_DTARY_8_UYVY (0x00 << 8) +#define CEU_CAMCR_DTARY_8_VYUY (0x01 << 8) +#define CEU_CAMCR_DTARY_8_YUYV
[PATCH v10 06/10] media: i2c: ov772x: Remove soc_camera dependencies
Remove soc_camera framework dependencies from ov772x sensor driver.
- Handle clock and gpios
- Register async subdevice
- Remove soc_camera specific g/s_mbus_config operations
- Change image format colorspace from JPEG to SRGB as the two use the
same colorspace information but JPEG makes assumptions on color
components quantization that do not apply to the sensor
- Remove sizes crop from get_selection as driver can't scale
- Add kernel doc to driver interface header file
- Adjust build system
This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera-based CEU driver.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
---
drivers/media/i2c/Kconfig | 11 +++
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/ov772x.c | 172 ++---
include/media/i2c/ov772x.h | 6 +-
4 files changed, 133 insertions(+), 57 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9f18cd2..e71e968 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -645,6 +645,17 @@ config VIDEO_OV5670
To compile this driver as a module, choose M here: the
module will be called ov5670.
+config VIDEO_OV772X
+ tristate "OmniVision OV772x sensor support"
+ depends on I2C && VIDEO_V4L2
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV772x camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov772x.
+
config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index c0f94cd..b0489a1 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 8063835..23106d7 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* ov772x Camera Driver
*
+ * Copyright (C) 2017 Jacopo Mondi
+ *
* Copyright (C) 2008 Renesas Solutions Corp.
* Kuninori Morimoto
*
@@ -9,27 +12,25 @@
* Copyright 2006-7 Jonathan Corbet
* Copyright (C) 2008 Magnus Damm
* Copyright (C) 2008, Guennadi Liakhovetski
- *
- * 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.
*/
+#include
+#include
+#include
+#include
#include
#include
#include
-#include
#include
-#include
#include
#include
#include
-#include
-#include
+
#include
-#include
+#include
#include
+#include
/*
* register offset
@@ -393,8 +394,10 @@ struct ov772x_win_size {
struct ov772x_priv {
struct v4l2_subdevsubdev;
struct v4l2_ctrl_handler hdl;
- struct v4l2_clk *clk;
+ struct clk *clk;
struct ov772x_camera_info*info;
+ struct gpio_desc *pwdn_gpio;
+ struct gpio_desc *rstb_gpio;
const struct ov772x_color_format *cfmt;
const struct ov772x_win_size *win;
unsigned shortflag_vflip:1;
@@ -409,7 +412,7 @@ struct ov772x_priv {
static const struct ov772x_color_format ov772x_cfmts[] = {
{
.code = MEDIA_BUS_FMT_YUYV8_2X8,
- .colorspace = V4L2_COLORSPACE_JPEG,
+ .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3 = 0x0,
.dsp4 = DSP_OFMT_YUV,
.com3 = SWAP_YUV,
@@ -417,7 +420,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
},
{
.code = MEDIA_BUS_FMT_YVYU8_2X8,
- .colorspace = V4L2_COLORSPACE_JPEG,
+ .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3 = UV_ON,
.dsp4 = DSP_OFMT_YUV,
.com3 = SWAP_YUV,
@@ -425,7 +428,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
},
{
.code = MEDIA_BUS_FMT_UYVY8_2X8,
- .colorspace = V4L2_COLORSPACE_JPEG,
+ .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3 = 0x0,
.dsp4 = DSP_OFMT_YUV,
.co
[PATCH v10 10/10] arch: sh: migor: Use new renesas-ceu camera driver
Migo-R platform uses sh_mobile_ceu camera driver, which is now being
replaced by a proper V4L2 camera driver named 'renesas-ceu'.
Move Migo-R platform to use the v4l2 renesas-ceu camera driver
interface and get rid of soc_camera defined components used to register
sensor drivers and of platform specific enable/disable routines.
Register clock source and GPIOs for sensor drivers, so they can use
clock and gpio APIs.
Also, memory for CEU video buffers is now reserved with membocks APIs,
and need to be declared as dma_coherent during machine initialization to
remove that architecture specific part from CEU driver.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
arch/sh/boards/mach-migor/setup.c | 225 +++--
arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +-
2 files changed, 101 insertions(+), 126 deletions(-)
diff --git a/arch/sh/boards/mach-migor/setup.c
b/arch/sh/boards/mach-migor/setup.c
index 0bcbe58..271dfc2 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -1,17 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Renesas System Solutions Asia Pte. Ltd - Migo-R
*
* Copyright (C) 2008 Magnus Damm
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
*/
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -23,10 +22,11 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -45,6 +45,9 @@
* 0x1800 8GB8 NAND Flash (K9K8G08U0A)
*/
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu_dma_membase;
+
static struct smc91x_platdata smc91x_info = {
.flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
};
@@ -301,65 +304,24 @@ static struct platform_device migor_lcdc_device = {
},
};
-static struct clk *camera_clk;
-static DEFINE_MUTEX(camera_lock);
-
-static void camera_power_on(int is_tw)
-{
- mutex_lock(_lock);
-
- /* Use 10 MHz VIO_CKO instead of 24 MHz to work
-* around signal quality issues on Panel Board V2.1.
-*/
- camera_clk = clk_get(NULL, "video_clk");
- clk_set_rate(camera_clk, 1000);
- clk_enable(camera_clk); /* start VIO_CKO */
-
- /* use VIO_RST to take camera out of reset */
- mdelay(10);
- if (is_tw) {
- gpio_set_value(GPIO_PTT2, 0);
- gpio_set_value(GPIO_PTT0, 0);
- } else {
- gpio_set_value(GPIO_PTT0, 1);
- }
- gpio_set_value(GPIO_PTT3, 0);
- mdelay(10);
- gpio_set_value(GPIO_PTT3, 1);
- mdelay(10); /* wait to let chip come out of reset */
-}
-
-static void camera_power_off(void)
-{
- clk_disable(camera_clk); /* stop VIO_CKO */
- clk_put(camera_clk);
-
- gpio_set_value(GPIO_PTT3, 0);
- mutex_unlock(_lock);
-}
-
-static int ov7725_power(struct device *dev, int mode)
-{
- if (mode)
- camera_power_on(0);
- else
- camera_power_off();
-
- return 0;
-}
-
-static int tw9910_power(struct device *dev, int mode)
-{
- if (mode)
- camera_power_on(1);
- else
- camera_power_off();
-
- return 0;
-}
-
-static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
- .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_platform_data ceu_pdata = {
+ .num_subdevs= 2,
+ .subdevs = {
+ { /* [0] = ov772x */
+ .flags = 0,
+ .bus_width = 8,
+ .bus_shift = 0,
+ .i2c_adapter_id = 0,
+ .i2c_address= 0x21,
+ },
+ { /* [1] = tw9910 */
+ .flags = 0,
+ .bus_width = 8,
+ .bus_shift = 0,
+ .i2c_adapter_id = 0,
+ .i2c_address= 0x45,
+ },
+ },
};
static struct resource migor_ceu_resources[] = {
@@ -373,18 +335,32 @@ static struct resource migor_ceu_resources[] = {
.start = evt2irq(0x880),
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* place holder for contiguous memory */
- },
};
static struct platform_device migor_ceu_device = {
- .name = "sh_mobile_ceu",
- .id = 0, /* "ceu0" clock */
+ .name = "renesas-ceu",
+ .id = 0, /* ceu.0 */
.num_resources = ARRAY_SIZE(migor_ceu_resources),
.resource = migor_ceu_resources,
.dev= {
- .platform_
[PATCH v10 09/10] media: i2c: tw9910: Remove soc_camera dependencies
Remove soc_camera framework dependencies from tw9910 sensor driver.
- Handle clock and gpios
- Register async subdevice
- Remove soc_camera specific g/s_mbus_config operations
- Add kernel doc to driver interface header file
- Adjust build system
This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera-based CEU driver.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
drivers/media/i2c/Kconfig | 9 +++
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/tw9910.c | 162 -
include/media/i2c/tw9910.h | 9 +++
4 files changed, 120 insertions(+), 61 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index e71e968..0460613 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -423,6 +423,15 @@ config VIDEO_TW9906
To compile this driver as a module, choose M here: the
module will be called tw9906.
+config VIDEO_TW9910
+ tristate "Techwell TW9910 video decoder"
+ depends on VIDEO_V4L2 && I2C
+ ---help---
+ Support for Techwell TW9910 NTSC/PAL/SECAM video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9910.
+
config VIDEO_VPX3220
tristate "vpx3220a, vpx3216b & vpx3214c video decoders"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index b0489a1..23c3ac6 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
+obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
obj-$(CONFIG_VIDEO_CS3308) += cs3308.o
obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
index bdb5e0a..96792df 100644
--- a/drivers/media/i2c/tw9910.c
+++ b/drivers/media/i2c/tw9910.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* tw9910 Video Driver
*
+ * Copyright (C) 2017 Jacopo Mondi
+ *
* Copyright (C) 2008 Renesas Solutions Corp.
* Kuninori Morimoto
*
@@ -10,12 +13,10 @@
* Copyright 2006-7 Jonathan Corbet
* Copyright (C) 2008 Magnus Damm
* Copyright (C) 2008, Guennadi Liakhovetski
- *
- * 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.
*/
+#include
+#include
#include
#include
#include
@@ -25,9 +26,7 @@
#include
#include
-#include
#include
-#include
#include
#define GET_ID(val) ((val & 0xF8) >> 3)
@@ -228,8 +227,10 @@ struct tw9910_scale_ctrl {
struct tw9910_priv {
struct v4l2_subdev subdev;
- struct v4l2_clk *clk;
+ struct clk *clk;
struct tw9910_video_info*info;
+ struct gpio_desc*pdn_gpio;
+ struct gpio_desc*rstb_gpio;
const struct tw9910_scale_ctrl *scale;
v4l2_std_id norm;
u32 revision;
@@ -582,13 +583,66 @@ static int tw9910_s_register(struct v4l2_subdev *sd,
}
#endif
+static int tw9910_power_on(struct tw9910_priv *priv)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(>subdev);
+ int ret;
+
+ if (priv->clk) {
+ ret = clk_prepare_enable(priv->clk);
+ if (ret)
+ return ret;
+ }
+
+ if (priv->pdn_gpio) {
+ gpiod_set_value(priv->pdn_gpio, 0);
+ usleep_range(500, 1000);
+ }
+
+ /*
+* FIXME: The reset signal is connected to a shared GPIO on some
+* platforms (namely the SuperH Migo-R). Until a framework becomes
+* available to handle this cleanly, request the GPIO temporarily
+* to avoid conflicts.
+*/
+ priv->rstb_gpio = gpiod_get_optional(>dev, "rstb",
+GPIOD_OUT_LOW);
+ if (IS_ERR(priv->rstb_gpio)) {
+ dev_info(>dev, "Unable to get GPIO \"rstb\"");
+ return PTR_ERR(priv->rstb_gpio);
+ }
+
+ if (priv->rstb_gpio) {
+ gpiod_set_value(priv->rstb_gpio, 1);
+ usleep_range(500, 1000);
+ gpiod_set_value(priv->rstb_gpio, 0);
+ usleep_range(500, 1000);
+
+ gpiod_put(priv->rstb_gpio);
+ }
+
+ return 0;
+}
+
+static int tw9910_power_off(struct tw9910_priv *priv)
+{
+ clk_disable_unprepare(priv->clk);
+
+ if (priv->pdn_gpio) {
+
[PATCH v10 08/10] media: i2c: Copy tw9910 soc_camera sensor driver
Copy the soc_camera based driver in v4l2 sensor driver directory. This commit just copies the original file without modifying it. No modification to KConfig and Makefile as soc_camera framework dependencies need to be removed first in next commit. Signed-off-by: Jacopo Mondi Acked-by: Laurent Pinchart Acked-by: Hans Verkuil --- drivers/media/i2c/tw9910.c | 999 + 1 file changed, 999 insertions(+) create mode 100644 drivers/media/i2c/tw9910.c diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c new file mode 100644 index 000..bdb5e0a --- /dev/null +++ b/drivers/media/i2c/tw9910.c @@ -0,0 +1,999 @@ +/* + * tw9910 Video Driver + * + * Copyright (C) 2008 Renesas Solutions Corp. + * Kuninori Morimoto + * + * Based on ov772x driver, + * + * Copyright (C) 2008 Kuninori Morimoto + * Copyright 2006-7 Jonathan Corbet + * Copyright (C) 2008 Magnus Damm + * Copyright (C) 2008, Guennadi Liakhovetski + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#define GET_ID(val) ((val & 0xF8) >> 3) +#define GET_REV(val) (val & 0x07) + +/* + * register offset + */ +#define ID 0x00 /* Product ID Code Register */ +#define STATUS10x01 /* Chip Status Register I */ +#define INFORM 0x02 /* Input Format */ +#define OPFORM 0x03 /* Output Format Control Register */ +#define DLYCTR 0x04 /* Hysteresis and HSYNC Delay Control */ +#define OUTCTR10x05 /* Output Control I */ +#define ACNTL1 0x06 /* Analog Control Register 1 */ +#define CROP_HI0x07 /* Cropping Register, High */ +#define VDELAY_LO 0x08 /* Vertical Delay Register, Low */ +#define VACTIVE_LO 0x09 /* Vertical Active Register, Low */ +#define HDELAY_LO 0x0A /* Horizontal Delay Register, Low */ +#define HACTIVE_LO 0x0B /* Horizontal Active Register, Low */ +#define CNTRL1 0x0C /* Control Register I */ +#define VSCALE_LO 0x0D /* Vertical Scaling Register, Low */ +#define SCALE_HI 0x0E /* Scaling Register, High */ +#define HSCALE_LO 0x0F /* Horizontal Scaling Register, Low */ +#define BRIGHT 0x10 /* BRIGHTNESS Control Register */ +#define CONTRAST 0x11 /* CONTRAST Control Register */ +#define SHARPNESS 0x12 /* SHARPNESS Control Register I */ +#define SAT_U 0x13 /* Chroma (U) Gain Register */ +#define SAT_V 0x14 /* Chroma (V) Gain Register */ +#define HUE0x15 /* Hue Control Register */ +#define CORING10x17 +#define CORING20x18 /* Coring and IF compensation */ +#define VBICNTL0x19 /* VBI Control Register */ +#define ACNTL2 0x1A /* Analog Control 2 */ +#define OUTCTR20x1B /* Output Control 2 */ +#define SDT0x1C /* Standard Selection */ +#define SDTR 0x1D /* Standard Recognition */ +#define TEST 0x1F /* Test Control Register */ +#define CLMPG 0x20 /* Clamping Gain */ +#define IAGC 0x21 /* Individual AGC Gain */ +#define AGCGAIN0x22 /* AGC Gain */ +#define PEAKWT 0x23 /* White Peak Threshold */ +#define CLMPL 0x24 /* Clamp level */ +#define SYNCT 0x25 /* Sync Amplitude */ +#define MISSCNT0x26 /* Sync Miss Count Register */ +#define PCLAMP 0x27 /* Clamp Position Register */ +#define VCNTL1 0x28 /* Vertical Control I */ +#define VCNTL2 0x29 /* Vertical Control II */ +#define CKILL 0x2A /* Color Killer Level Control */ +#define COMB 0x2B /* Comb Filter Control */ +#define LDLY 0x2C /* Luma Delay and H Filter Control */ +#define MISC1 0x2D /* Miscellaneous Control I */ +#define LOOP 0x2E /* LOOP Control Register */ +#define MISC2 0x2F /* Miscellaneous Control II */ +#define MVSN 0x30 /* Macrovision Detection */ +#define STATUS20x31 /* Chip STATUS II */ +#define HFREF 0x32 /* H monitor */ +#define CLMD 0x33 /* CLAMP MODE */ +#define IDCNTL 0x34 /* ID Detection Control */ +#define CLCNTL10x35 /* Clamp Control I */ +#define ANAPLLCTL 0x4C +#define VBIMIN 0x4D +#define HSLOWCTL 0x4E +#define WSS3 0x4F +#define FILLDATA 0x50 +#define SDID 0x51 +#define DID0x52 +#define WSS1 0x53 +#define WSS2 0x54 +#define VVBI 0x55 +#define LCTL6 0x56 +#define LCTL7 0x57 +#define LCTL8 0x58 +#define LCTL9 0x59 +#define LCTL10 0x5A +#define LCTL11 0x5B +#define LCTL12 0x5C +#define LCTL13
[PATCH v10 07/10] media: i2c: ov772x: Support frame interval handling
Add support to ov772x driver for frame intervals handling and enumeration.
Tested with 10MHz and 24MHz input clock at VGA and QVGA resolutions for
10, 15 and 30 frame per second rates.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
drivers/media/i2c/ov772x.c | 213 +
1 file changed, 196 insertions(+), 17 deletions(-)
diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 23106d7..3edf0cb 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -250,6 +250,7 @@
#define AEC_1p2 0x10 /* 01: 1/2 window */
#define AEC_1p4 0x20 /* 10: 1/4 window */
#define AEC_2p3 0x30 /* 11: Low 2/3 window */
+#define COM4_RESERVED 0x01 /* Reserved bit */
/* COM5 */
#define AFR_ON_OFF 0x80 /* Auto frame rate control ON/OFF selection */
@@ -267,6 +268,10 @@
/* AEC max step control */
#define AEC_NO_LIMIT0x01 /* 0 : AEC incease step has limit */
/* 1 : No limit to AEC increase step */
+/* CLKRC */
+ /* Input clock divider register */
+#define CLKRC_RESERVED 0x80 /* Reserved bit */
+#define CLKRC_DIV(n)((n) - 1)
/* COM7 */
/* SCCB Register Reset */
@@ -373,6 +378,19 @@
#define VERSION(pid, ver) ((pid<<8)|(ver&0xFF))
/*
+ * PLL multipliers
+ */
+static struct {
+ unsigned int mult;
+ u8 com4;
+} ov772x_pll[] = {
+ { 1, PLL_BYPASS, },
+ { 4, PLL_4x, },
+ { 6, PLL_6x, },
+ { 8, PLL_8x, },
+};
+
+/*
* struct
*/
@@ -388,6 +406,7 @@ struct ov772x_color_format {
struct ov772x_win_size {
char *name;
unsigned char com7_bit;
+ unsigned int sizeimage;
struct v4l2_rect rect;
};
@@ -404,6 +423,7 @@ struct ov772x_priv {
unsigned shortflag_hflip:1;
/* band_filter = COM8[5] ? 256 - BDBASE : 0 */
unsigned shortband_filter;
+ unsigned int fps;
};
/*
@@ -487,27 +507,34 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
static const struct ov772x_win_size ov772x_win_sizes[] = {
{
- .name = "VGA",
- .com7_bit = SLCT_VGA,
+ .name = "VGA",
+ .com7_bit = SLCT_VGA,
+ .sizeimage = 510 * 748,
.rect = {
- .left = 140,
- .top = 14,
- .width = VGA_WIDTH,
- .height = VGA_HEIGHT,
+ .left = 140,
+ .top= 14,
+ .width = VGA_WIDTH,
+ .height = VGA_HEIGHT,
},
}, {
- .name = "QVGA",
- .com7_bit = SLCT_QVGA,
+ .name = "QVGA",
+ .com7_bit = SLCT_QVGA,
+ .sizeimage = 278 * 576,
.rect = {
- .left = 252,
- .top = 6,
- .width = QVGA_WIDTH,
- .height = QVGA_HEIGHT,
+ .left = 252,
+ .top= 6,
+ .width = QVGA_WIDTH,
+ .height = QVGA_HEIGHT,
},
},
};
/*
+ * frame rate settings lists
+ */
+static unsigned int ov772x_frame_intervals[] = { 5, 10, 15, 20, 30, 60 };
+
+/*
* general function
*/
@@ -574,6 +601,128 @@ static int ov772x_s_stream(struct v4l2_subdev *sd, int
enable)
return 0;
}
+static int ov772x_set_frame_rate(struct ov772x_priv *priv,
+struct v4l2_fract *tpf,
+const struct ov772x_color_format *cfmt,
+const struct ov772x_win_size *win)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(>subdev);
+ unsigned long fin = clk_get_rate(priv->clk);
+ unsigned int fps = tpf->numerator ?
+ tpf->denominator / tpf->numerator :
+ tpf->denominator;
+ unsigned int best_diff;
+ unsigned int fsize;
+ unsigned int pclk;
+ unsigned int diff;
+ unsigned int idx;
+ unsigned int i;
+ u8 clkrc = 0;
+ u8 com4 = 0;
+ int ret;
+
+ /* Approximate to the closest supported frame interval. */
+ best_diff = ~0L;
+ for (i = 0, idx = 0; i < ARRAY_SIZE(ov772x_frame_intervals); i++) {
+ diff = abs(fps - ov772x_frame_intervals[i]);
+ if (diff < best_diff) {
+ idx = i;
+ best_diff = diff;
+ }
+
[PATCH v10 05/10] media: i2c: Copy ov772x soc_camera sensor driver
Copy the soc_camera based driver in v4l2 sensor driver directory. This commit just copies the original file without modifying it. No modification to KConfig and Makefile as soc_camera framework dependencies need to be removed first in next commit. Signed-off-by: Jacopo Mondi Acked-by: Laurent Pinchart Acked-by: Hans Verkuil --- drivers/media/i2c/ov772x.c | 1124 1 file changed, 1124 insertions(+) create mode 100644 drivers/media/i2c/ov772x.c diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c new file mode 100644 index 000..8063835 --- /dev/null +++ b/drivers/media/i2c/ov772x.c @@ -0,0 +1,1124 @@ +/* + * ov772x Camera Driver + * + * Copyright (C) 2008 Renesas Solutions Corp. + * Kuninori Morimoto + * + * Based on ov7670 and soc_camera_platform driver, + * + * Copyright 2006-7 Jonathan Corbet + * Copyright (C) 2008 Magnus Damm + * Copyright (C) 2008, Guennadi Liakhovetski + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +/* + * register offset + */ +#define GAIN0x00 /* AGC - Gain control gain setting */ +#define BLUE0x01 /* AWB - Blue channel gain setting */ +#define RED 0x02 /* AWB - Red channel gain setting */ +#define GREEN 0x03 /* AWB - Green channel gain setting */ +#define COM10x04 /* Common control 1 */ +#define BAVG0x05 /* U/B Average Level */ +#define GAVG0x06 /* Y/Gb Average Level */ +#define RAVG0x07 /* V/R Average Level */ +#define AECH0x08 /* Exposure Value - AEC MSBs */ +#define COM20x09 /* Common control 2 */ +#define PID 0x0A /* Product ID Number MSB */ +#define VER 0x0B /* Product ID Number LSB */ +#define COM30x0C /* Common control 3 */ +#define COM40x0D /* Common control 4 */ +#define COM50x0E /* Common control 5 */ +#define COM60x0F /* Common control 6 */ +#define AEC 0x10 /* Exposure Value */ +#define CLKRC 0x11 /* Internal clock */ +#define COM70x12 /* Common control 7 */ +#define COM80x13 /* Common control 8 */ +#define COM90x14 /* Common control 9 */ +#define COM10 0x15 /* Common control 10 */ +#define REG16 0x16 /* Register 16 */ +#define HSTART 0x17 /* Horizontal sensor size */ +#define HSIZE 0x18 /* Horizontal frame (HREF column) end high 8-bit */ +#define VSTART 0x19 /* Vertical frame (row) start high 8-bit */ +#define VSIZE 0x1A /* Vertical sensor size */ +#define PSHFT 0x1B /* Data format - pixel delay select */ +#define MIDH0x1C /* Manufacturer ID byte - high */ +#define MIDL0x1D /* Manufacturer ID byte - low */ +#define LAEC0x1F /* Fine AEC value */ +#define COM11 0x20 /* Common control 11 */ +#define BDBASE 0x22 /* Banding filter Minimum AEC value */ +#define DBSTEP 0x23 /* Banding filter Maximum Setp */ +#define AEW 0x24 /* AGC/AEC - Stable operating region (upper limit) */ +#define AEB 0x25 /* AGC/AEC - Stable operating region (lower limit) */ +#define VPT 0x26 /* AGC/AEC Fast mode operating region */ +#define REG28 0x28 /* Register 28 */ +#define HOUTSIZE0x29 /* Horizontal data output size MSBs */ +#define EXHCH 0x2A /* Dummy pixel insert MSB */ +#define EXHCL 0x2B /* Dummy pixel insert LSB */ +#define VOUTSIZE0x2C /* Vertical data output size MSBs */ +#define ADVFL 0x2D /* LSB of insert dummy lines in Vertical direction */ +#define ADVFH 0x2E /* MSG of insert dummy lines in Vertical direction */ +#define YAVE0x2F /* Y/G Channel Average value */ +#define LUMHTH 0x30 /* Histogram AEC/AGC Luminance high level threshold */ +#define LUMLTH 0x31 /* Histogram AEC/AGC Luminance low level threshold */ +#define HREF0x32 /* Image start and size control */ +#define DM_LNL 0x33 /* Dummy line low 8 bits */ +#define DM_LNH 0x34 /* Dummy line high 8 bits */ +#define ADOFF_B 0x35 /* AD offset compensation value for B channel */ +#define ADOFF_R 0x36 /* AD offset compensation value for R channel */ +#define ADOFF_GB0x37 /* AD offset compensation value for Gb channel */ +#define ADOFF_GR0x38 /* AD offset compensation value for Gr channel */ +#define OFF_B 0x39 /* Analog process B channel offset value */ +#define OFF_R 0x3A /* Analog process R channel offset value */ +#define OFF_GB 0x3B /* Analog process Gb channel offset value */ +#define OFF_GR 0x3C /* Analog process Gr channel offset value */ +#define COM12 0x3D /* Common control 12 */ +#define COM13 0x3E /* Common control 13 */ +#define COM14 0x3F /* Common
[PATCH v10 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)
Add Capture Engine Unit (CEU) node to device tree.
Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
arch/arm/boot/dts/r7s72100.dtsi | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index ab9645a..23e05ce 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -135,9 +135,9 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks",
"renesas,cpg-mstp-clocks";
reg = <0xfcfe042c 4>;
- clocks = <_clk>;
- clock-indices = ;
- clock-output-names = "rtc";
+ clocks = <_clk>, <_clk>;
+ clock-indices = ;
+ clock-output-names = "ceu", "rtc";
};
mstp7_clks: mstp7_clks@fcfe0430 {
@@ -667,4 +667,13 @@
power-domains = <_clocks>;
status = "disabled";
};
+
+ ceu: camera@e821 {
+ reg = <0xe821 0x3000>;
+ compatible = "renesas,r7s72100-ceu";
+ interrupts = ;
+ clocks = <_clks R7S72100_CLK_CEU>;
+ power-domains = <_clocks>;
+ status = "disabled";
+ };
};
--
2.7.4
[PATCH v10 02/10] include: media: Add Renesas CEU driver interface
Add renesas-ceu header file.
Do not remove the existing sh_mobile_ceu.h one as long as the original
driver does not go away.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
include/media/drv-intf/renesas-ceu.h | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 include/media/drv-intf/renesas-ceu.h
diff --git a/include/media/drv-intf/renesas-ceu.h
b/include/media/drv-intf/renesas-ceu.h
new file mode 100644
index 000..52841d1
--- /dev/null
+++ b/include/media/drv-intf/renesas-ceu.h
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * renesas-ceu.h - Renesas CEU driver interface
+ *
+ * Copyright 2017-2018 Jacopo Mondi
+ */
+
+#ifndef __MEDIA_DRV_INTF_RENESAS_CEU_H__
+#define __MEDIA_DRV_INTF_RENESAS_CEU_H__
+
+#define CEU_MAX_SUBDEVS2
+
+struct ceu_async_subdev {
+ unsigned long flags;
+ unsigned char bus_width;
+ unsigned char bus_shift;
+ unsigned int i2c_adapter_id;
+ unsigned int i2c_address;
+};
+
+struct ceu_platform_data {
+ unsigned int num_subdevs;
+ struct ceu_async_subdev subdevs[CEU_MAX_SUBDEVS];
+};
+
+#endif /* ___MEDIA_DRV_INTF_RENESAS_CEU_H__ */
--
2.7.4
[PATCH v11 00/10] Renesas Capture Engine Unit (CEU) V4L2 driver
e to new notifier implementation -- Fixed several comments from Hans, Laurent and Sakari - Migo-R -- Register clocks and gpios for sensor drivers in Migo-R setup -- Updated sensors (tw9910 and ov772x) drivers headers and drivers to close remarks from Hans and Laurent: --- Removed platform callbacks and handle clocks and gpios from sensor drivers --- Remove g/s_mbus_config operations Jacopo Mondi (10): dt-bindings: media: Add Renesas CEU bindings include: media: Add Renesas CEU driver interface media: platform: Add Renesas CEU driver ARM: dts: r7s72100: Add Capture Engine Unit (CEU) media: i2c: Copy ov772x soc_camera sensor driver media: i2c: ov772x: Remove soc_camera dependencies media: i2c: ov772x: Support frame interval handling media: i2c: Copy tw9910 soc_camera sensor driver media: i2c: tw9910: Remove soc_camera dependencies arch: sh: migor: Use new renesas-ceu camera driver .../devicetree/bindings/media/renesas,ceu.txt | 81 + arch/arm/boot/dts/r7s72100.dtsi| 15 +- arch/sh/boards/mach-migor/setup.c | 225 ++- arch/sh/kernel/cpu/sh4a/clock-sh7722.c |2 +- drivers/media/i2c/Kconfig | 20 + drivers/media/i2c/Makefile |2 + drivers/media/i2c/ov772x.c | 1365 drivers/media/i2c/tw9910.c | 1039 drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile|1 + drivers/media/platform/renesas-ceu.c | 1675 include/media/drv-intf/renesas-ceu.h | 26 + include/media/i2c/ov772x.h |6 +- include/media/i2c/tw9910.h |9 + 14 files changed, 4344 insertions(+), 131 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt create mode 100644 drivers/media/i2c/ov772x.c create mode 100644 drivers/media/i2c/tw9910.c create mode 100644 drivers/media/platform/renesas-ceu.c create mode 100644 include/media/drv-intf/renesas-ceu.h -- 2.7.4
[PATCH v11 02/10] include: media: Add Renesas CEU driver interface
Add renesas-ceu header file.
Do not remove the existing sh_mobile_ceu.h one as long as the original
driver does not go away.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
include/media/drv-intf/renesas-ceu.h | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 include/media/drv-intf/renesas-ceu.h
diff --git a/include/media/drv-intf/renesas-ceu.h
b/include/media/drv-intf/renesas-ceu.h
new file mode 100644
index 000..52841d1
--- /dev/null
+++ b/include/media/drv-intf/renesas-ceu.h
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * renesas-ceu.h - Renesas CEU driver interface
+ *
+ * Copyright 2017-2018 Jacopo Mondi
+ */
+
+#ifndef __MEDIA_DRV_INTF_RENESAS_CEU_H__
+#define __MEDIA_DRV_INTF_RENESAS_CEU_H__
+
+#define CEU_MAX_SUBDEVS2
+
+struct ceu_async_subdev {
+ unsigned long flags;
+ unsigned char bus_width;
+ unsigned char bus_shift;
+ unsigned int i2c_adapter_id;
+ unsigned int i2c_address;
+};
+
+struct ceu_platform_data {
+ unsigned int num_subdevs;
+ struct ceu_async_subdev subdevs[CEU_MAX_SUBDEVS];
+};
+
+#endif /* ___MEDIA_DRV_INTF_RENESAS_CEU_H__ */
--
2.7.4
[PATCH v11 06/10] media: i2c: ov772x: Remove soc_camera dependencies
Remove soc_camera framework dependencies from ov772x sensor driver.
- Handle clock and gpios
- Register async subdevice
- Remove soc_camera specific g/s_mbus_config operations
- Change image format colorspace from JPEG to SRGB as the two use the
same colorspace information but JPEG makes assumptions on color
components quantization that do not apply to the sensor
- Remove sizes crop from get_selection as driver can't scale
- Add kernel doc to driver interface header file
- Adjust build system
This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera-based CEU driver.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
---
drivers/media/i2c/Kconfig | 11 +++
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/ov772x.c | 172 ++---
include/media/i2c/ov772x.h | 6 +-
4 files changed, 133 insertions(+), 57 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9f18cd2..e71e968 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -645,6 +645,17 @@ config VIDEO_OV5670
To compile this driver as a module, choose M here: the
module will be called ov5670.
+config VIDEO_OV772X
+ tristate "OmniVision OV772x sensor support"
+ depends on I2C && VIDEO_V4L2
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV772x camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov772x.
+
config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index c0f94cd..b0489a1 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 8063835..23106d7 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* ov772x Camera Driver
*
+ * Copyright (C) 2017 Jacopo Mondi
+ *
* Copyright (C) 2008 Renesas Solutions Corp.
* Kuninori Morimoto
*
@@ -9,27 +12,25 @@
* Copyright 2006-7 Jonathan Corbet
* Copyright (C) 2008 Magnus Damm
* Copyright (C) 2008, Guennadi Liakhovetski
- *
- * 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.
*/
+#include
+#include
+#include
+#include
#include
#include
#include
-#include
#include
-#include
#include
#include
#include
-#include
-#include
+
#include
-#include
+#include
#include
+#include
/*
* register offset
@@ -393,8 +394,10 @@ struct ov772x_win_size {
struct ov772x_priv {
struct v4l2_subdevsubdev;
struct v4l2_ctrl_handler hdl;
- struct v4l2_clk *clk;
+ struct clk *clk;
struct ov772x_camera_info*info;
+ struct gpio_desc *pwdn_gpio;
+ struct gpio_desc *rstb_gpio;
const struct ov772x_color_format *cfmt;
const struct ov772x_win_size *win;
unsigned shortflag_vflip:1;
@@ -409,7 +412,7 @@ struct ov772x_priv {
static const struct ov772x_color_format ov772x_cfmts[] = {
{
.code = MEDIA_BUS_FMT_YUYV8_2X8,
- .colorspace = V4L2_COLORSPACE_JPEG,
+ .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3 = 0x0,
.dsp4 = DSP_OFMT_YUV,
.com3 = SWAP_YUV,
@@ -417,7 +420,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
},
{
.code = MEDIA_BUS_FMT_YVYU8_2X8,
- .colorspace = V4L2_COLORSPACE_JPEG,
+ .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3 = UV_ON,
.dsp4 = DSP_OFMT_YUV,
.com3 = SWAP_YUV,
@@ -425,7 +428,7 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
},
{
.code = MEDIA_BUS_FMT_UYVY8_2X8,
- .colorspace = V4L2_COLORSPACE_JPEG,
+ .colorspace = V4L2_COLORSPACE_SRGB,
.dsp3 = 0x0,
.dsp4 = DSP_OFMT_YUV,
.co
[PATCH v11 07/10] media: i2c: ov772x: Support frame interval handling
Add support to ov772x driver for frame intervals handling and enumeration.
Tested with 10MHz and 24MHz input clock at VGA and QVGA resolutions for
10, 15 and 30 frame per second rates.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
drivers/media/i2c/ov772x.c | 213 +
1 file changed, 196 insertions(+), 17 deletions(-)
diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 23106d7..3edf0cb 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -250,6 +250,7 @@
#define AEC_1p2 0x10 /* 01: 1/2 window */
#define AEC_1p4 0x20 /* 10: 1/4 window */
#define AEC_2p3 0x30 /* 11: Low 2/3 window */
+#define COM4_RESERVED 0x01 /* Reserved bit */
/* COM5 */
#define AFR_ON_OFF 0x80 /* Auto frame rate control ON/OFF selection */
@@ -267,6 +268,10 @@
/* AEC max step control */
#define AEC_NO_LIMIT0x01 /* 0 : AEC incease step has limit */
/* 1 : No limit to AEC increase step */
+/* CLKRC */
+ /* Input clock divider register */
+#define CLKRC_RESERVED 0x80 /* Reserved bit */
+#define CLKRC_DIV(n)((n) - 1)
/* COM7 */
/* SCCB Register Reset */
@@ -373,6 +378,19 @@
#define VERSION(pid, ver) ((pid<<8)|(ver&0xFF))
/*
+ * PLL multipliers
+ */
+static struct {
+ unsigned int mult;
+ u8 com4;
+} ov772x_pll[] = {
+ { 1, PLL_BYPASS, },
+ { 4, PLL_4x, },
+ { 6, PLL_6x, },
+ { 8, PLL_8x, },
+};
+
+/*
* struct
*/
@@ -388,6 +406,7 @@ struct ov772x_color_format {
struct ov772x_win_size {
char *name;
unsigned char com7_bit;
+ unsigned int sizeimage;
struct v4l2_rect rect;
};
@@ -404,6 +423,7 @@ struct ov772x_priv {
unsigned shortflag_hflip:1;
/* band_filter = COM8[5] ? 256 - BDBASE : 0 */
unsigned shortband_filter;
+ unsigned int fps;
};
/*
@@ -487,27 +507,34 @@ static const struct ov772x_color_format ov772x_cfmts[] = {
static const struct ov772x_win_size ov772x_win_sizes[] = {
{
- .name = "VGA",
- .com7_bit = SLCT_VGA,
+ .name = "VGA",
+ .com7_bit = SLCT_VGA,
+ .sizeimage = 510 * 748,
.rect = {
- .left = 140,
- .top = 14,
- .width = VGA_WIDTH,
- .height = VGA_HEIGHT,
+ .left = 140,
+ .top= 14,
+ .width = VGA_WIDTH,
+ .height = VGA_HEIGHT,
},
}, {
- .name = "QVGA",
- .com7_bit = SLCT_QVGA,
+ .name = "QVGA",
+ .com7_bit = SLCT_QVGA,
+ .sizeimage = 278 * 576,
.rect = {
- .left = 252,
- .top = 6,
- .width = QVGA_WIDTH,
- .height = QVGA_HEIGHT,
+ .left = 252,
+ .top= 6,
+ .width = QVGA_WIDTH,
+ .height = QVGA_HEIGHT,
},
},
};
/*
+ * frame rate settings lists
+ */
+static unsigned int ov772x_frame_intervals[] = { 5, 10, 15, 20, 30, 60 };
+
+/*
* general function
*/
@@ -574,6 +601,128 @@ static int ov772x_s_stream(struct v4l2_subdev *sd, int
enable)
return 0;
}
+static int ov772x_set_frame_rate(struct ov772x_priv *priv,
+struct v4l2_fract *tpf,
+const struct ov772x_color_format *cfmt,
+const struct ov772x_win_size *win)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(>subdev);
+ unsigned long fin = clk_get_rate(priv->clk);
+ unsigned int fps = tpf->numerator ?
+ tpf->denominator / tpf->numerator :
+ tpf->denominator;
+ unsigned int best_diff;
+ unsigned int fsize;
+ unsigned int pclk;
+ unsigned int diff;
+ unsigned int idx;
+ unsigned int i;
+ u8 clkrc = 0;
+ u8 com4 = 0;
+ int ret;
+
+ /* Approximate to the closest supported frame interval. */
+ best_diff = ~0L;
+ for (i = 0, idx = 0; i < ARRAY_SIZE(ov772x_frame_intervals); i++) {
+ diff = abs(fps - ov772x_frame_intervals[i]);
+ if (diff < best_diff) {
+ idx = i;
+ best_diff = diff;
+ }
+
[PATCH v11 08/10] media: i2c: Copy tw9910 soc_camera sensor driver
Copy the soc_camera based driver in v4l2 sensor driver directory. This commit just copies the original file without modifying it. No modification to KConfig and Makefile as soc_camera framework dependencies need to be removed first in next commit. Signed-off-by: Jacopo Mondi Acked-by: Laurent Pinchart Acked-by: Hans Verkuil --- drivers/media/i2c/tw9910.c | 999 + 1 file changed, 999 insertions(+) create mode 100644 drivers/media/i2c/tw9910.c diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c new file mode 100644 index 000..bdb5e0a --- /dev/null +++ b/drivers/media/i2c/tw9910.c @@ -0,0 +1,999 @@ +/* + * tw9910 Video Driver + * + * Copyright (C) 2008 Renesas Solutions Corp. + * Kuninori Morimoto + * + * Based on ov772x driver, + * + * Copyright (C) 2008 Kuninori Morimoto + * Copyright 2006-7 Jonathan Corbet + * Copyright (C) 2008 Magnus Damm + * Copyright (C) 2008, Guennadi Liakhovetski + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#define GET_ID(val) ((val & 0xF8) >> 3) +#define GET_REV(val) (val & 0x07) + +/* + * register offset + */ +#define ID 0x00 /* Product ID Code Register */ +#define STATUS10x01 /* Chip Status Register I */ +#define INFORM 0x02 /* Input Format */ +#define OPFORM 0x03 /* Output Format Control Register */ +#define DLYCTR 0x04 /* Hysteresis and HSYNC Delay Control */ +#define OUTCTR10x05 /* Output Control I */ +#define ACNTL1 0x06 /* Analog Control Register 1 */ +#define CROP_HI0x07 /* Cropping Register, High */ +#define VDELAY_LO 0x08 /* Vertical Delay Register, Low */ +#define VACTIVE_LO 0x09 /* Vertical Active Register, Low */ +#define HDELAY_LO 0x0A /* Horizontal Delay Register, Low */ +#define HACTIVE_LO 0x0B /* Horizontal Active Register, Low */ +#define CNTRL1 0x0C /* Control Register I */ +#define VSCALE_LO 0x0D /* Vertical Scaling Register, Low */ +#define SCALE_HI 0x0E /* Scaling Register, High */ +#define HSCALE_LO 0x0F /* Horizontal Scaling Register, Low */ +#define BRIGHT 0x10 /* BRIGHTNESS Control Register */ +#define CONTRAST 0x11 /* CONTRAST Control Register */ +#define SHARPNESS 0x12 /* SHARPNESS Control Register I */ +#define SAT_U 0x13 /* Chroma (U) Gain Register */ +#define SAT_V 0x14 /* Chroma (V) Gain Register */ +#define HUE0x15 /* Hue Control Register */ +#define CORING10x17 +#define CORING20x18 /* Coring and IF compensation */ +#define VBICNTL0x19 /* VBI Control Register */ +#define ACNTL2 0x1A /* Analog Control 2 */ +#define OUTCTR20x1B /* Output Control 2 */ +#define SDT0x1C /* Standard Selection */ +#define SDTR 0x1D /* Standard Recognition */ +#define TEST 0x1F /* Test Control Register */ +#define CLMPG 0x20 /* Clamping Gain */ +#define IAGC 0x21 /* Individual AGC Gain */ +#define AGCGAIN0x22 /* AGC Gain */ +#define PEAKWT 0x23 /* White Peak Threshold */ +#define CLMPL 0x24 /* Clamp level */ +#define SYNCT 0x25 /* Sync Amplitude */ +#define MISSCNT0x26 /* Sync Miss Count Register */ +#define PCLAMP 0x27 /* Clamp Position Register */ +#define VCNTL1 0x28 /* Vertical Control I */ +#define VCNTL2 0x29 /* Vertical Control II */ +#define CKILL 0x2A /* Color Killer Level Control */ +#define COMB 0x2B /* Comb Filter Control */ +#define LDLY 0x2C /* Luma Delay and H Filter Control */ +#define MISC1 0x2D /* Miscellaneous Control I */ +#define LOOP 0x2E /* LOOP Control Register */ +#define MISC2 0x2F /* Miscellaneous Control II */ +#define MVSN 0x30 /* Macrovision Detection */ +#define STATUS20x31 /* Chip STATUS II */ +#define HFREF 0x32 /* H monitor */ +#define CLMD 0x33 /* CLAMP MODE */ +#define IDCNTL 0x34 /* ID Detection Control */ +#define CLCNTL10x35 /* Clamp Control I */ +#define ANAPLLCTL 0x4C +#define VBIMIN 0x4D +#define HSLOWCTL 0x4E +#define WSS3 0x4F +#define FILLDATA 0x50 +#define SDID 0x51 +#define DID0x52 +#define WSS1 0x53 +#define WSS2 0x54 +#define VVBI 0x55 +#define LCTL6 0x56 +#define LCTL7 0x57 +#define LCTL8 0x58 +#define LCTL9 0x59 +#define LCTL10 0x5A +#define LCTL11 0x5B +#define LCTL12 0x5C +#define LCTL13
[PATCH v11 10/10] arch: sh: migor: Use new renesas-ceu camera driver
Migo-R platform uses sh_mobile_ceu camera driver, which is now being
replaced by a proper V4L2 camera driver named 'renesas-ceu'.
Move Migo-R platform to use the v4l2 renesas-ceu camera driver
interface and get rid of soc_camera defined components used to register
sensor drivers and of platform specific enable/disable routines.
Register clock source and GPIOs for sensor drivers, so they can use
clock and gpio APIs.
Also, memory for CEU video buffers is now reserved with membocks APIs,
and need to be declared as dma_coherent during machine initialization to
remove that architecture specific part from CEU driver.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
arch/sh/boards/mach-migor/setup.c | 225 +++--
arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +-
2 files changed, 101 insertions(+), 126 deletions(-)
diff --git a/arch/sh/boards/mach-migor/setup.c
b/arch/sh/boards/mach-migor/setup.c
index 0bcbe58..271dfc2 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -1,17 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Renesas System Solutions Asia Pte. Ltd - Migo-R
*
* Copyright (C) 2008 Magnus Damm
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
*/
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -23,10 +22,11 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -45,6 +45,9 @@
* 0x1800 8GB8 NAND Flash (K9K8G08U0A)
*/
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu_dma_membase;
+
static struct smc91x_platdata smc91x_info = {
.flags = SMC91X_USE_16BIT | SMC91X_NOWAIT,
};
@@ -301,65 +304,24 @@ static struct platform_device migor_lcdc_device = {
},
};
-static struct clk *camera_clk;
-static DEFINE_MUTEX(camera_lock);
-
-static void camera_power_on(int is_tw)
-{
- mutex_lock(_lock);
-
- /* Use 10 MHz VIO_CKO instead of 24 MHz to work
-* around signal quality issues on Panel Board V2.1.
-*/
- camera_clk = clk_get(NULL, "video_clk");
- clk_set_rate(camera_clk, 1000);
- clk_enable(camera_clk); /* start VIO_CKO */
-
- /* use VIO_RST to take camera out of reset */
- mdelay(10);
- if (is_tw) {
- gpio_set_value(GPIO_PTT2, 0);
- gpio_set_value(GPIO_PTT0, 0);
- } else {
- gpio_set_value(GPIO_PTT0, 1);
- }
- gpio_set_value(GPIO_PTT3, 0);
- mdelay(10);
- gpio_set_value(GPIO_PTT3, 1);
- mdelay(10); /* wait to let chip come out of reset */
-}
-
-static void camera_power_off(void)
-{
- clk_disable(camera_clk); /* stop VIO_CKO */
- clk_put(camera_clk);
-
- gpio_set_value(GPIO_PTT3, 0);
- mutex_unlock(_lock);
-}
-
-static int ov7725_power(struct device *dev, int mode)
-{
- if (mode)
- camera_power_on(0);
- else
- camera_power_off();
-
- return 0;
-}
-
-static int tw9910_power(struct device *dev, int mode)
-{
- if (mode)
- camera_power_on(1);
- else
- camera_power_off();
-
- return 0;
-}
-
-static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
- .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_platform_data ceu_pdata = {
+ .num_subdevs= 2,
+ .subdevs = {
+ { /* [0] = ov772x */
+ .flags = 0,
+ .bus_width = 8,
+ .bus_shift = 0,
+ .i2c_adapter_id = 0,
+ .i2c_address= 0x21,
+ },
+ { /* [1] = tw9910 */
+ .flags = 0,
+ .bus_width = 8,
+ .bus_shift = 0,
+ .i2c_adapter_id = 0,
+ .i2c_address= 0x45,
+ },
+ },
};
static struct resource migor_ceu_resources[] = {
@@ -373,18 +335,32 @@ static struct resource migor_ceu_resources[] = {
.start = evt2irq(0x880),
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* place holder for contiguous memory */
- },
};
static struct platform_device migor_ceu_device = {
- .name = "sh_mobile_ceu",
- .id = 0, /* "ceu0" clock */
+ .name = "renesas-ceu",
+ .id = 0, /* ceu.0 */
.num_resources = ARRAY_SIZE(migor_ceu_resources),
.resource = migor_ceu_resources,
.dev= {
- .platform_
[PATCH v11 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)
Add Capture Engine Unit (CEU) node to device tree.
Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
arch/arm/boot/dts/r7s72100.dtsi | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index ab9645a..23e05ce 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -135,9 +135,9 @@
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks",
"renesas,cpg-mstp-clocks";
reg = <0xfcfe042c 4>;
- clocks = <_clk>;
- clock-indices = ;
- clock-output-names = "rtc";
+ clocks = <_clk>, <_clk>;
+ clock-indices = ;
+ clock-output-names = "ceu", "rtc";
};
mstp7_clks: mstp7_clks@fcfe0430 {
@@ -667,4 +667,13 @@
power-domains = <_clocks>;
status = "disabled";
};
+
+ ceu: camera@e821 {
+ reg = <0xe821 0x3000>;
+ compatible = "renesas,r7s72100-ceu";
+ interrupts = ;
+ clocks = <_clks R7S72100_CLK_CEU>;
+ power-domains = <_clocks>;
+ status = "disabled";
+ };
};
--
2.7.4
[PATCH v11 03/10] media: platform: Add Renesas CEU driver
Add driver for Renesas Capture Engine Unit (CEU). The CEU interface supports capturing 'data' (YUV422) and 'images' (NV[12|21|16|61]). This driver aims to replace the soc_camera-based sh_mobile_ceu one. Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ platform GR-Peach. Tested with ov7725 camera sensor on SH4 platform Migo-R. Signed-off-by: Jacopo Mondi Reviewed-by: Laurent Pinchart --- drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile |1 + drivers/media/platform/renesas-ceu.c | 1675 ++ 3 files changed, 1685 insertions(+) create mode 100644 drivers/media/platform/renesas-ceu.c diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 614fbef..f9cc058 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -144,6 +144,15 @@ config VIDEO_STM32_DCMI To compile this driver as a module, choose M here: the module will be called stm32-dcmi. +config VIDEO_RENESAS_CEU + tristate "Renesas Capture Engine Unit (CEU) driver" + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA + depends on ARCH_SHMOBILE || ARCH_R7S72100 || COMPILE_TEST + select VIDEOBUF2_DMA_CONTIG + select V4L2_FWNODE + ---help--- + This is a v4l2 driver for the Renesas CEU Interface + source "drivers/media/platform/soc_camera/Kconfig" source "drivers/media/platform/exynos4-is/Kconfig" source "drivers/media/platform/am437x/Kconfig" diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 7f30804..85e1121 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -62,6 +62,7 @@ obj-$(CONFIG_VIDEO_SH_VOU)+= sh_vou.o obj-$(CONFIG_SOC_CAMERA) += soc_camera/ obj-$(CONFIG_VIDEO_RCAR_DRIF) += rcar_drif.o +obj-$(CONFIG_VIDEO_RENESAS_CEU)+= renesas-ceu.o obj-$(CONFIG_VIDEO_RENESAS_FCP)+= rcar-fcp.o obj-$(CONFIG_VIDEO_RENESAS_FDP1) += rcar_fdp1.o obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o diff --git a/drivers/media/platform/renesas-ceu.c b/drivers/media/platform/renesas-ceu.c new file mode 100644 index 000..cfabe1a --- /dev/null +++ b/drivers/media/platform/renesas-ceu.c @@ -0,0 +1,1675 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * V4L2 Driver for Renesas Capture Engine Unit (CEU) interface + * Copyright (C) 2017-2018 Jacopo Mondi + * + * Based on soc-camera driver "soc_camera/sh_mobile_ceu_camera.c" + * Copyright (C) 2008 Magnus Damm + * + * Based on V4L2 Driver for PXA camera host - "pxa_camera.c", + * Copyright (C) 2006, Sascha Hauer, Pengutronix + * Copyright (C) 2008, Guennadi Liakhovetski + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define DRIVER_NAME"renesas-ceu" + +/* CEU registers offsets and masks. */ +#define CEU_CAPSR 0x00 /* Capture start register */ +#define CEU_CAPCR 0x04 /* Capture control register*/ +#define CEU_CAMCR 0x08 /* Capture interface control register */ +#define CEU_CAMOR 0x10 /* Capture interface offset register */ +#define CEU_CAPWR 0x14 /* Capture interface width register*/ +#define CEU_CAIFR 0x18 /* Capture interface input format register */ +#define CEU_CRCNTR 0x28 /* CEU register control register */ +#define CEU_CRCMPR 0x2c /* CEU register forcible control register */ +#define CEU_CFLCR 0x30 /* Capture filter control register */ +#define CEU_CFSZR 0x34 /* Capture filter size clip register */ +#define CEU_CDWDR 0x38 /* Capture destination width register */ +#define CEU_CDAYR 0x3c /* Capture data address Y register */ +#define CEU_CDACR 0x40 /* Capture data address C register */ +#define CEU_CFWCR 0x5c /* Firewall operation control register */ +#define CEU_CDOCR 0x64 /* Capture data output control register*/ +#define CEU_CEIER 0x70 /* Capture event interrupt enable register */ +#define CEU_CETCR 0x74 /* Capture event flag clear register */ +#define CEU_CSTSR 0x7c /* Capture status register */ +#define CEU_CSRTR 0x80 /* Capture software reset register */ + +/* Data synchronous fetch mode. */ +#define CEU_CAMCR_JPEG BIT(4) + +/* Input components ordering: CEU_CAMCR.DTARY field. */ +#define CEU_CAMCR_DTARY_8_UYVY (0x00 << 8) +#define CEU_CAMCR_DTARY_8_VYUY (0x01 << 8) +#define CEU_CAMCR_DTARY_8_YUYV
[PATCH v11 09/10] media: i2c: tw9910: Remove soc_camera dependencies
Remove soc_camera framework dependencies from tw9910 sensor driver.
- Handle clock and gpios
- Register async subdevice
- Remove soc_camera specific g/s_mbus_config operations
- Add kernel doc to driver interface header file
- Adjust build system
This commit does not remove the original soc_camera based driver as long
as other platforms depends on soc_camera-based CEU driver.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
drivers/media/i2c/Kconfig | 9 +++
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/tw9910.c | 162 -
include/media/i2c/tw9910.h | 9 +++
4 files changed, 120 insertions(+), 61 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index e71e968..0460613 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -423,6 +423,15 @@ config VIDEO_TW9906
To compile this driver as a module, choose M here: the
module will be called tw9906.
+config VIDEO_TW9910
+ tristate "Techwell TW9910 video decoder"
+ depends on VIDEO_V4L2 && I2C
+ ---help---
+ Support for Techwell TW9910 NTSC/PAL/SECAM video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9910.
+
config VIDEO_VPX3220
tristate "vpx3220a, vpx3216b & vpx3214c video decoders"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index b0489a1..23c3ac6 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
+obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
obj-$(CONFIG_VIDEO_CS3308) += cs3308.o
obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
diff --git a/drivers/media/i2c/tw9910.c b/drivers/media/i2c/tw9910.c
index bdb5e0a..96792df 100644
--- a/drivers/media/i2c/tw9910.c
+++ b/drivers/media/i2c/tw9910.c
@@ -1,6 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* tw9910 Video Driver
*
+ * Copyright (C) 2017 Jacopo Mondi
+ *
* Copyright (C) 2008 Renesas Solutions Corp.
* Kuninori Morimoto
*
@@ -10,12 +13,10 @@
* Copyright 2006-7 Jonathan Corbet
* Copyright (C) 2008 Magnus Damm
* Copyright (C) 2008, Guennadi Liakhovetski
- *
- * 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.
*/
+#include
+#include
#include
#include
#include
@@ -25,9 +26,7 @@
#include
#include
-#include
#include
-#include
#include
#define GET_ID(val) ((val & 0xF8) >> 3)
@@ -228,8 +227,10 @@ struct tw9910_scale_ctrl {
struct tw9910_priv {
struct v4l2_subdev subdev;
- struct v4l2_clk *clk;
+ struct clk *clk;
struct tw9910_video_info*info;
+ struct gpio_desc*pdn_gpio;
+ struct gpio_desc*rstb_gpio;
const struct tw9910_scale_ctrl *scale;
v4l2_std_id norm;
u32 revision;
@@ -582,13 +583,66 @@ static int tw9910_s_register(struct v4l2_subdev *sd,
}
#endif
+static int tw9910_power_on(struct tw9910_priv *priv)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(>subdev);
+ int ret;
+
+ if (priv->clk) {
+ ret = clk_prepare_enable(priv->clk);
+ if (ret)
+ return ret;
+ }
+
+ if (priv->pdn_gpio) {
+ gpiod_set_value(priv->pdn_gpio, 0);
+ usleep_range(500, 1000);
+ }
+
+ /*
+* FIXME: The reset signal is connected to a shared GPIO on some
+* platforms (namely the SuperH Migo-R). Until a framework becomes
+* available to handle this cleanly, request the GPIO temporarily
+* to avoid conflicts.
+*/
+ priv->rstb_gpio = gpiod_get_optional(>dev, "rstb",
+GPIOD_OUT_LOW);
+ if (IS_ERR(priv->rstb_gpio)) {
+ dev_info(>dev, "Unable to get GPIO \"rstb\"");
+ return PTR_ERR(priv->rstb_gpio);
+ }
+
+ if (priv->rstb_gpio) {
+ gpiod_set_value(priv->rstb_gpio, 1);
+ usleep_range(500, 1000);
+ gpiod_set_value(priv->rstb_gpio, 0);
+ usleep_range(500, 1000);
+
+ gpiod_put(priv->rstb_gpio);
+ }
+
+ return 0;
+}
+
+static int tw9910_power_off(struct tw9910_priv *priv)
+{
+ clk_disable_unprepare(priv->clk);
+
+ if (priv->pdn_gpio) {
+
[PATCH v11 05/10] media: i2c: Copy ov772x soc_camera sensor driver
Copy the soc_camera based driver in v4l2 sensor driver directory. This commit just copies the original file without modifying it. No modification to KConfig and Makefile as soc_camera framework dependencies need to be removed first in next commit. Signed-off-by: Jacopo Mondi Acked-by: Laurent Pinchart Acked-by: Hans Verkuil --- drivers/media/i2c/ov772x.c | 1124 1 file changed, 1124 insertions(+) create mode 100644 drivers/media/i2c/ov772x.c diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c new file mode 100644 index 000..8063835 --- /dev/null +++ b/drivers/media/i2c/ov772x.c @@ -0,0 +1,1124 @@ +/* + * ov772x Camera Driver + * + * Copyright (C) 2008 Renesas Solutions Corp. + * Kuninori Morimoto + * + * Based on ov7670 and soc_camera_platform driver, + * + * Copyright 2006-7 Jonathan Corbet + * Copyright (C) 2008 Magnus Damm + * Copyright (C) 2008, Guennadi Liakhovetski + * + * 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. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +/* + * register offset + */ +#define GAIN0x00 /* AGC - Gain control gain setting */ +#define BLUE0x01 /* AWB - Blue channel gain setting */ +#define RED 0x02 /* AWB - Red channel gain setting */ +#define GREEN 0x03 /* AWB - Green channel gain setting */ +#define COM10x04 /* Common control 1 */ +#define BAVG0x05 /* U/B Average Level */ +#define GAVG0x06 /* Y/Gb Average Level */ +#define RAVG0x07 /* V/R Average Level */ +#define AECH0x08 /* Exposure Value - AEC MSBs */ +#define COM20x09 /* Common control 2 */ +#define PID 0x0A /* Product ID Number MSB */ +#define VER 0x0B /* Product ID Number LSB */ +#define COM30x0C /* Common control 3 */ +#define COM40x0D /* Common control 4 */ +#define COM50x0E /* Common control 5 */ +#define COM60x0F /* Common control 6 */ +#define AEC 0x10 /* Exposure Value */ +#define CLKRC 0x11 /* Internal clock */ +#define COM70x12 /* Common control 7 */ +#define COM80x13 /* Common control 8 */ +#define COM90x14 /* Common control 9 */ +#define COM10 0x15 /* Common control 10 */ +#define REG16 0x16 /* Register 16 */ +#define HSTART 0x17 /* Horizontal sensor size */ +#define HSIZE 0x18 /* Horizontal frame (HREF column) end high 8-bit */ +#define VSTART 0x19 /* Vertical frame (row) start high 8-bit */ +#define VSIZE 0x1A /* Vertical sensor size */ +#define PSHFT 0x1B /* Data format - pixel delay select */ +#define MIDH0x1C /* Manufacturer ID byte - high */ +#define MIDL0x1D /* Manufacturer ID byte - low */ +#define LAEC0x1F /* Fine AEC value */ +#define COM11 0x20 /* Common control 11 */ +#define BDBASE 0x22 /* Banding filter Minimum AEC value */ +#define DBSTEP 0x23 /* Banding filter Maximum Setp */ +#define AEW 0x24 /* AGC/AEC - Stable operating region (upper limit) */ +#define AEB 0x25 /* AGC/AEC - Stable operating region (lower limit) */ +#define VPT 0x26 /* AGC/AEC Fast mode operating region */ +#define REG28 0x28 /* Register 28 */ +#define HOUTSIZE0x29 /* Horizontal data output size MSBs */ +#define EXHCH 0x2A /* Dummy pixel insert MSB */ +#define EXHCL 0x2B /* Dummy pixel insert LSB */ +#define VOUTSIZE0x2C /* Vertical data output size MSBs */ +#define ADVFL 0x2D /* LSB of insert dummy lines in Vertical direction */ +#define ADVFH 0x2E /* MSG of insert dummy lines in Vertical direction */ +#define YAVE0x2F /* Y/G Channel Average value */ +#define LUMHTH 0x30 /* Histogram AEC/AGC Luminance high level threshold */ +#define LUMLTH 0x31 /* Histogram AEC/AGC Luminance low level threshold */ +#define HREF0x32 /* Image start and size control */ +#define DM_LNL 0x33 /* Dummy line low 8 bits */ +#define DM_LNH 0x34 /* Dummy line high 8 bits */ +#define ADOFF_B 0x35 /* AD offset compensation value for B channel */ +#define ADOFF_R 0x36 /* AD offset compensation value for R channel */ +#define ADOFF_GB0x37 /* AD offset compensation value for Gb channel */ +#define ADOFF_GR0x38 /* AD offset compensation value for Gr channel */ +#define OFF_B 0x39 /* Analog process B channel offset value */ +#define OFF_R 0x3A /* Analog process R channel offset value */ +#define OFF_GB 0x3B /* Analog process Gb channel offset value */ +#define OFF_GR 0x3C /* Analog process Gr channel offset value */ +#define COM12 0x3D /* Common control 12 */ +#define COM13 0x3E /* Common control 13 */ +#define COM14 0x3F /* Common
[PATCH v11 01/10] dt-bindings: media: Add Renesas CEU bindings
Add bindings documentation for Renesas Capture Engine Unit (CEU).
Signed-off-by: Jacopo Mondi
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
.../devicetree/bindings/media/renesas,ceu.txt | 81 ++
1 file changed, 81 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/renesas,ceu.txt
diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.txt
b/Documentation/devicetree/bindings/media/renesas,ceu.txt
new file mode 100644
index 000..3fc66df
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.txt
@@ -0,0 +1,81 @@
+Renesas Capture Engine Unit (CEU)
+--
+
+The Capture Engine Unit is the image capture interface found in the Renesas
+SH Mobile and RZ SoCs.
+
+The interface supports a single parallel input with data bus width of 8 or 16
+bits.
+
+Required properties:
+- compatible: Shall be "renesas,r7s72100-ceu" for CEU units found in RZ/A1H
+ and RZ/A1M SoCs.
+- reg: Registers address base and size.
+- interrupts: The interrupt specifier.
+
+The CEU supports a single parallel input and should contain a single 'port'
+subnode with a single 'endpoint'. Connection to input devices are modeled
+according to the video interfaces OF bindings specified in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Optional endpoint properties applicable to parallel input bus described in
+the above mentioned "video-interfaces.txt" file are supported.
+
+- hsync-active: Active state of the HSYNC signal, 0/1 for LOW/HIGH
respectively.
+ If property is not present, default is active high.
+- vsync-active: Active state of the VSYNC signal, 0/1 for LOW/HIGH
respectively.
+ If property is not present, default is active high.
+
+Example:
+
+The example describes the connection between the Capture Engine Unit and an
+OV7670 image sensor connected to i2c1 interface.
+
+ceu: ceu@e821 {
+ reg = <0xe821 0x209c>;
+ compatible = "renesas,r7s72100-ceu";
+ interrupts = ;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+
+ port {
+ ceu_in: endpoint {
+ remote-endpoint = <_out>;
+
+ hsync-active = <1>;
+ vsync-active = <0>;
+ };
+ };
+};
+
+i2c1: i2c@fcfee400 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+
+ clock-frequency = <10>;
+
+ ov7670: camera@21 {
+ compatible = "ovti,ov7670";
+ reg = <0x21>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ reset-gpios = < 11 GPIO_ACTIVE_LOW>;
+ powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov7670_out: endpoint {
+ remote-endpoint = <_in>;
+
+ hsync-active = <1>;
+ vsync-active = <0>;
+ };
+ };
+ };
+};
--
2.7.4
