Re: [PATCH v6 1/2] pinctrl: Add RZ/A2 pin and gpio controller
Hi Chris,
On Thu, Nov 15, 2018 at 09:00:44AM -0500, Chris Brandt wrote:
> Adds support for the pin and gpio controller found in R7S9210 (RZ/A2) SoCs.
>
> Signed-off-by: Chris Brandt
> Reviewed-by: Jacopo Mondi
> ---
> v5:
> * Specify number of ports using of_device_id.data and save as priv->npins
> * Use priv->npins everywhere instead of hard coded RZA2_NPINS
> * Check gpio-ranges to make sure args matches SOC
Sorry about this, I didn't want to ask you to do this now, it might
have had post-poned to when a new SoC will have to be supported, but..
[snip]
> +
> +static const struct of_device_id rza2_pinctrl_of_match[] = {
> + { .compatible = "renesas,r7s9210-pinctrl", .data = (void *)22, },
... I really don't like this, I'm sorry.
I would rather make a 'struct rza_pinctrl_info' or similar which
contains all the fields you now hardcode (number of ports, pins per
port etc) and which is easily extensible in case you need to do so.
I'm sorry this is more work, and again, it might be post-poned imo,
provided you drop this change you have introduced here.
Thanks
j
> + { /* sentinel */ }
> +};
> +
> +static struct platform_driver rza2_pinctrl_driver = {
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = rza2_pinctrl_of_match,
> + },
> + .probe = rza2_pinctrl_probe,
> +};
> +
> +static int __init rza2_pinctrl_init(void)
> +{
> + return platform_driver_register(_pinctrl_driver);
> +}
> +core_initcall(rza2_pinctrl_init);
> +
> +MODULE_AUTHOR("Chris Brandt ");
> +MODULE_DESCRIPTION("Pin and gpio controller driver for RZ/A2 SoC");
> +MODULE_LICENSE("GPL v2");
> --
> 2.16.1
>
signature.asc
Description: PGP signature
Re: [PATCH v4 1/2] pinctrl: Add RZ/A2 pin and gpio controller
ret = of_property_read_u32_index(np, "pinmux", i, );
> + if (ret)
> + return ret;
> + pins[i] = value & MUX_PIN_ID_MASK;
> + psel_val[i] = MUX_FUNC(value);
> + }
> +
> + /* Register a single pin group listing all the pins we read from DT */
> + gsel = pinctrl_generic_add_group(pctldev, np->name, pins, npins, NULL);
> + if (gsel < 0)
> + return gsel;
> +
> + /*
> + * Register a single group function where the 'data' is an array PSEL
> + * register values read from DT.
> + */
> + pin_fn[0] = np->name;
> + fsel = pinmux_generic_add_function(pctldev, np->name, pin_fn, 1,
> +psel_val);
> + if (fsel < 0) {
> + ret = fsel;
> + goto remove_group;
> + }
> +
> + dev_dbg(priv->dev, "Parsed %s with %d pins\n", np->name, npins);
> +
> + /* Create map where to retrieve function and mux settings from */
> + *num_maps = 0;
> + *map = kzalloc(sizeof(**map), GFP_KERNEL);
> + if (!*map) {
> + ret = -ENOMEM;
> + goto remove_function;
> + }
> +
> + (*map)->type = PIN_MAP_TYPE_MUX_GROUP;
> + (*map)->data.mux.group = np->name;
> + (*map)->data.mux.function = np->name;
> + *num_maps = 1;
> +
> + return 0;
> +
> +remove_function:
> + pinmux_generic_remove_function(pctldev, fsel);
> +
> +remove_group:
> + pinctrl_generic_remove_group(pctldev, gsel);
> +
> + dev_info(priv->dev, "Unable to parse DT node %s\n", np->name);
> +
> + return ret;
> +}
> +
> +static void rza2_dt_free_map(struct pinctrl_dev *pctldev,
> + struct pinctrl_map *map, unsigned int num_maps)
> +{
> + kfree(map);
> +}
> +
> +static const struct pinctrl_ops rza2_pinctrl_ops = {
> + .get_groups_count = pinctrl_generic_get_group_count,
> + .get_group_name = pinctrl_generic_get_group_name,
> + .get_group_pins = pinctrl_generic_get_group_pins,
> + .dt_node_to_map = rza2_dt_node_to_map,
> + .dt_free_map= rza2_dt_free_map,
> +};
> +
> +static int rza2_set_mux(struct pinctrl_dev *pctldev, unsigned int selector,
> +unsigned int group)
> +{
> + struct rza2_pinctrl_priv *priv = pinctrl_dev_get_drvdata(pctldev);
> + struct function_desc *func;
> + struct group_desc *grp;
> + int i;
> + unsigned int *psel_val;
> +
> + grp = pinctrl_generic_get_group(pctldev, group);
> + if (!grp)
> + return -EINVAL;
> +
> + func = pinmux_generic_get_function(pctldev, selector);
> + if (!func)
> + return -EINVAL;
> +
> + psel_val = func->data;
> +
> + for (i = 0; i < grp->num_pins; ++i) {
> + dev_dbg(priv->dev, "Setting P%c_%d to PSEL=%d\n",
> + port_names[RZA2_PIN_ID_TO_PORT(grp->pins[i])],
> + RZA2_PIN_ID_TO_PIN(grp->pins[i]),
> + psel_val[i]);
> + rza2_set_pin_function(
> + priv->base,
> + RZA2_PIN_ID_TO_PORT(grp->pins[i]),
> + RZA2_PIN_ID_TO_PIN(grp->pins[i]),
> + psel_val[i]);
> + }
> +
> + return 0;
> +}
> +
> +static const struct pinmux_ops rza2_pinmux_ops = {
> + .get_functions_count= pinmux_generic_get_function_count,
> + .get_function_name = pinmux_generic_get_function_name,
> + .get_function_groups= pinmux_generic_get_function_groups,
> + .set_mux= rza2_set_mux,
> + .strict = true,
> +};
> +
> +static int rza2_pinctrl_probe(struct platform_device *pdev)
> +{
> + struct rza2_pinctrl_priv *priv;
> + struct resource *res;
> + int ret;
> +
> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = >dev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + priv->base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(priv->base))
> + return PTR_ERR(priv->base);
> +
> + platform_set_drvdata(pdev, priv);
> +
> + priv->desc.name = DRIVER_NAME;
> + priv->desc.pctlops = _pinctrl_ops;
> + priv->desc.pmxops = _pinmux_ops;
> + priv->desc.owner= THIS_MODULE;
> +
> + ret = rza2_pinctrl_register(priv);
> + if (ret)
> + return ret;
> +
> + pr_info("RZ/A2 pin controller registered\n");
nit: dev_info
> +
> + return 0;
> +}
> +
> +static const struct of_device_id rza2_pinctrl_of_match[] = {
> + {
> + .compatible = "renesas,r7s9210-pinctrl",
> + },
> + { /* sentinel */ }
> +};
> +
> +static struct platform_driver rza2_pinctrl_driver = {
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = rza2_pinctrl_of_match,
> + },
> + .probe = rza2_pinctrl_probe,
> +};
> +
> +static int __init rza2_pinctrl_init(void)
> +{
> + return platform_driver_register(_pinctrl_driver);
> +}
> +core_initcall(rza2_pinctrl_init);
> +
> +
nit: multiple empty lines
With this minor fixed, please add my
Reviewed-by: Jacopo Mondi
Thanks
j
> +MODULE_AUTHOR("Chris Brandt ");
> +MODULE_DESCRIPTION("Pin and gpio controller driver for RZ/A2 SoC");
> +MODULE_LICENSE("GPL v2");
> --
> 2.16.1
>
signature.asc
Description: PGP signature
Re: [PATCH v4 2/2] dt-bindings: pinctrl: Add RZ/A2 pinctrl and GPIO
Hi Chris,
thanks for the patch
Just two minor things, so please add my
Reviewed-by: Jacopo Mondi
On Wed, Nov 07, 2018 at 01:27:33PM -0500, Chris Brandt wrote:
> Add device tree binding documentation and header file for Renesas R7S9210
> (RZ/A2) SoCs.
>
> Signed-off-by: Chris Brandt
> Reviewed-by: Rob Herring
> ---
> v3:
> - Added Reviewed-by
> v2:
> * Moved gpio-controller to required
> * Wrote a better description of what the sub-nodes are for
> * Added pinmux property description
> * Changed macro RZA2_PIN_ID to RZA2_PIN
> ---
> .../bindings/pinctrl/renesas,rza2-pinctrl.txt | 88
> ++
> include/dt-bindings/pinctrl/r7s9210-pinctrl.h | 47
> 2 files changed, 135 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> create mode 100644 include/dt-bindings/pinctrl/r7s9210-pinctrl.h
>
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> new file mode 100644
> index ..622d37a7225b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> @@ -0,0 +1,88 @@
> +Renesas RZ/A2 combined Pin and GPIO controller
> +
> +The Renesas SoCs of the RZ/A2 series feature a combined Pin and GPIO
> controller.
> +Pin multiplexing and GPIO configuration is performed on a per-pin basis.
> +Each port features up to 8 pins, each of them configurable for GPIO
> +function (port mode) or in alternate function mode.
> +Up to 8 different alternate function modes exist for each single pin.
> +
> +Pin controller node
> +---
> +
> +Required properties:
> + - compatible: should be:
s/should/shall ?
> +- "renesas,r7s9210-pinctrl": for RZ/A2M
> + - reg
> +Address base and length of the memory area where the pin controller
> +hardware is mapped to.
> + - gpio-controller
> +This pin controller also controls pins as GPIO
> + - #gpio-cells
> +Must be 2
> + - gpio-ranges
> +Expresses the total number GPIO ports/pins in this SoC
> +
> +
Two empty lines.
Thanks
j
> +Example: Pin controller node for RZ/A2M SoC (r7s9210)
> +
> + pinctrl: pin-controller@fcffe000 {
> + compatible = "renesas,r7s9210-pinctrl";
> + reg = <0xfcffe000 0x9D1>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = < 0 0 176>;
> + };
> +
> +Sub-nodes
> +-
> +
> +The child nodes of the pin controller designate pins to be used for
> +specific peripheral functions or as GPIO.
> +
> +- Pin multiplexing sub-nodes:
> + A pin multiplexing sub-node describes how to configure a set of
> + (or a single) pin in some desired alternate function mode.
> + The values for the pinmux properties are a combination of port name, pin
> + number and the desired function index. Use the RZA2_PINMUX macro located
> + in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily define these.
> + For assigning GPIO pins, use the macro RZA2_PIN_ID also in
> r7s9210-pinctrl.h
> + to express the desired port pin.
> +
> + Required properties:
> +- pinmux:
> + integer array representing pin number and pin multiplexing
> configuration.
> + When a pin has to be configured in alternate function mode, use this
> + property to identify the pin by its global index, and provide its
> + alternate function configuration number along with it.
> + When multiple pins are required to be configured as part of the same
> + alternate function they shall be specified as members of the same
> + argument list of a single "pinmux" property.
> + Helper macros to ease assembling the pin index from its position
> + (port where it sits on and pin number) and alternate function
> identifier
> + are provided by the pin controller header file at:
> +
> + Integers values in "pinmux" argument list are assembled as:
> + ((PORT * 8 + PIN) | MUX_FUNC << 16)
> +
> + Example: Board specific pins configuration
> +
> + {
> + /* Serial Console */
> + scif4_pins: serial4 {
> + pinmux = , /* TxD4 */
> + ; /* RxD4 */
> + };
> + };
> +
> + Example: Assigning a GPIO:
> +
> + leds {
> + status = "okay";
> + compatible = "gpio-leds";
> +
> + led0 {
> + /* P6_0 */
> +
[PATCH v5 3/6] pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions
Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car E3.
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Use new variadic macro: this time for real as reported by Simon
- s/union vin_data/union vin_data16/ for VIN5 pins and mux as suggested by Geert
- add vin4_data18_[a|b] pins
- fix VIN4_DATA19 pin number in vin4_data_b group
v3 -> v4:
- Use new variadic version of VIN_DATA_PIN_GROUP macro
v2 -> v3:
- Rebased on v4.20-rc1
- Use the newly introduced VIN_DATA_PIN_GROUP_VER macro
Incorporate Geert's comments:
- vin5_data8_b is only used with 8 pins: use regular SH_PFC_PIN_GROUP()
- remove stf groups for vin4/vin5
- confirmed that pins [23-8] of vin4's groups 'a' and 'b' are shared
- confirmed with HW team the synchronism pins in vin5 are only for group 'a'
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 300 +-
1 file changed, 298 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 923261687a75..1a2cf73a84ad 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -2786,8 +2786,240 @@ static const unsigned int usb30_id_mux[] = {
USB3HS0_ID_MARK,
};
+/* - VIN4 ---
*/
+static const unsigned int vin4_data18_a_pins[] = {
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+};
+
+static const unsigned int vin4_data18_a_mux[] = {
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+};
+
+static const union vin_data vin4_data_a_pins = {
+ .data24 = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_a_mux = {
+ .data24 = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const unsigned int vin4_data18_b_pins[] = {
+ RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
+ RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
+ RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+};
+
+static const unsigned int vin4_data18_b_mux[] = {
+ VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+ VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+ VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+};
+
+static const union vin_data vin4_data_b_pins = {
+ .data24 = {
+ RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
+ RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
+ RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
+ RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
+ RCAR_GP_PIN(1, 4), RCAR_GP
[PATCH v5 4/6] pinctrl: sh-pfc: r8a7792: Fix VIN versioned groups
Versioned VIN groups can appear on different sets of pins. Use of the
VIN_DATA_PIN_GROUP macro fix naming of said groups through an optional
'version' argument.
Use the 'version' argument for said macro to fix naming of versioned
groups for R-Car V2H R8A7792 SoC.
Fixes: 7dd74bb1f058 ("pinctrl: sh-pfc: r8a7792: Add VIN pin groups")
Reviewed-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Broke out r8a7792 from single patch
---
drivers/pinctrl/sh-pfc/pfc-r8a7792.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
index e977121b433b..a623459b234e 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
@@ -1744,10 +1744,10 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
VIN_DATA_PIN_GROUP(vin1_data, 12),
VIN_DATA_PIN_GROUP(vin1_data, 10),
VIN_DATA_PIN_GROUP(vin1_data, 8),
- VIN_DATA_PIN_GROUP(vin1_data_b, 24),
- VIN_DATA_PIN_GROUP(vin1_data_b, 20),
+ VIN_DATA_PIN_GROUP(vin1_data, 24, _b),
+ VIN_DATA_PIN_GROUP(vin1_data, 20, _b),
SH_PFC_PIN_GROUP(vin1_data18_b),
- VIN_DATA_PIN_GROUP(vin1_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin1_data, 16, _b),
SH_PFC_PIN_GROUP(vin1_sync),
SH_PFC_PIN_GROUP(vin1_field),
SH_PFC_PIN_GROUP(vin1_clkenb),
--
2.7.4
[PATCH v5 5/6] pinctrl: sh-pfc: r8a7795: Fix VIN versioned groups
Versioned VIN groups can appear on different sets of pins. Use of the
VIN_DATA_PIN_GROUP macro fix naming of said groups through an optional
'version' argument.
Use the 'version' argument for said macro to fix naming of versioned
groups for R-Car H3 R8A7795 SoC.
Fixes: 9942a5b52990 ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
definitions")
Reviewed-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Broke out r8a7795 from single patch
---
drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index 0af737d11403..20fac0fde91a 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -4474,20 +4474,20 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(usb2),
SH_PFC_PIN_GROUP(usb2_ch3),
SH_PFC_PIN_GROUP(usb30),
- VIN_DATA_PIN_GROUP(vin4_data_a, 8),
- VIN_DATA_PIN_GROUP(vin4_data_a, 10),
- VIN_DATA_PIN_GROUP(vin4_data_a, 12),
- VIN_DATA_PIN_GROUP(vin4_data_a, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _a),
SH_PFC_PIN_GROUP(vin4_data18_a),
- VIN_DATA_PIN_GROUP(vin4_data_a, 20),
- VIN_DATA_PIN_GROUP(vin4_data_a, 24),
- VIN_DATA_PIN_GROUP(vin4_data_b, 8),
- VIN_DATA_PIN_GROUP(vin4_data_b, 10),
- VIN_DATA_PIN_GROUP(vin4_data_b, 12),
- VIN_DATA_PIN_GROUP(vin4_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _b),
SH_PFC_PIN_GROUP(vin4_data18_b),
- VIN_DATA_PIN_GROUP(vin4_data_b, 20),
- VIN_DATA_PIN_GROUP(vin4_data_b, 24),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _b),
SH_PFC_PIN_GROUP(vin4_sync),
SH_PFC_PIN_GROUP(vin4_field),
SH_PFC_PIN_GROUP(vin4_clkenb),
--
2.7.4
[PATCH v5 0/6] sh-pfc: Variadic VIN_DATA_PIN_GROUP macro + VIN updates
Hi Geert, Simon, this version uses the new variadic macro VIN_DATA_PIN_GROUP as v4 (this for real in [3/6]. Refactoring of users of the macro old version have broken out to single patches, comments on M3-N and E3 VIN PFC groups have been incorporated. Quite a few changes in M3-N and E3 VIN support in PFC, so the single patches changelog is in commit messages. Thanks j Jacopo Mondi (6): pinctrl: sh-pfc: Add optional arg to VIN_DATA_PIN_GROUP pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions pinctrl: sh-pfc: r8a7792: Fix VIN versioned groups pinctrl: sh-pfc: r8a7795: Fix VIN versioned groups pinctrl: sh-pfc: r8a7796: Fix VIN versioned groups drivers/pinctrl/sh-pfc/pfc-r8a7792.c | 6 +- drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 24 +-- drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 24 +-- drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 270 ++ drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 244 ++ drivers/pinctrl/sh-pfc/sh_pfc.h | 15 +- 6 files changed, 549 insertions(+), 34 deletions(-) -- 2.7.4
[PATCH v5 6/6] pinctrl: sh-pfc: r8a7796: Fix VIN versioned groups
Versioned VIN groups can appear on different sets of pins. Using the
VIN_DATA_PIN_GROUP macro now supports proper naming of said groups through
an optional 'version' argument.
Use the 'version' argument for said macro to fix naming of versioned
groups for R-Car M3-W R8A7796 SoC.
Fixes: a5c2949ff7bd ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
definitions")
Reviewed-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Broke out r8a7796 from single patch
---
drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
index 3a6d21d87107..b003abdd1a74 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
@@ -4409,20 +4409,20 @@ static const struct {
SH_PFC_PIN_GROUP(usb0),
SH_PFC_PIN_GROUP(usb1),
SH_PFC_PIN_GROUP(usb30),
- VIN_DATA_PIN_GROUP(vin4_data_a, 8),
- VIN_DATA_PIN_GROUP(vin4_data_a, 10),
- VIN_DATA_PIN_GROUP(vin4_data_a, 12),
- VIN_DATA_PIN_GROUP(vin4_data_a, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _a),
SH_PFC_PIN_GROUP(vin4_data18_a),
- VIN_DATA_PIN_GROUP(vin4_data_a, 20),
- VIN_DATA_PIN_GROUP(vin4_data_a, 24),
- VIN_DATA_PIN_GROUP(vin4_data_b, 8),
- VIN_DATA_PIN_GROUP(vin4_data_b, 10),
- VIN_DATA_PIN_GROUP(vin4_data_b, 12),
- VIN_DATA_PIN_GROUP(vin4_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _b),
SH_PFC_PIN_GROUP(vin4_data18_b),
- VIN_DATA_PIN_GROUP(vin4_data_b, 20),
- VIN_DATA_PIN_GROUP(vin4_data_b, 24),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _b),
SH_PFC_PIN_GROUP(vin4_sync),
SH_PFC_PIN_GROUP(vin4_field),
SH_PFC_PIN_GROUP(vin4_clkenb),
--
2.7.4
[PATCH v5 1/6] pinctrl: sh-pfc: Add optional arg to VIN_DATA_PIN_GROUP
VIN data groups may appear on different sets of pins, usually named
"vinX_data_[a|b]". The existing VIN_DATA_PIN_GROUP() does not support
appending the '_a' or '_b' suffix, leading to the definition of group
names not consistent with the ones defined using the SH_PFC_PIN_GROUP()
macro.
Fix this by making the VIN_DATA_PIN_GROUP macro a variadic one,
which accepts an optional 'version' argument.
Fixes: 423caa52534f ("pinctrl: sh-pfc: r8a779[01]: Move 'union vin_data' to
shared header file")
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Rebased on sh-pfc-for-v4.21
- Add fixes tag
---
drivers/pinctrl/sh-pfc/sh_pfc.h | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index 1fc13366869a..4ef485cfe08d 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -55,14 +55,15 @@ struct sh_pfc_pin_group {
/*
* Using union vin_data{,12,16} saves memory occupied by the VIN data pins.
* VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups
- * in this case.
+ * in this case. It accepts an optional 'version' argument used when the
+ * same group can appear on a different set of pins.
*/
-#define VIN_DATA_PIN_GROUP(n, s) \
- { \
- .name = #n#s, \
- .pins = n##_pins.data##s, \
- .mux = n##_mux.data##s, \
- .nr_pins = ARRAY_SIZE(n##_pins.data##s),\
+#define VIN_DATA_PIN_GROUP(n, s, ...) \
+ { \
+ .name = #n#s#__VA_ARGS__, \
+ .pins = n##__VA_ARGS__##_pins.data##s, \
+ .mux = n##__VA_ARGS__##_mux.data##s,\
+ .nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s), \
}
union vin_data12 {
--
2.7.4
[PATCH v5 2/6] pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions
The VIN4 and VIN5 interfaces supports parallel video input.
Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car M3-N.
Reviewed-by: Ulrich Hecht
Signed-off-by: Jacopo Mondi
---
v4 -> v5:
- Add definitions for 10, 12 and 20 pin groups for VIN4 as suggested by Geert
- Add definitions for 10 and 12 pin groups for VIN5 as suggested by Geert
- s/union vin_data/union vin_data16/ for VIN5 pins and mux as suggested by Geert
---
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 270 ++
1 file changed, 270 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
index dfdd982984d4..0159e80d29c3 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77965.c
@@ -3725,6 +3725,216 @@ static const unsigned int usb30_mux[] = {
USB30_PWEN_MARK, USB30_OVC_MARK,
};
+/* - VIN4 ---
*/
+static const unsigned int vin4_data18_a_pins[] = {
+ RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+ RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
+};
+
+static const unsigned int vin4_data18_a_mux[] = {
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+};
+
+static const union vin_data vin4_data_a_pins = {
+ .data24 = {
+ RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 9),
+ RCAR_GP_PIN(0, 10), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+ RCAR_GP_PIN(0, 14), RCAR_GP_PIN(0, 15),
+ RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
+ },
+};
+
+static const union vin_data vin4_data_a_mux = {
+ .data24 = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const unsigned int vin4_data18_b_pins[] = {
+ RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),
+ RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5),
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0, 7),
+};
+
+static const unsigned int vin4_data18_b_mux[] = {
+ VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+ VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+ VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+};
+
+static const union vin_data vin4_data_b_pins = {
+ .data24 = {
+ RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
+ RCAR_GP_PIN(2, 2), RCAR_GP_PIN(2, 3),
+ RCAR_GP_PIN(2, 4), RCAR_GP_PIN(2, 5),
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(1, 0), RCAR_GP_PIN(1, 1),
+ RCAR_GP_PIN(1, 2), RCAR_GP_PIN(1, 3),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(0, 0), RCAR_GP_PIN(0, 1),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ RCAR_GP_PIN(0, 4), RCAR_GP_PIN(0, 5),
+ RCAR_GP_PIN(0, 6), RCAR_GP_PIN(0
Re: [PATCH v4 2/4] pinctrl: sh-pfc: Fix VIN versioned groups name
Hi Geert
On Thu, Nov 08, 2018 at 11:59:08AM +0100, Geert Uytterhoeven wrote:
> On Tue, Nov 6, 2018 at 11:35 AM Jacopo Mondi
> wrote:
> > Versioned VIN groups can appear on different sets of pins. Using the
> > VIN_DATA_PIN_GROUP macro now supports proper naming of said groups through
> > an optional 'version' argument.
> >
> > Use the 'version' argument for said macro to fix naming of versioned
> > groups for R-Car SoCs that defines them.
> >
> > Signed-off-by: Jacopo Mondi
>
> Fixes: 7dd74bb1f058786e ("pinctrl: sh-pfc: r8a7792: Add VIN pin groups")
> Fixes: a5c2949ff7bd9e04 ("pinctrl: sh-pfc: r8a7796: Deduplicate VIN4 pin
> Fixes: 9942a5b52990b8d5 ("pinctrl: sh-pfc: r8a7795: Deduplicate VIN4 pin
> Reviewed-by: Geert Uytterhoeven
I added the Fixes tag to the single patches I've broke out and will
send in v5.
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
signature.asc
Description: PGP signature
Re: [PATCH v4 2/4] pinctrl: sh-pfc: Fix VIN versioned groups name
Hi Simon, On Wed, Nov 07, 2018 at 11:41:34AM +0100, Simon Horman wrote: > On Tue, Nov 06, 2018 at 11:35:31AM +0100, Jacopo Mondi wrote: > > Versioned VIN groups can appear on different sets of pins. Using the > > VIN_DATA_PIN_GROUP macro now supports proper naming of said groups through > > an optional 'version' argument. > > > > Use the 'version' argument for said macro to fix naming of versioned > > groups for R-Car SoCs that defines them. > > > > Signed-off-by: Jacopo Mondi > > Reviewed-by: Simon Horman > I'm going to split this patch for each SoC to ease backporting, as Geert suggested. Provided the single patches content is the same as here, can I retain your R-b tag? signature.asc Description: PGP signature
Re: [PATCH v4 4/4] pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions
Hi Simon,
On Wed, Nov 07, 2018 at 11:34:50AM +0100, Simon Horman wrote:
> On Tue, Nov 06, 2018 at 11:35:33AM +0100, Jacopo Mondi wrote:
> > Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car E3.
> >
> > Signed-off-by: Jacopo Mondi
> >
> > ---
> > v3 -> v4:
> > - Use new variadic version of VIN_DATA_PIN_GROUP macro
>
> I may be missing something but this patch seems to be the same as v3,
> using the VIN_DATA_PIN_GROUP_VER macro.
>
Oooops, I forgot to add the changes and lost them while rebasing.
Sorry about this, I'll resend.
Thanks
j
> >
> > v2 -> v3:
> > - Rebased on v4.20-rc1
> > - Use the newly introduced VIN_DATA_PIN_GROUP_VER macro
> >
> > Incorporate Geert's comments:
> > - vin5_data8_b is only used with 8 pins: use regular SH_PFC_PIN_GROUP()
> > - remove stf groups for vin4/vin5
> > - confirmed that pins [23-8] of vin4's groups 'a' and 'b' are shared
> > - confirmed with HW team the synchronism pins in vin5 are only for group 'a'
> > ---
> > drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 244
> > ++
> > 1 file changed, 244 insertions(+)
> >
> > diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > index 1fdafa4..16fd139 100644
> > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > @@ -2433,6 +2433,190 @@ static const unsigned int usb30_id_mux[] = {
> > USB3HS0_ID_MARK,
> > };
> >
> > +/* - VIN4
> > --- */
> > +static const union vin_data vin4_data_a_pins = {
> > + .data24 = {
> > + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
> > + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
> > + RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
> > + RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> > + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
> > + RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
> > + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
> > + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
> > + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
> > + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
> > + },
> > +};
> > +
> > +static const union vin_data vin4_data_a_mux = {
> > + .data24 = {
> > + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
> > + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
> > + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
> > + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
> > + VI4_DATA8_MARK, VI4_DATA9_MARK,
> > + VI4_DATA10_MARK, VI4_DATA11_MARK,
> > + VI4_DATA12_MARK, VI4_DATA13_MARK,
> > + VI4_DATA14_MARK, VI4_DATA15_MARK,
> > + VI4_DATA16_MARK, VI4_DATA17_MARK,
> > + VI4_DATA18_MARK, VI4_DATA19_MARK,
> > + VI4_DATA20_MARK, VI4_DATA21_MARK,
> > + VI4_DATA22_MARK, VI4_DATA23_MARK,
> > + },
> > +};
> > +
> > +static const union vin_data vin4_data_b_pins = {
> > + .data24 = {
> > + RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
> > + RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
> > + RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
> > + RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> > + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
> > + RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
> > + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
> > + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 15),
> > + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
> > + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
> > + },
> > +};
> > +
> > +static const union vin_data vin4_data_b_mux = {
> > + .data24 = {
> > + VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
> > + VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
> > + VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
> > + VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
> > + VI4_DATA8_MARK, VI4_DATA9_MARK,
> > + VI4_DATA10_MARK, VI4_DATA11_MARK,
> > + VI4_DATA12_MARK, VI4_DATA13_MARK,
> > + VI4_DATA14_MARK, VI4_DATA15_MARK,
> > + VI4_DATA16_MARK, VI4_DATA17_MARK,
> > + VI4_DATA18_MARK, VI4_DATA19_MARK,
> > +
[PATCH v4 1/4] pinctrl: sh-pfc: Add optional arg to VIN_DATA_PIN_GROUP
VIN data groups may appear on different sets of pins, usually named
"vinX_data_[a|b]". The existing VIN_DATA_PIN_GROUP() does not support
appending the '_a' or '_b' suffix, leading to the definition of groups
names not consistent with the ones defined using SH_PFC_PIN_GROUP() macro.
Fix this by adding making the VIN_DATA_PIN_GROUP macro a variadic one,
which accepts an optional 'version' argument.
Signed-off-by: Jacopo Mondi
---
drivers/pinctrl/sh-pfc/sh_pfc.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index 458ae0a..0e0b4cc 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -54,15 +54,16 @@ struct sh_pfc_pin_group {
/*
* Using union vin_data saves memory occupied by the VIN data pins.
- * VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups
- * in this case.
+ * VIN_DATA_PIN_GROUP() is a macro used to describe the VIN pin groups
+ * in this case. It accepts an optional 'version' argument used when the
+ * same group can appear on a different set of pins.
*/
-#define VIN_DATA_PIN_GROUP(n, s) \
- { \
- .name = #n#s, \
- .pins = n##_pins.data##s, \
- .mux = n##_mux.data##s, \
- .nr_pins = ARRAY_SIZE(n##_pins.data##s),\
+#define VIN_DATA_PIN_GROUP(n, s, ...) \
+ { \
+ .name = #n#s#__VA_ARGS__, \
+ .pins = n##__VA_ARGS__##_pins.data##s, \
+ .mux = n##__VA_ARGS__##_mux.data##s,\
+ .nr_pins = ARRAY_SIZE(n##__VA_ARGS__##_pins.data##s), \
}
union vin_data {
--
2.7.4
[PATCH v4 0/4] sh-pfc: Variadic VIN_DATA_PIN_GROUP macro + updates
Hi Geert, thanks to your suggestion I made a variadic macro out of the VIN_DATA_PIN_GROUP one. The macro accepts an optional third argument 'version' and creates properly formatted names in the form of 'vin4_data8_a' in place of the previous 'vin4_data_a8' ones. I included in this series the refactoring of existing users of versioned VIN_DATA_PIN_GROUP macro and upstreaming of VIN4 and VIN5 enablement for both R-Car M3-N and E3, both of them users of versioned VIN groups. Thanks j v3 -> v4: - The series gathers different patch series previously sent separately: [PATCH 0/2] pinctrl: sh-pfc: r8a77965: Add VIN4 and VIN5 [PATCH] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions As E3 patch depends on the M3-N series, I made a single one out of those. Changelog for the E3 patch (which was actually at v3) is included in the single patch commit message. Jacopo Mondi (4): pinctrl: sh-pfc: Add optional arg to VIN_DATA_PIN_GROUP pinctrl: sh-pfc: Fix VIN versioned groups name pinctrl: sh-pfc: r8a77965: Add VIN[4|5] groups/functions pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions drivers/pinctrl/sh-pfc/pfc-r8a7792.c | 6 +- drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 24 ++-- drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 24 ++-- drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 254 ++ drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 244 drivers/pinctrl/sh-pfc/sh_pfc.h | 17 +-- 6 files changed, 534 insertions(+), 35 deletions(-) -- 2.7.4
[PATCH v4 4/4] pinctrl: sh-pfc: r8a77990: Add VIN[4|5] groups/functions
Add pin, mux and functions definitions for VIN4 and VIN5 for R-Car E3.
Signed-off-by: Jacopo Mondi
---
v3 -> v4:
- Use new variadic version of VIN_DATA_PIN_GROUP macro
v2 -> v3:
- Rebased on v4.20-rc1
- Use the newly introduced VIN_DATA_PIN_GROUP_VER macro
Incorporate Geert's comments:
- vin5_data8_b is only used with 8 pins: use regular SH_PFC_PIN_GROUP()
- remove stf groups for vin4/vin5
- confirmed that pins [23-8] of vin4's groups 'a' and 'b' are shared
- confirmed with HW team the synchronism pins in vin5 are only for group 'a'
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 244 ++
1 file changed, 244 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 1fdafa4..16fd139 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -2433,6 +2433,190 @@ static const unsigned int usb30_id_mux[] = {
USB3HS0_ID_MARK,
};
+/* - VIN4 ---
*/
+static const union vin_data vin4_data_a_pins = {
+ .data24 = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_a_mux = {
+ .data24 = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const union vin_data vin4_data_b_pins = {
+ .data24 = {
+ RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
+ RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
+ RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
+ RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 15),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_b_mux = {
+ .data24 = {
+ VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
+ VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+ VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+ VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const unsigned int vin4_sync_pins[] = {
+ /* HSYNC, VSYNC */
+ RCAR_GP_PIN(2, 25), RCAR_GP_PIN(2, 24),
+};
+
+static const unsigned int vin4_sync_mux[] = {
+ VI4_HSYNC_N_MARK, VI4_VSYNC_N_MARK,
+};
+
+static const unsigned int vin4_field_pins[] = {
+ RCAR_GP_PIN(2, 23),
+};
+
+static const unsigned int vin4_field_mux[] = {
+ VI4_FIELD_MARK,
+};
+
+static const unsigned int vin4_clkenb_pins[] = {
+ RCAR_GP_PIN(1, 2),
+};
+
+static const unsigned int vin4_clkenb_mux[] = {
+ VI4_CLKENB_MARK,
+};
+
+static const unsigned int vin4_clk_pins[] = {
+ RCAR_GP_PIN(2, 22),
+};
+
+static const unsigned int vin4_clk_mux[] = {
+ VI4_CLK_MARK,
+};
+
+/* - VIN5 ---
*/
+static const union vin_data vin5_data_a_pins = {
+ .data16 = {
+ RCAR_GP_PIN(1, 1), RCAR_GP_PIN(1, 2),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN
[PATCH v4 2/4] pinctrl: sh-pfc: Fix VIN versioned groups name
Versioned VIN groups can appear on different sets of pins. Using the
VIN_DATA_PIN_GROUP macro now supports proper naming of said groups through
an optional 'version' argument.
Use the 'version' argument for said macro to fix naming of versioned
groups for R-Car SoCs that defines them.
Signed-off-by: Jacopo Mondi
---
drivers/pinctrl/sh-pfc/pfc-r8a7792.c | 6 +++---
drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 24
drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 24
3 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
index bf0681b..a8a110d 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7792.c
@@ -1744,10 +1744,10 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
VIN_DATA_PIN_GROUP(vin1_data, 12),
VIN_DATA_PIN_GROUP(vin1_data, 10),
VIN_DATA_PIN_GROUP(vin1_data, 8),
- VIN_DATA_PIN_GROUP(vin1_data_b, 24),
- VIN_DATA_PIN_GROUP(vin1_data_b, 20),
+ VIN_DATA_PIN_GROUP(vin1_data, 24, _b),
+ VIN_DATA_PIN_GROUP(vin1_data, 20, _b),
SH_PFC_PIN_GROUP(vin1_data18_b),
- VIN_DATA_PIN_GROUP(vin1_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin1_data, 16, _b),
SH_PFC_PIN_GROUP(vin1_sync),
SH_PFC_PIN_GROUP(vin1_field),
SH_PFC_PIN_GROUP(vin1_clkenb),
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
index 0af737d..20fac0f 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
@@ -4474,20 +4474,20 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(usb2),
SH_PFC_PIN_GROUP(usb2_ch3),
SH_PFC_PIN_GROUP(usb30),
- VIN_DATA_PIN_GROUP(vin4_data_a, 8),
- VIN_DATA_PIN_GROUP(vin4_data_a, 10),
- VIN_DATA_PIN_GROUP(vin4_data_a, 12),
- VIN_DATA_PIN_GROUP(vin4_data_a, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _a),
SH_PFC_PIN_GROUP(vin4_data18_a),
- VIN_DATA_PIN_GROUP(vin4_data_a, 20),
- VIN_DATA_PIN_GROUP(vin4_data_a, 24),
- VIN_DATA_PIN_GROUP(vin4_data_b, 8),
- VIN_DATA_PIN_GROUP(vin4_data_b, 10),
- VIN_DATA_PIN_GROUP(vin4_data_b, 12),
- VIN_DATA_PIN_GROUP(vin4_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _b),
SH_PFC_PIN_GROUP(vin4_data18_b),
- VIN_DATA_PIN_GROUP(vin4_data_b, 20),
- VIN_DATA_PIN_GROUP(vin4_data_b, 24),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _b),
SH_PFC_PIN_GROUP(vin4_sync),
SH_PFC_PIN_GROUP(vin4_field),
SH_PFC_PIN_GROUP(vin4_clkenb),
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
index 3a6d21d..b003abd 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
@@ -4409,20 +4409,20 @@ static const struct {
SH_PFC_PIN_GROUP(usb0),
SH_PFC_PIN_GROUP(usb1),
SH_PFC_PIN_GROUP(usb30),
- VIN_DATA_PIN_GROUP(vin4_data_a, 8),
- VIN_DATA_PIN_GROUP(vin4_data_a, 10),
- VIN_DATA_PIN_GROUP(vin4_data_a, 12),
- VIN_DATA_PIN_GROUP(vin4_data_a, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _a),
SH_PFC_PIN_GROUP(vin4_data18_a),
- VIN_DATA_PIN_GROUP(vin4_data_a, 20),
- VIN_DATA_PIN_GROUP(vin4_data_a, 24),
- VIN_DATA_PIN_GROUP(vin4_data_b, 8),
- VIN_DATA_PIN_GROUP(vin4_data_b, 10),
- VIN_DATA_PIN_GROUP(vin4_data_b, 12),
- VIN_DATA_PIN_GROUP(vin4_data_b, 16),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _a),
+ VIN_DATA_PIN_GROUP(vin4_data, 8, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 10, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 12, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 16, _b),
SH_PFC_PIN_GROUP(vin4_data18_b),
- VIN_DATA_PIN_GROUP(vin4_data_b, 20),
- VIN_DATA_PIN_GROUP(vin4_data_b, 24),
+ VIN_DATA_PIN_GROUP(vin4_data, 20, _b),
+ VIN_DATA_PIN_GROUP(vin4_data, 24, _b),
SH_PFC_PIN_GROUP(vin4_sync),
SH_PFC_PIN_GROUP(vin4_field),
SH_PFC_PIN_GROUP(vin4_clkenb
[PATCH v2] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
The VIN driver bindings dictates fixed numbering for VIN endpoints connected
to CSI-2 endpoints, even when a single endpoint exists.
Without proper endpoint numbering the VIN driver fails to probe.
Based on a patch in BSP from Koji Matsuoka
Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2 device
nodes")
Signed-off-by: Koji Matsuoka
Signed-off-by: Takeshi Kihara
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 9509dc0..106a574 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -745,9 +745,13 @@
#size-cells = <0>;
port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
reg = <1>;
- vin4csi40: endpoint {
+ vin4csi40: endpoint@2 {
+ reg = <2>;
remote-endpoint= <>;
};
};
@@ -769,9 +773,13 @@
#size-cells = <0>;
port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
reg = <1>;
- vin5csi40: endpoint {
+ vin5csi40: endpoint@2 {
+ reg = <2>;
remote-endpoint= <>;
};
};
--
2.7.4
Re: [PATCH] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
Hi Geert,
On Mon, Nov 05, 2018 at 01:57:07PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Mon, Nov 5, 2018 at 1:46 PM jacopo mondi wrote:
> > On Mon, Nov 05, 2018 at 01:07:58PM +0100, Geert Uytterhoeven wrote:
> > > On Mon, Nov 5, 2018 at 12:49 PM Jacopo Mondi
> > > wrote:
> > > > The VIN driver bindings dictates fixed numbering for VIN endpoints
> > > > connected
> > > > to CSI-2 endpoints, even when a single endpoint exists.
> > > >
> > > > Without proper endpoint numbering the VIN driver fails to probe.
> > > >
> > > > Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2
> > > > device nodes")
> > > > Signed-off-by: Koji Matsuoka
> > >
> > > Was this patch authored by you or by Matsuoka-san?
> >
> > The original patch didn't apply
> >
> > $git am index.html\?id\=1b1b73f7558d867d72e198901b84bec1e6ef1405
> > Applying: arm64: dts: r8a77990: Fix csi2 endpoint number in VIN node
> > error: patch failed: arch/arm64/boot/dts/renesas/r8a77990.dtsi:811
> > error: arch/arm64/boot/dts/renesas/r8a77990.dtsi: patch does not apply
>
> Right, the BSP had the unit address and reg property, while upstream hadn't.
>
> So don't you need to re-add:
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> else dtc complains:
>
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (reg_format): /soc/video@e6ef4000/ports/port@1/endpoint@2:reg:
> property has invalid length (4 bytes) (#address-cells == 2,
> #size-cells == 1)
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (pci_device_bus_num): Failed prerequisite 'reg_format'
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (simple_bus_reg): Failed prerequisite 'reg_format'
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (i2c_bus_reg): Failed prerequisite 'reg_format'
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (spi_bus_reg): Failed prerequisite 'reg_format'
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (avoid_default_addr_size):
> /soc/video@e6ef4000/ports/port@1/endpoint@2: Relying on default
> #address-cells value
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (avoid_default_addr_size):
> /soc/video@e6ef4000/ports/port@1/endpoint@2: Relying on default
> #size-cells value
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (graph_endpoint): /soc/video@e6ef4000/ports/port@1/endpoint@2: graph
> node '#address-cells' is -1, must be 1
> arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: Warning
> (graph_endpoint): /soc/video@e6ef4000/ports/port@1/endpoint@2: graph
> node '#size-cells' is -1, must be 0
Oh, sorry I didn't notice. I assumed the partent's ones were used.
I have now fixed that and will send v2.
Thanks
j
>
> > So I made a new one, changing the commit message and adding the Fixes
> > tag.
> >
> > I can change author if you want to.
>
> In such a case, I usually add "based on a patch in the BSP by ...", instead of
> the original SoB-chain.
>
> > > > Signed-off-by: Takeshi Kihara
> > > > Signed-off-by: Jacopo Mondi
>
> 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
signature.asc
Description: PGP signature
Re: [PATCH] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
Hi Geert,
On Mon, Nov 05, 2018 at 01:07:58PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> Thanks for your patch!
>
> On Mon, Nov 5, 2018 at 12:49 PM Jacopo Mondi
> wrote:
> > The VIN driver bindings dictates fixed numbering for VIN endpoints connected
> > to CSI-2 endpoints, even when a single endpoint exists.
> >
> > Without proper endpoint numbering the VIN driver fails to probe.
> >
> > Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2
> > device nodes")
> > Signed-off-by: Koji Matsuoka
>
> Was this patch authored by you or by Matsuoka-san?
The original patch didn't apply
$git am index.html\?id\=1b1b73f7558d867d72e198901b84bec1e6ef1405
Applying: arm64: dts: r8a77990: Fix csi2 endpoint number in VIN node
error: patch failed: arch/arm64/boot/dts/renesas/r8a77990.dtsi:811
error: arch/arm64/boot/dts/renesas/r8a77990.dtsi: patch does not apply
So I made a new one, changing the commit message and adding the Fixes
tag.
I can change author if you want to.
>
> > Signed-off-by: Takeshi Kihara
> > Signed-off-by: Jacopo Mondi
>
> 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
signature.asc
Description: PGP signature
[PATCH] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
Signed-off-by: Jacopo Mondi
---
This patch requires the VIN_DATA_PIN_GROUP_VER macro introduced by patch:
[PATCH 1/2] pinctrl: sh-pfc: Introduce VIN_DATA_PIN_GROUP_VER
Patch based on v4.20-rc1
v2 -> v3:
- Rebased on v4.20-rc1
- Use the newly introduced VIN_DATA_PIN_GROUP_VER macro
Incorporate Geert's comments:
- vin5_data8_b is only used with 8 pins: use regular SH_PFC_PIN_GROUP()
- remove stf groups for vin4/vin5
- confirmed that pins [23-8] of vin4's groups 'a' and 'b' are shared
- confirmed with HW team the synchronism pins in vin5 are only for group 'a'
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 244 ++
1 file changed, 244 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 1fdafa4..16fd139 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -2433,6 +2433,190 @@ static const unsigned int usb30_id_mux[] = {
USB3HS0_ID_MARK,
};
+/* - VIN4 ---
*/
+static const union vin_data vin4_data_a_pins = {
+ .data24 = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_a_mux = {
+ .data24 = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const union vin_data vin4_data_b_pins = {
+ .data24 = {
+ RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
+ RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
+ RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
+ RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 15),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_b_mux = {
+ .data24 = {
+ VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
+ VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+ VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+ VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const unsigned int vin4_sync_pins[] = {
+ /* HSYNC, VSYNC */
+ RCAR_GP_PIN(2, 25), RCAR_GP_PIN(2, 24),
+};
+
+static const unsigned int vin4_sync_mux[] = {
+ VI4_HSYNC_N_MARK, VI4_VSYNC_N_MARK,
+};
+
+static const unsigned int vin4_field_pins[] = {
+ RCAR_GP_PIN(2, 23),
+};
+
+static const unsigned int vin4_field_mux[] = {
+ VI4_FIELD_MARK,
+};
+
+static const unsigned int vin4_clkenb_pins[] = {
+ RCAR_GP_PIN(1, 2),
+};
+
+static const unsigned int vin4_clkenb_mux[] = {
+ VI4_CLKENB_MARK,
+};
+
+static const unsigned int vin4_clk_pins[] = {
+ RCAR_GP_PIN(2, 22),
+};
+
+static const unsigned int vin4_clk_mux[] = {
+ VI4_CLK_MARK,
+};
+
+/* - VIN5 ---
*/
+static const union vin_data vin5_data_a_pins = {
+ .data16 = {
+ RCAR_GP_PIN(1, 1), RCAR_GP_PIN(1
[PATCH] arm64: dts: renesas: r8a77990: Fix VIN endpoint numbering
The VIN driver bindings dictates fixed numbering for VIN endpoints connected
to CSI-2 endpoints, even when a single endpoint exists.
Without proper endpoint numbering the VIN driver fails to probe.
Fixes: ec70407ae7d7 ("arm64: dts: renesas: r8a77990: Add VIN and CSI-2 device
nodes")
Signed-off-by: Koji Matsuoka
Signed-off-by: Takeshi Kihara
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 9509dc0..97f7e0c 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -747,7 +747,8 @@
port@1 {
reg = <1>;
- vin4csi40: endpoint {
+ vin4csi40: endpoint@2 {
+ reg = <2>;
remote-endpoint= <>;
};
};
@@ -771,7 +772,8 @@
port@1 {
reg = <1>;
- vin5csi40: endpoint {
+ vin5csi40: endpoint@2 {
+ reg = <2>;
remote-endpoint= <>;
};
};
--
2.7.4
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
Hi Simon,
On Wed, Oct 31, 2018 at 03:37:39PM +0100, Simon Horman wrote:
> On Wed, Oct 31, 2018 at 02:18:40PM +0100, jacopo mondi wrote:
> > Hi Simon,
> >
> > On Wed, Oct 31, 2018 at 01:48:13PM +0100, Simon Horman wrote:
> > > On Tue, Oct 30, 2018 at 02:57:59PM +0200, Laurent Pinchart wrote:
> > > > Hi Jacopo,
> > > >
> > > > On Tuesday, 30 October 2018 12:14:31 EET jacopo mondi wrote:
> > > > > On Mon, Sep 10, 2018 at 05:12:30PM +0300, Laurent Pinchart wrote:
> > > > > > On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> > > > > >> From: Koji Matsuoka
> > > > > >>
> > > > > >> Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990
> > > > > >> device
> > > > > >> tree.
> > > > > >>
> > > > > >> Signed-off-by: Koji Matsuoka
> > > > > >> Signed-off-by: Takeshi Kihara
> > > > > >> Signed-off-by: Jacopo Mondi
> > > > > >> ---
> > > > > >>
> > > > > >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79
> > > > > >>
> > > > > >> 1 file changed, 79 insertions(+)
> > > > > >>
> > > > > >> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > >> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index ae89260..0ae7bbe
> > > > > >> 100644
> > > > > >> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > >> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > > > >> @@ -337,6 +337,85 @@
> > > > > >>
> > > > > >>status = "disabled";
> > > > > >>
> > > > > >>};
> > > > > >>
> > > > > >> + csi40: csi2@feaa {
> > > > > >
> > > > > > I believe Simon would like to keep the nodes sorted by address
> > > > > >
> > > > > >> + compatible = "renesas,r8a77990-csi2",
> > > > > >> "renesas,rcar-gen3-csi2";
> > > > > >> + reg = <0 0xfeaa 0 0x1>;
> > > > > >
> > > > > > 0x1 seems pretty large to me.
> > > > >
> > > > > It seems to me that all Gen3 SoC have this lenght specified
> > > > >
> > > > > $git grep -A 10 'csi[2|4][0|1]: csi' arch/arm64/boot/dts/renesas/ |
> > > > > grep reg
> > > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfea8 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeab 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfea8 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfea8 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77970.dtsi- reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeab 0
> > > > > 0x1>;
> > > > > arch/arm64/boot/dts/renesas/r8a77990.dtsi- reg = <0 0xfeaa 0
> > > > > 0x1>;
> > > > >
> > > > > Am I missing something?
> > > >
> > > > Cargo-cult programming ? :-) This will likely not hurt, but such a large
> > > > memory area is not required, and we'll save a bit of memory if we
> > > > reduce the
> > > > mapping from 64kB to 4kB (or less)
> > >
> > > Can we please update this patch, and existing dtsi files,
> > > to use an appropriately small register window?
> > >
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
Hi Simon,
On Wed, Oct 31, 2018 at 01:48:13PM +0100, Simon Horman wrote:
> On Tue, Oct 30, 2018 at 02:57:59PM +0200, Laurent Pinchart wrote:
> > Hi Jacopo,
> >
> > On Tuesday, 30 October 2018 12:14:31 EET jacopo mondi wrote:
> > > On Mon, Sep 10, 2018 at 05:12:30PM +0300, Laurent Pinchart wrote:
> > > > On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> > > >> From: Koji Matsuoka
> > > >>
> > > >> Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990 device
> > > >> tree.
> > > >>
> > > >> Signed-off-by: Koji Matsuoka
> > > >> Signed-off-by: Takeshi Kihara
> > > >> Signed-off-by: Jacopo Mondi
> > > >> ---
> > > >>
> > > >> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79
> > > >>
> > > >> 1 file changed, 79 insertions(+)
> > > >>
> > > >> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > >> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index ae89260..0ae7bbe
> > > >> 100644
> > > >> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > >> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > >> @@ -337,6 +337,85 @@
> > > >>
> > > >>status = "disabled";
> > > >>
> > > >>};
> > > >>
> > > >> + csi40: csi2@feaa {
> > > >
> > > > I believe Simon would like to keep the nodes sorted by address
> > > >
> > > >> + compatible = "renesas,r8a77990-csi2",
> > > >> "renesas,rcar-gen3-csi2";
> > > >> + reg = <0 0xfeaa 0 0x1>;
> > > >
> > > > 0x1 seems pretty large to me.
> > >
> > > It seems to me that all Gen3 SoC have this lenght specified
> > >
> > > $git grep -A 10 'csi[2|4][0|1]: csi' arch/arm64/boot/dts/renesas/ | grep
> > > reg
> > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfea8 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeaa 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeab 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfea8 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfeaa 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfea8 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfeaa 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77970.dtsi- reg = <0 0xfeaa 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeaa 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeab 0
> > > 0x1>;
> > > arch/arm64/boot/dts/renesas/r8a77990.dtsi- reg = <0 0xfeaa 0
> > > 0x1>;
> > >
> > > Am I missing something?
> >
> > Cargo-cult programming ? :-) This will likely not hurt, but such a large
> > memory area is not required, and we'll save a bit of memory if we reduce the
> > mapping from 64kB to 4kB (or less)
>
> Can we please update this patch, and existing dtsi files,
> to use an appropriately small register window?
>
What if we keep this one as it is and we change all the DTSIs in one
go?
> >
> > > > Apart from that,
> > >
> > > I will include the upporting of the following patch to fix the VIN
> > > endpoint numbering in forthcoming v3:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit
> > > /?id=1b1b73f7558d867d72e198901b84bec1e6ef1405
> > >
> > > As this has already been applied to simon's tree.
> > >
> > > > Reviewed-by: Laurent Pinchart
> > > >
> > > >> + interrupts = ;
> > > >> + clocks = < CPG_MOD 716>;
> > > >> + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > > >> + resets = < 716>;
> > > >> + status = "disabled";
> > >
Re: [PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
On Mon, Sep 10, 2018 at 05:12:30PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> > From: Koji Matsuoka
> >
> > Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990 device tree.
> >
> > Signed-off-by: Koji Matsuoka
> > Signed-off-by: Takeshi Kihara
> > Signed-off-by: Jacopo Mondi
> > ---
> > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79
> > 1 file changed, 79 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index ae89260..0ae7bbe 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > @@ -337,6 +337,85 @@
> > status = "disabled";
> > };
> >
> > + csi40: csi2@feaa {
>
> I believe Simon would like to keep the nodes sorted by address
>
> > + compatible = "renesas,r8a77990-csi2",
> > "renesas,rcar-gen3-csi2";
> > + reg = <0 0xfeaa 0 0x1>;
>
> 0x1 seems pretty large to me.
It seems to me that all Gen3 SoC have this lenght specified
$git grep -A 10 'csi[2|4][0|1]: csi' arch/arm64/boot/dts/renesas/ | grep reg
arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfea8 0 0x1>;
arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeaa 0 0x1>;
arch/arm64/boot/dts/renesas/r8a7795.dtsi-reg = <0 0xfeab 0 0x1>;
arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfea8 0 0x1>;
arch/arm64/boot/dts/renesas/r8a7796.dtsi-reg = <0 0xfeaa 0 0x1>;
arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfea8 0 0x1>;
arch/arm64/boot/dts/renesas/r8a77965.dtsi- reg = <0 0xfeaa 0 0x1>;
arch/arm64/boot/dts/renesas/r8a77970.dtsi- reg = <0 0xfeaa 0 0x1>;
arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeaa 0 0x1>;
arch/arm64/boot/dts/renesas/r8a77980.dtsi- reg = <0 0xfeab 0 0x1>;
arch/arm64/boot/dts/renesas/r8a77990.dtsi- reg = <0 0xfeaa 0 0x1>;
Am I missing something?
>
> Apart from that,
I will include the upporting of the following patch to fix the VIN
endpoint numbering in forthcoming v3:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=1b1b73f7558d867d72e198901b84bec1e6ef1405
As this has already been applied to simon's tree.
Thanks
j
>
> Reviewed-by: Laurent Pinchart
>
> > + interrupts = ;
> > + clocks = < CPG_MOD 716>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 716>;
> > + status = "disabled";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + reg = <1>;
> > +
> > + csi40vin4: endpoint@0 {
> > + reg = <0>;
> > + remote-endpoint = <>;
> > + };
> > + csi40vin5: endpoint@1 {
> > + reg = <1>;
> > + remote-endpoint = <>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + vin4: video@e6ef4000 {
> > + compatible = "renesas,vin-r8a77990";
> > + reg = <0 0xe6ef4000 0 0x1000>;
> > + interrupts = ;
> > + clocks = < CPG_MOD 807>;
> > + power-domains = < R8A77990_PD_ALWAYS_ON>;
> > + resets = < 807>;
> > + renesas,id = <4>;
> > + status = "disabled";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > +
Re: [PATCH 2/2] dt-bindings: pinctrl: Add RZ/A2 pinctrl and GPIO
Hi Chris,
On Tue, Oct 16, 2018 at 05:47:00PM -0500, Rob Herring wrote:
> On Fri, Oct 05, 2018 at 10:09:51AM -0500, Chris Brandt wrote:
> > Add device tree binding documentation and header file for Renesas R7S9210
> > (RZ/A2) SoCs.
> >
> > Signed-off-by: Chris Brandt
> > ---
> > .../bindings/pinctrl/renesas,rza2-pinctrl.txt | 76
> > ++
> > include/dt-bindings/pinctrl/r7s9210-pinctrl.h | 47 +
> > 2 files changed, 123 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> > create mode 100644 include/dt-bindings/pinctrl/r7s9210-pinctrl.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> > b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> > new file mode 100644
> > index ..5f338054f493
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> > @@ -0,0 +1,76 @@
> > +Renesas RZ/A2 combined Pin and GPIO controller
> > +
> > +The Renesas SoCs of the RZ/A2 series feature a combined Pin and GPIO
> > controller.
> > +Pin multiplexing and GPIO configuration is performed on a per-pin basis.
> > +Each port features up to 8 pins, each of them configurable for GPIO
> > +function (port mode) or in alternate function mode.
> > +Up to 8 different alternate function modes exist for each single pin.
> > +
> > +Pin controller node
> > +---
> > +
> > +Required properties:
> > + - compatible: should be:
> > +- "renesas,r7s9210-pinctrl": for RZ/A2M
> > +
> > + - reg
> > +address base and length of the memory area where the pin controller
> > +hardware is mapped to.
> > +
> > +Optional properties:
> > + - gpio-controller
> > +Include this in order to enable GPIO functionality. When included, both
> > +gpio_cells and gpio_ranges are then required.
> > + - #gpio-cells
> > +Must be 2
> > + - gpio-ranges
> > +Expresses the total number GPIO ports/pins in this SoC
>
> Are these really optional? I guess in theory a board could use no GPIOs,
> but that seems unlikely.
Here you define bindings that allows you to have only one
gpio-controller node for the whole system.
With RZ/A1 we have a gpio-controller sub-node for each port. It's
true though that you have a lot of ports and few pins per port, but
to refer to a gpio you have to index the gpio in the whole pin space
with RZA1_PIN_ID():
gpios = < RZA2_PIN_ID(P6, 0) GPIO_ACTIVE_HIGH>;
While I think this is nicer:
gpios = < 0 GPIO_ACTIVE_HIGH>;
Having gpio-controller sub-nodes also allows you
to specify a 'ngpios' property for each port (or do all ports have 8
pins? If I read Table 51.1 right they don't..), and when RZ/A2x will
come and has different pins per port it's
easy for developers to identify the differences (but this
depends on the package too, so it's not that easy as I'm putting it
here probably)
What do you think?
Thanks
j
> > +
> > +
> > +Example: Pin controller node for RZ/A2M SoC (r7s9210)
> > +
> > + pinctrl: pin-controller@fcffe000 {
> > + compatible = "renesas,r7s9210-pinctrl";
> > + reg = <0xfcffe000 0x9D1>;
> > +
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + gpio-ranges = < 0 0 176>;
> > + };
> > +
> > +Sub-nodes
> > +-
> > +
> > +The child nodes of the pin controller node describe a pin multiplexing
> > +function or a GPIO controller alternatively.
>
> But the parent is already a GPIO controller. This needs to be fully
> defined.
>
> > +
> > +- Pin multiplexing sub-nodes:
> > + A pin multiplexing sub-node describes how to configure a set of
> > + (or a single) pin in some desired alternate function mode.
> > + The values for the pinmux properties are a combination of port name, pin
> > + number and the desired function index. Use the RZA2_PINMUX macro located
> > + in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily define these.
> > + For assigning GPIO pins, use the macro RZA2_PIN_ID also in
> > r7s9210-pinctrl.h
> > + to express the desired port pin.
> > +
> > + Example: Board specific pins configuration
> > +
> > +{
> > + /* Serial Console */
> > + scif4_pins: serial4 {
> > + pinmux = , /* TxD4 */
> > +; /* RxD4 */
> > + };
> > + };
> > +
> > + Example: Assigning a GPIO:
> > +
> > + leds {
> > + status = "okay";
> > + compatible = "gpio-leds";
> > +
> > + led0 {
> > + /* P6_0 */
> > + gpios = < RZA2_PIN_ID(P6, 0) GPIO_ACTIVE_HIGH>;
> > + };
> > + };
signature.asc
Description: PGP signature
Re: [PATCH 2/2] dt-bindings: pinctrl: Add RZ/A2 pinctrl and GPIO
Hi Chris,
On Fri, Oct 05, 2018 at 10:09:51AM -0500, Chris Brandt wrote:
> Add device tree binding documentation and header file for Renesas R7S9210
> (RZ/A2) SoCs.
>
> Signed-off-by: Chris Brandt
> ---
> .../bindings/pinctrl/renesas,rza2-pinctrl.txt | 76
> ++
> include/dt-bindings/pinctrl/r7s9210-pinctrl.h | 47 +
> 2 files changed, 123 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> create mode 100644 include/dt-bindings/pinctrl/r7s9210-pinctrl.h
>
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> new file mode 100644
> index ..5f338054f493
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt
> @@ -0,0 +1,76 @@
> +Renesas RZ/A2 combined Pin and GPIO controller
> +
> +The Renesas SoCs of the RZ/A2 series feature a combined Pin and GPIO
> controller.
> +Pin multiplexing and GPIO configuration is performed on a per-pin basis.
> +Each port features up to 8 pins, each of them configurable for GPIO
> +function (port mode) or in alternate function mode.
> +Up to 8 different alternate function modes exist for each single pin.
> +
> +Pin controller node
> +---
> +
> +Required properties:
> + - compatible: should be:
> +- "renesas,r7s9210-pinctrl": for RZ/A2M
> +
> + - reg
> +address base and length of the memory area where the pin controller
> +hardware is mapped to.
> +
> +Optional properties:
> + - gpio-controller
> +Include this in order to enable GPIO functionality. When included, both
> +gpio_cells and gpio_ranges are then required.
> + - #gpio-cells
> +Must be 2
> + - gpio-ranges
> +Expresses the total number GPIO ports/pins in this SoC
I have some concerns here, I'll reply to Rob on this
> +
> +
> +Example: Pin controller node for RZ/A2M SoC (r7s9210)
> +
> + pinctrl: pin-controller@fcffe000 {
> + compatible = "renesas,r7s9210-pinctrl";
> + reg = <0xfcffe000 0x9D1>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = < 0 0 176>;
> + };
> +
> +Sub-nodes
> +-
> +
> +The child nodes of the pin controller node describe a pin multiplexing
> +function or a GPIO controller alternatively.
> +
> +- Pin multiplexing sub-nodes:
> + A pin multiplexing sub-node describes how to configure a set of
> + (or a single) pin in some desired alternate function mode.
> + The values for the pinmux properties are a combination of port name, pin
> + number and the desired function index. Use the RZA2_PINMUX macro located
> + in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily define these.
> + For assigning GPIO pins, use the macro RZA2_PIN_ID also in
> r7s9210-pinctrl.h
> + to express the desired port pin.
> +
> + Example: Board specific pins configuration
> +
> + {
> + /* Serial Console */
> + scif4_pins: serial4 {
> + pinmux = , /* TxD4 */
> + ; /* RxD4 */
> + };
> + };
> +
> + Example: Assigning a GPIO:
> +
> + leds {
> + status = "okay";
> + compatible = "gpio-leds";
> +
> + led0 {
> + /* P6_0 */
> + gpios = < RZA2_PIN_ID(P6, 0) GPIO_ACTIVE_HIGH>;
> + };
> + };
I think you should list the required properties ('pinmux') and the pin
configuration flags the hardware supports. From a quick look to the
manual I only see a configurable drive strength, but I might have
missed something.
> diff --git a/include/dt-bindings/pinctrl/r7s9210-pinctrl.h
> b/include/dt-bindings/pinctrl/r7s9210-pinctrl.h
> new file mode 100644
> index ..39ac74ba520b
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/r7s9210-pinctrl.h
> @@ -0,0 +1,47 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Defines macros and constants for Renesas RZ/A2 pin controller pin
> + * muxing functions.
> + */
> +#ifndef __DT_BINDINGS_PINCTRL_RENESAS_RZA2_H
> +#define __DT_BINDINGS_PINCTRL_RENESAS_RZA2_H
> +
> +#define RZA2_PINS_PER_PORT 8
> +
> +/* Port names as labeled in the Hardware Manual */
> +#define P0 0
> +#define P1 1
> +#define P2 2
> +#define P3 3
> +#define P4 4
> +#define P5 5
> +#define P6 6
> +#define P7 7
> +#define P8 8
> +#define P9 9
> +#define PA 10
> +#define PB 11
> +#define PC 12
> +#define PD 13
> +#define PE 14
> +#define PF 15
> +#define PG 16
> +#define PH 17
> +/* No I */
> +#define PJ 18
> +#define PK 19
> +#define PL 20
> +#define PM 21
> +
> +/*
> + * Create the pin index from its bank and position numbers and store in
> + * the upper 8 bits the alternate function identifier
> + */
> +#define RZA2_PINMUX(b, p, f) ((b) * RZA2_PINS_PER_PORT + (p) | (f << 16))
> +
> +/*
> + * Convert a port and pin label to
Re: [PATCH 1/2] pinctrl: Add RZ/A2 pin and gpio controller
Hi Chris,
thanks for the patches.
On Fri, Oct 05, 2018 at 10:09:50AM -0500, Chris Brandt wrote:
> Adds support for the pin and gpio controller found in R7S9210 (RZ/A2) SoCs.
>
> Signed-off-by: Chris Brandt
> ---
> drivers/pinctrl/Kconfig| 11 +
> drivers/pinctrl/Makefile | 1 +
> drivers/pinctrl/pinctrl-rza2.c | 519
> +
> 3 files changed, 531 insertions(+)
> create mode 100644 drivers/pinctrl/pinctrl-rza2.c
>
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index 978b2ed4d014..5819e0c9c3a8 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -195,6 +195,17 @@ config PINCTRL_RZA1
> help
> This selects pinctrl driver for Renesas RZ/A1 platforms.
>
> +config PINCTRL_RZA2
> + bool "Renesas RZ/A2 gpio and pinctrl driver"
> + depends on OF
> + depends on ARCH_R7S9210 || COMPILE_TEST
> + select GPIOLIB
> + select GENERIC_PINCTRL_GROUPS
> + select GENERIC_PINMUX_FUNCTIONS
> + select GENERIC_PINCONF
> + help
> + This selects pinctrl driver for Renesas RZ/A2 platforms.
> +
> config PINCTRL_SINGLE
> tristate "One-register-per-pin type device tree based pinctrl driver"
> depends on OF
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> index 8e127bd8610f..9354f0c2044c 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_PINCTRL_PIC32) += pinctrl-pic32.o
> obj-$(CONFIG_PINCTRL_PISTACHIO) += pinctrl-pistachio.o
> obj-$(CONFIG_PINCTRL_ROCKCHIP) += pinctrl-rockchip.o
> obj-$(CONFIG_PINCTRL_RZA1) += pinctrl-rza1.o
> +obj-$(CONFIG_PINCTRL_RZA2) += pinctrl-rza2.o
> obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
> obj-$(CONFIG_PINCTRL_SIRF) += sirf/
> obj-$(CONFIG_PINCTRL_SX150X) += pinctrl-sx150x.o
> diff --git a/drivers/pinctrl/pinctrl-rza2.c b/drivers/pinctrl/pinctrl-rza2.c
> new file mode 100644
> index ..db8d5a3cf2ea
> --- /dev/null
> +++ b/drivers/pinctrl/pinctrl-rza2.c
> @@ -0,0 +1,519 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Combined GPIO and pin controller support for Renesas RZ/A2 (R7S72100) SoC
R7S9210
> + *
> + * Copyright (C) 2018 Chris Brandt
> + */
> +
> +/*
> + * This pin controller/gpio combined driver supports Renesas devices of RZ/A2
> + * family.
> + */
> +
> +#include
> +#include
Headers sorted please :)
> +#include
> +#include
> +#include
> +
> +#include "core.h"
> +#include "pinmux.h"
> +
> +#define DRIVER_NAME "pinctrl-rza2"
> +
> +#define RZA2_NPORTS (PM + 1)
Why not making this part of the enum itself?
> +#define RZA2_PINS_PER_PORT 8
> +#define RZA2_NPINS (RZA2_PINS_PER_PORT * RZA2_NPORTS)
> +#define RZA2_PIN_ID_TO_PORT(id) ((id) / RZA2_PINS_PER_PORT)
> +#define RZA2_PIN_ID_TO_PIN(id) ((id) % RZA2_PINS_PER_PORT)
> +
> +/*
> + * Use 16 lower bits [15:0] for pin identifier
> + * Use 16 higher bits [31:16] for pin mux function
> + */
> +#define MUX_PIN_ID_MASK GENMASK(15, 0)
> +#define MUX_FUNC_MASKGENMASK(31, 16)
> +#define MUX_FUNC_OFFS16
> +#define MUX_FUNC(pinconf)((pinconf & MUX_FUNC_MASK) >> MUX_FUNC_OFFS)
> +#define MUX_FUNC(pinconf)((pinconf & MUX_FUNC_MASK) >> MUX_FUNC_OFFS)
Seems like the same line to me.
Also, double empty line.
> +
> +
> +enum pfc_pin_port_name {P0, P1, P2, P3, P4, P5, P6, P7, P8, P9, PA, PB, PC,
> PD,
> + PE, PF, PG, PH, PJ, PK, PL, PM};
weird spacing
> +static const char port_names[] = "0123456789ABCDEFGHJKLM";
> +
> +struct rza2_pinctrl_priv {
> + struct device *dev;
> + void __iomem *base;
> +
> + struct pinctrl_pin_desc *pins;
> + struct pinctrl_desc desc;
> + struct pinctrl_dev *pctl;
> +};
> +
> +#define PDR_BASE(b) (b + 0x)/* 16-bit, 2 bytes apart */
() around macros parameters when used:
((b) + 0x)
which is just (b) by the way :)
Also, please prefix all defines with RZA2_ not to pollute the global
symbols space.
> +#define PODR_BASE(b) (b + 0x0040)/* 8-bit, 1 byte apart */
> +#define PIDR_BASE(b) (b + 0x0060)/* 8-bit, 1 byte apart */
> +#define PMR_BASE(b) (b + 0x0080)/* 8-bit, 1 byte apart */
> +#define DSCR_BASE(b) (b + 0x0140)/* 16-bit, 2 bytes apart */
> +#define PFS_BASE(b) (b + 0x0200)/* 8-bit, 8 bytes apart */
Here you define registers address bases, but instead of computing
everytime the port-pin dedicated register address (I'm thinking about
PFS specifically but it applies to others), would you consider providing
accessors helpers to write the offset computations process just once here?
Eg.
#define RZA2_PFS(_b, _port, _pin) (RZA2_PFS_BASE(_b) + (_port) * 8 + (_pin))
Same for other register which needs offset calculation based on port
and pin values.
> +#define PWPR(b) (b + 0x02FF)/*
Re: [PATCH] MAINTAINERS: Add Renesas RZ/A and RZ/N files to Renesas pinctrl section
Hi Geert, On Tue, Oct 16, 2018 at 01:56:53PM +0200, Geert Uytterhoeven wrote: > Add paths for the Renesas RZ/A and RZ/N series pin controller drivers, > as they are not under sh-pfc/, but still maintained with the other > Renesas pin controller drivers. > > Signed-off-by: Geert Uytterhoeven Acked-by: Jacopo Mondi Thank you j > --- > To be queued in sh-pfc-for-v4.21. > > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 809600de0b7293c8..77ff83bc09464c1f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11672,6 +11672,7 @@ M:Geert Uytterhoeven > L: linux-renesas-soc@vger.kernel.org > T: git > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git sh-pfc > S: Maintained > +F: drivers/pinctrl/pinctrl-rz* > F: drivers/pinctrl/sh-pfc/ > > PIN CONTROLLER - SAMSUNG > -- > 2.17.1 > signature.asc Description: PGP signature
Re: [PATCH v2] pinctrl: rzn1: Fix check for used MDIO bus
Hi Phil,
On Tue, Oct 16, 2018 at 08:04:53AM +, Phil Edworthy wrote:
> Hi Jacopo,
>
> On 15 October 2018 16:12 jacopo mondi wrote:
> > On Mon, Oct 15, 2018 at 04:01:47PM +0100, Phil Edworthy wrote:
> > > This fixes the check for unused mdio bus setting and the following
> > > static checker warning:
> > > drivers/pinctrl/pinctrl-rzn1.c:198 rzn1_pinctrl_mdio_select()
> > > warn: always true condition '(ipctl->mdio_func[mdio] >= 0) => (0-u32max
> > >= 0)'
> > >
> > > It also fixes the return var when calling of_get_child_count()
> > >
> >
> > Not really, since you skip the assignement if return value is <= 0:
> >
> > nfuncs = of_get_child_count(np);
> > if (nfuncs <= 0)
> > return 0;
> >
> > ipctl->nfunctions = nfuncs;
> >
> > This seems more likely to be here to make 'rzn1_pmx_get_funcs_count()'
> > happy, as it returns a signed integer, but since nfunctions is only
> > assigned if
> > 'nfuncs' > 0, then the cast is safe there.
> >
> > I would keep this unsigned, and rather return an error if
> > 'of_get_child_count()' returns an error of any sort in 'probe_dt()',
> > otherwise
> > assign 'ipctl->nfunctions = nfuncs;' unconditionally and return immediately
> > if
> > nfuncs == 0. This makes sure nfunctions is initialized even if there are no
> > functions registered.
> Ok, I get what you're saying, though nfunctions will always be initialised due
> to allocation with devm_kzalloc.
>
Right, sorry for missing that.
> > Anyway, small issues, this just doesn't belong to this patch, but it's
> > likely not
> > to cause any harm I guess.
> True... should I leave this patch as is or respin again?
I think you should handle the case where of_get_child_count() returns
an error, but in a follow up patch. You can leave this one as it is,
even if that change is imho not necessary.
Thanks
j
>
> Thanks
> Phil
>
> > > Reported-by: Dan Carpenter
> > > Signed-off-by: Phil Edworthy
> > > ---
> > > v2:
> > > - Don't use implicit type conversion.
> > > - Fix type of return var when calling of_get_child_count().
> > > ---
> > > drivers/pinctrl/pinctrl-rzn1.c | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/pinctrl/pinctrl-rzn1.c
> > > b/drivers/pinctrl/pinctrl-rzn1.c index ce05e3a00be2..4998463c54a0
> > > 100644
> > > --- a/drivers/pinctrl/pinctrl-rzn1.c
> > > +++ b/drivers/pinctrl/pinctrl-rzn1.c
> > > @@ -112,13 +112,13 @@ struct rzn1_pinctrl {
> > > struct rzn1_pinctrl_regs __iomem *lev2;
> > > u32 lev1_protect_phys;
> > > u32 lev2_protect_phys;
> > > - u32 mdio_func[2];
> > > + int mdio_func[2];
> > >
> > > struct rzn1_pin_group *groups;
> > > unsigned int ngroups;
> > >
> > > struct rzn1_pmx_func *functions;
> > > - unsigned int nfunctions;
> > > + int nfunctions;
> > > };
> > >
> > > #define RZN1_PINS_PROP "pinmux"
> > > @@ -195,9 +195,9 @@ static void rzn1_hw_set_lock(struct rzn1_pinctrl
> > > *ipctl, u8 lock, u8 value) static void rzn1_pinctrl_mdio_select(struct
> > rzn1_pinctrl *ipctl, int mdio,
> > >u32 func)
> > > {
> > > - if (ipctl->mdio_func[mdio] >= 0 && ipctl->mdio_func[mdio] != func)
> > > + if (ipctl->mdio_func[mdio] >= 0 && ipctl->mdio_func[mdio] !=
> > > +(int)func)
> > > dev_warn(ipctl->dev, "conflicting setting for mdio%d!\n",
> > mdio);
> > > - ipctl->mdio_func[mdio] = func;
> > > + ipctl->mdio_func[mdio] = (int)func;
> > >
> > > dev_dbg(ipctl->dev, "setting mdio%d to %u\n", mdio, func);
> > >
> > > @@ -810,8 +810,8 @@ static int rzn1_pinctrl_probe_dt(struct
> > platform_device *pdev,
> > > struct device_node *np = pdev->dev.of_node;
> > > struct device_node *child;
> > > unsigned int maxgroups = 0;
> > > - unsigned int nfuncs = 0;
> > > unsigned int i = 0;
> > > + int nfuncs = 0;
> > > int ret;
> > >
> > > nfuncs = of_get_child_count(np);
> > > --
> > > 2.17.1
> > >
signature.asc
Description: PGP signature
Re: [PATCH v2] pinctrl: rzn1: Fix check for used MDIO bus
Hi Phil,
On Mon, Oct 15, 2018 at 04:01:47PM +0100, Phil Edworthy wrote:
> This fixes the check for unused mdio bus setting and the following static
> checker warning:
> drivers/pinctrl/pinctrl-rzn1.c:198 rzn1_pinctrl_mdio_select()
> warn: always true condition '(ipctl->mdio_func[mdio] >= 0) => (0-u32max >=
> 0)'
>
> It also fixes the return var when calling of_get_child_count()
>
Not really, since you skip the assignement if return value is <= 0:
nfuncs = of_get_child_count(np);
if (nfuncs <= 0)
return 0;
ipctl->nfunctions = nfuncs;
This seems more likely to be here to make 'rzn1_pmx_get_funcs_count()'
happy, as it returns a signed integer, but since nfunctions is only
assigned if 'nfuncs' > 0, then the cast is safe there.
I would keep this unsigned, and rather return an error if
'of_get_child_count()' returns an error of any sort in 'probe_dt()',
otherwise assign 'ipctl->nfunctions = nfuncs;' unconditionally and
return immediately if nfuncs == 0. This makes sure nfunctions is
initialized even if there are no functions registered.
Anyway, small issues, this just doesn't belong to this patch, but it's
likely not to cause any harm I guess.
> Reported-by: Dan Carpenter
> Signed-off-by: Phil Edworthy
> ---
> v2:
> - Don't use implicit type conversion.
> - Fix type of return var when calling of_get_child_count().
> ---
> drivers/pinctrl/pinctrl-rzn1.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-rzn1.c b/drivers/pinctrl/pinctrl-rzn1.c
> index ce05e3a00be2..4998463c54a0 100644
> --- a/drivers/pinctrl/pinctrl-rzn1.c
> +++ b/drivers/pinctrl/pinctrl-rzn1.c
> @@ -112,13 +112,13 @@ struct rzn1_pinctrl {
> struct rzn1_pinctrl_regs __iomem *lev2;
> u32 lev1_protect_phys;
> u32 lev2_protect_phys;
> - u32 mdio_func[2];
> + int mdio_func[2];
>
> struct rzn1_pin_group *groups;
> unsigned int ngroups;
>
> struct rzn1_pmx_func *functions;
> - unsigned int nfunctions;
> + int nfunctions;
> };
>
> #define RZN1_PINS_PROP "pinmux"
> @@ -195,9 +195,9 @@ static void rzn1_hw_set_lock(struct rzn1_pinctrl *ipctl,
> u8 lock, u8 value)
> static void rzn1_pinctrl_mdio_select(struct rzn1_pinctrl *ipctl, int mdio,
>u32 func)
> {
> - if (ipctl->mdio_func[mdio] >= 0 && ipctl->mdio_func[mdio] != func)
> + if (ipctl->mdio_func[mdio] >= 0 && ipctl->mdio_func[mdio] != (int)func)
> dev_warn(ipctl->dev, "conflicting setting for mdio%d!\n", mdio);
> - ipctl->mdio_func[mdio] = func;
> + ipctl->mdio_func[mdio] = (int)func;
>
> dev_dbg(ipctl->dev, "setting mdio%d to %u\n", mdio, func);
>
> @@ -810,8 +810,8 @@ static int rzn1_pinctrl_probe_dt(struct platform_device
> *pdev,
> struct device_node *np = pdev->dev.of_node;
> struct device_node *child;
> unsigned int maxgroups = 0;
> - unsigned int nfuncs = 0;
> unsigned int i = 0;
> + int nfuncs = 0;
> int ret;
>
> nfuncs = of_get_child_count(np);
> --
> 2.17.1
>
signature.asc
Description: PGP signature
Re: [PATCH] pinctrl: rzn1: Fix check for used MDIO bus
Hi Phil,
On Fri, Oct 12, 2018 at 11:40:36AM +0100, Phil Edworthy wrote:
> This fixes the check for unused mdio bus setting and the following static
> checker warning:
> drivers/pinctrl/pinctrl-rzn1.c:198 rzn1_pinctrl_mdio_select()
> warn: always true condition '(ipctl->mdio_func[mdio] >= 0) => (0-u32max >=
> 0)'
>
> Reported-by: Dan Carpenter
> Signed-off-by: Phil Edworthy
> ---
> drivers/pinctrl/pinctrl-rzn1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-rzn1.c b/drivers/pinctrl/pinctrl-rzn1.c
> index ce05e3a00be2..f688f3a29dfd 100644
> --- a/drivers/pinctrl/pinctrl-rzn1.c
> +++ b/drivers/pinctrl/pinctrl-rzn1.c
> @@ -195,7 +195,7 @@ static void rzn1_hw_set_lock(struct rzn1_pinctrl *ipctl,
> u8 lock, u8 value)
> static void rzn1_pinctrl_mdio_select(struct rzn1_pinctrl *ipctl, int mdio,
>u32 func)
> {
> - if (ipctl->mdio_func[mdio] >= 0 && ipctl->mdio_func[mdio] != func)
> + if (ipctl->mdio_func[mdio] != -1 && ipctl->mdio_func[mdio] != func)
> dev_warn(ipctl->dev, "conflicting setting for mdio%d!\n", mdio);
> ipctl->mdio_func[mdio] = func;
>
MY understanding here is that the static checker complains because you
are comparing a variable of unsigned type to negative values, and
indeed you are treating mdio_func as signed in the driver code.
mdio_func is defined as:
struct rzn1_pinctrl {
...
u32 mdio_func[2];
...
};
Then in probe function mdio_func gets intialized as:
ipctl->mdio_func[0] = -1;
ipctl->mdio_func[1] = -1;
I think you could safely make mdio_func integers, or either define an
INVALID value ( > 0), intialize them it that value and check against it for
validity.
Thanks
j
> --
> 2.17.1
>
signature.asc
Description: PGP signature
Re: [PATCH v2 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Hi again,
thanks to Morimoto-san, we got answers from the HW team.
I'm pasting them here below.
On Tue, Sep 11, 2018 at 11:44:30AM +0200, jacopo mondi wrote:
> Hi again,
>I actually noticed I'm handling VIN4 and VIN5 un-consistently
> here...
>
> On Tue, Sep 11, 2018 at 09:44:48AM +0200, jacopo mondi wrote:
> > Hi Simon,
> >thanks for looking into this patch
> >
> > On Mon, Sep 10, 2018 at 03:01:15PM +0200, Simon Horman wrote:
> > > On Wed, Sep 05, 2018 at 05:29:42PM +0200, Jacopo Mondi wrote:
> > > > This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
> > > >
> > > > Signed-off-by: Jacopo Mondi
> > > > ---
> > > > drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 250
> > > > ++
> > > > 1 file changed, 250 insertions(+)
> > > >
> > > > diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > > b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > > index b81c807..0797940 100644
> > > > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > > @@ -1831,6 +1831,194 @@ static const unsigned int usb30_id_mux[] = {
> > > > USB3HS0_ID_MARK,
> > > > };
> > > >
> > > > +/* - VIN4
> > > > --- */
> > > > +static const union vin_data vin4_data_a_pins = {
> > > > + .data24 = {
> > > > + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
> > > > + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
> > > > + RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
> > > > + RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
> > > > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> > > > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> > > > + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
> > > > + RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
> > > > + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
> > > > + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
> > > > + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
> > > > + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
> > > > + },
> > > > +};
> > > > +
> > > > +static const union vin_data vin4_data_a_mux = {
> > > > + .data24 = {
> > > > + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
> > > > + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
> > > > + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
> > > > + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
> > > > + VI4_DATA8_MARK, VI4_DATA9_MARK,
> > > > + VI4_DATA10_MARK, VI4_DATA11_MARK,
> > > > + VI4_DATA12_MARK, VI4_DATA13_MARK,
> > > > + VI4_DATA14_MARK, VI4_DATA15_MARK,
> > > > + VI4_DATA16_MARK, VI4_DATA17_MARK,
> > > > + VI4_DATA18_MARK, VI4_DATA19_MARK,
> > > > + VI4_DATA20_MARK, VI4_DATA21_MARK,
> > > > + VI4_DATA22_MARK, VI4_DATA23_MARK,
> > > > + },
> > > > +};
> > > > +
> > > > +static const union vin_data vin4_data_b_pins = {
> > > > + .data24 = {
> > > > + RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
> > > > + RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
> > > > + RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
> > > > + RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
> > >
> > > I am curious to know why the data B pins below (8 - 23)
> > > are duplicates of the corresponding data A pins in vin4_data_a_pins.
> > >
> >
> > On R-Car E3 only pins [0-7] of VIN4 interface have an '_a' and '_b'
> > options. Pins from [8-23] are "shared".
> >
> > We can discuss how we want this to be handled, but according to Table
> > 6D.5 (pag. 383 of R-Car chip manual revision 1.00) this table is
> > correct.
> >
> > Currently there are two open questions on this PFC patch:
> > 1) This one here you reported
>
> It does not end here, I'm sorry.
>
> VIN4 and VIN5 are described differently, it seems to me that we have
>
> vin4_data[0-7]_[a|b]
> vin4_data[8-23]
> vin4_sync
>
> vin5_data[0-7]_[a|b]
> vin5_data[8-15]_a
> vin5_sync_a
&g
Re: [PATCH 07/30] media: entity: Add has_route entity operation
Hello,
thank you all for the patches!
On Thu, Aug 23, 2018 at 03:25:21PM +0200, Niklas Söderlund wrote:
> From: Laurent Pinchart
>
> The optional operation can be used by entities to report whether two
> pads are internally connected.
>
> Signed-off-by: Laurent Pinchart
> Signed-off-by: Michal Simek
> Signed-off-by: Sakari Ailus
> ---
> include/media/media-entity.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> index 532c438b9eb862c5..07df1b8d85a3c1ba 100644
> --- a/include/media/media-entity.h
> +++ b/include/media/media-entity.h
> @@ -193,6 +193,9 @@ struct media_pad {
> * @link_validate: Return whether a link is valid from the entity point of
> * view. The media_pipeline_start() function
> * validates all links by calling this operation. Optional.
> + * @has_route: Return whether a route exists inside the entity
> between
> + * two given pads. Optional. If the operation isn't
> + * implemented all pads will be considered as connected.
> *
> * .. note::
> *
> @@ -205,6 +208,8 @@ struct media_entity_operations {
> const struct media_pad *local,
> const struct media_pad *remote, u32 flags);
> int (*link_validate)(struct media_link *link);
> + bool (*has_route)(struct media_entity *entity, unsigned int pad0,
> + unsigned int pad1);
In one next patch in the series:
[PATCH 09/30] media: entity: Swap pads if route is checked from source to sink
the media_entity_has_route() operations ensures the sink pad is always
the first one. Could we make it explicit in the paramters name and
documentation to ease understanding when driver will have to implement this?
Thanks
j
> };
>
> /**
> --
> 2.18.0
>
signature.asc
Description: PGP signature
Re: [PATCH v2 8/8] arm64: dts: renesas: ebisu: Add HDMI and CVBS input
Hi Simon, On Wed, Sep 12, 2018 at 11:29:51AM +0200, Simon Horman wrote: > On Mon, Sep 10, 2018 at 05:21:08PM +0300, Laurent Pinchart wrote: > > Hi Jacopo, > > > > Thank you for the patch. > > > > On Wednesday, 5 September 2018 18:29:45 EEST Jacopo Mondi wrote: > > > Add HDMI and CVBS inputs device nodes to R-Car E3 Ebisu board. > > > > > > Both HDMI and CVBS inputs are connected to an ADV7482 video decoder hooked > > > to the SoC CSI-2 receiver port. > > > > > > Signed-off-by: Jacopo Mondi > > > > Reviewed-by: Laurent Pinchart > > Jacopo, > > I assume that this patch depends on 7/8. > Please repost this patch when you repost that one, > addressing Laurent's feedback. Sorry, I'm now confused :) I don't see any pending comment on [7/8] nor on this one ([8/8]). [7/8] has been applied to your "arm64-dt-for-v4.20" branch already (just checked). I have a small comment on [6/8] and one open question on [5/8]. All the other patches have been reviewed/acked already. To sum up: do you want me to repost [7/8] when re-sending this series? Thanks j signature.asc Description: PGP signature
Re: [PATCH v2 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Hi again,
I actually noticed I'm handling VIN4 and VIN5 un-consistently
here...
On Tue, Sep 11, 2018 at 09:44:48AM +0200, jacopo mondi wrote:
> Hi Simon,
>thanks for looking into this patch
>
> On Mon, Sep 10, 2018 at 03:01:15PM +0200, Simon Horman wrote:
> > On Wed, Sep 05, 2018 at 05:29:42PM +0200, Jacopo Mondi wrote:
> > > This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
> > >
> > > Signed-off-by: Jacopo Mondi
> > > ---
> > > drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 250
> > > ++
> > > 1 file changed, 250 insertions(+)
> > >
> > > diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > index b81c807..0797940 100644
> > > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > > @@ -1831,6 +1831,194 @@ static const unsigned int usb30_id_mux[] = {
> > > USB3HS0_ID_MARK,
> > > };
> > >
> > > +/* - VIN4
> > > --- */
> > > +static const union vin_data vin4_data_a_pins = {
> > > + .data24 = {
> > > + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
> > > + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
> > > + RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
> > > + RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
> > > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> > > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> > > + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
> > > + RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
> > > + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
> > > + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
> > > + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
> > > + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
> > > + },
> > > +};
> > > +
> > > +static const union vin_data vin4_data_a_mux = {
> > > + .data24 = {
> > > + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
> > > + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
> > > + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
> > > + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
> > > + VI4_DATA8_MARK, VI4_DATA9_MARK,
> > > + VI4_DATA10_MARK, VI4_DATA11_MARK,
> > > + VI4_DATA12_MARK, VI4_DATA13_MARK,
> > > + VI4_DATA14_MARK, VI4_DATA15_MARK,
> > > + VI4_DATA16_MARK, VI4_DATA17_MARK,
> > > + VI4_DATA18_MARK, VI4_DATA19_MARK,
> > > + VI4_DATA20_MARK, VI4_DATA21_MARK,
> > > + VI4_DATA22_MARK, VI4_DATA23_MARK,
> > > + },
> > > +};
> > > +
> > > +static const union vin_data vin4_data_b_pins = {
> > > + .data24 = {
> > > + RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
> > > + RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
> > > + RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
> > > + RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
> >
> > I am curious to know why the data B pins below (8 - 23)
> > are duplicates of the corresponding data A pins in vin4_data_a_pins.
> >
>
> On R-Car E3 only pins [0-7] of VIN4 interface have an '_a' and '_b'
> options. Pins from [8-23] are "shared".
>
> We can discuss how we want this to be handled, but according to Table
> 6D.5 (pag. 383 of R-Car chip manual revision 1.00) this table is
> correct.
>
> Currently there are two open questions on this PFC patch:
> 1) This one here you reported
It does not end here, I'm sorry.
VIN4 and VIN5 are described differently, it seems to me that we have
vin4_data[0-7]_[a|b]
vin4_data[8-23]
vin4_sync
vin5_data[0-7]_[a|b]
vin5_data[8-15]_a
vin5_sync_a
So I handled it differently, as I've registered the following data groups
for VIN4
> > > + "vin4_data8_a",
> > > + "vin4_data10_a",
> > > + "vin4_data12_a",
> > > + "vin4_data16_a",
> > > + "vin4_data20_a",
> > > + "vin4_data24_a",
> > > + "vin4_data8_b",
> > > + "vin4_data10_b",
> > > + "vin4_data12_b",
> > > + "vin4_data16_b",
> > > + "vin4_data20_b",
> > > + "vin4_data24_b",
And the following ones for VIN5
> > > + "vin5_data8_a",
> > > + "vin5_data10_a",
> > > + "vin5_data12_a",
> > > + "vin5_data16_a",
> > > +
Re: [PATCH v2 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Hi Geert,
On Tue, Sep 11, 2018 at 10:15:23AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Tue, Sep 11, 2018 at 9:44 AM jacopo mondi wrote:
> > On Mon, Sep 10, 2018 at 03:01:15PM +0200, Simon Horman wrote:
> > > On Wed, Sep 05, 2018 at 05:29:42PM +0200, Jacopo Mondi wrote:
> > > > This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
>
> > Currently there are two open questions on this PFC patch:
>
> > 2) VIN5 synchronism signals (V/HSYNC, CLKENB, FIELD) are marked as
> >"_A" only, while VIN4 ones have not _A or _B extensions and are
> >shared between _A and _B group. The VIN5_#_A extension is an
> >indication that synchronism signals for group _B are not
> >multiplexed but active be default according to Morimoto-san, that
> >is about to confirm this with HW team. In that case, we need to
> >decide if to provide an 'vin5_sync_b' group anyway to let user
> >select it from DTS. Otherwise it won't be possible to select
> >synchronism pins for VIN5_B group (which is maybe fine if they're
> >not multiplexed at all).
>
> If the a "B" sync group exists, the pins are probably configurable as GPIOs,
> too, so we probably do need a group for them in the driver.
>
The chip manual does not report any _b group, and I don't have any E3
pin-related documentation like I have for M3-W/N
(r01uh0802ej0100-r-car-3rd-pin.pdf,
ASOM-C18-201_R-CarM3_pinfunction.xls etc etc)
How to find it out? Morimoto-san have you heard any news from HW team?
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
signature.asc
Description: PGP signature
Re: [PATCH v2 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Hi Simon,
thanks for looking into this patch
On Mon, Sep 10, 2018 at 03:01:15PM +0200, Simon Horman wrote:
> On Wed, Sep 05, 2018 at 05:29:42PM +0200, Jacopo Mondi wrote:
> > This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 250
> > ++
> > 1 file changed, 250 insertions(+)
> >
> > diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > index b81c807..0797940 100644
> > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > @@ -1831,6 +1831,194 @@ static const unsigned int usb30_id_mux[] = {
> > USB3HS0_ID_MARK,
> > };
> >
> > +/* - VIN4
> > --- */
> > +static const union vin_data vin4_data_a_pins = {
> > + .data24 = {
> > + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
> > + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
> > + RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
> > + RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> > + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
> > + RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
> > + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
> > + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
> > + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
> > + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
> > + },
> > +};
> > +
> > +static const union vin_data vin4_data_a_mux = {
> > + .data24 = {
> > + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
> > + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
> > + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
> > + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
> > + VI4_DATA8_MARK, VI4_DATA9_MARK,
> > + VI4_DATA10_MARK, VI4_DATA11_MARK,
> > + VI4_DATA12_MARK, VI4_DATA13_MARK,
> > + VI4_DATA14_MARK, VI4_DATA15_MARK,
> > + VI4_DATA16_MARK, VI4_DATA17_MARK,
> > + VI4_DATA18_MARK, VI4_DATA19_MARK,
> > + VI4_DATA20_MARK, VI4_DATA21_MARK,
> > + VI4_DATA22_MARK, VI4_DATA23_MARK,
> > + },
> > +};
> > +
> > +static const union vin_data vin4_data_b_pins = {
> > + .data24 = {
> > + RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
> > + RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
> > + RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
> > + RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
>
> I am curious to know why the data B pins below (8 - 23)
> are duplicates of the corresponding data A pins in vin4_data_a_pins.
>
On R-Car E3 only pins [0-7] of VIN4 interface have an '_a' and '_b'
options. Pins from [8-23] are "shared".
We can discuss how we want this to be handled, but according to Table
6D.5 (pag. 383 of R-Car chip manual revision 1.00) this table is
correct.
Currently there are two open questions on this PFC patch:
1) This one here you reported
... (see below)
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> > + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
> > + RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
> > + RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
> > + RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 15),
> > + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
> > + RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
> > + },
> > +};
> > +
> > +static const union vin_data vin4_data_b_mux = {
> > + .data24 = {
> > + VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
> > + VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
> > + VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
> > + VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
> > + VI4_DATA8_MARK, VI4_DATA9_MARK,
> > + VI4_DATA10_MARK, VI4_DATA11_MARK,
> > + VI4_DATA12_MARK, VI4_DATA13_MARK,
> > + VI4_DATA14_MARK, VI4_DATA15_MARK,
> > + VI4_DATA16_MARK, VI4_DATA17_MARK,
> > + VI4_DATA18_MARK, VI4_DATA19_MARK,
> > + VI4_DATA20_MARK, VI4_DATA21_MARK,
> > + VI4_DATA22_MARK, VI4_DATA23_MARK,
> > + },
> > +};
> > +
> > +static const unsigned int vin4_sync_pins[] = {
> > + /* HSYNC, VSYNC */
> > + RCAR_GP_PIN(2,
[PATCH v2 8/8] arm64: dts: renesas: ebisu: Add HDMI and CVBS input
Add HDMI and CVBS inputs device nodes to R-Car E3 Ebisu board.
Both HDMI and CVBS inputs are connected to an ADV7482 video decoder hooked to
the SoC CSI-2 receiver port.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 86 ++
1 file changed, 86 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
index 2bc3a48..d2faf3e 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts
@@ -28,6 +28,29 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x3800>;
};
+
+ cvbs-in {
+ compatible = "composite-video-connector";
+ label = "CVBS IN";
+
+ port {
+ cvbs_con: endpoint {
+ remote-endpoint = <_ain7>;
+ };
+ };
+ };
+
+ hdmi-in {
+ compatible = "hdmi-connector";
+ label = "HDMI IN";
+ type = "a";
+
+ port {
+ hdmi_in_con: endpoint {
+ remote-endpoint = <_hdmi>;
+ };
+ };
+ };
};
{
@@ -47,6 +70,22 @@
};
};
+ {
+ status = "okay";
+
+ ports {
+ port@0 {
+ reg = <0>;
+
+ csi40_in: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ remote-endpoint = <_txa>;
+ };
+ };
+ };
+};
+
{
status = "okay";
};
@@ -55,6 +94,49 @@
clock-frequency = <4800>;
};
+ {
+ status = "okay";
+
+ video-receiver@70 {
+ compatible = "adi,adv7482";
+ reg = <0x70>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ interrupt-parent = <>;
+ interrupt-names = "intrq1", "intrq2";
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>,
+<17 IRQ_TYPE_LEVEL_LOW>;
+
+ port@7 {
+ reg = <7>;
+
+ adv7482_ain7: endpoint {
+ remote-endpoint = <_con>;
+ };
+ };
+
+ port@8 {
+ reg = <8>;
+
+ adv7482_hdmi: endpoint {
+ remote-endpoint = <_in_con>;
+ };
+ };
+
+ port@a {
+ reg = <0xa>;
+
+ adv7482_txa: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+};
+
{
status = "okay";
};
@@ -94,6 +176,10 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
--
2.7.4
[PATCH v2 2/8] media: rcar-vin: Add support for R-Car R8A77990
Add R-Car E3 R8A77990 SoC to the rcar-vin supported ones.
Based on the experimental patch from Magnus Damm.
Signed-off-by: Jacopo Mondi
---
drivers/media/platform/rcar-vin/rcar-core.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index ce09799..d443c09 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1085,6 +1085,22 @@ static const struct rvin_info rcar_info_r8a77970 = {
.routes = rcar_info_r8a77970_routes,
};
+static const struct rvin_group_route rcar_info_r8a77990_routes[] = {
+ { .csi = RVIN_CSI40, .channel = 0, .vin = 4, .mask = BIT(0) | BIT(3) },
+ { .csi = RVIN_CSI40, .channel = 0, .vin = 5, .mask = BIT(2) },
+ { .csi = RVIN_CSI40, .channel = 1, .vin = 4, .mask = BIT(2) },
+ { .csi = RVIN_CSI40, .channel = 1, .vin = 5, .mask = BIT(1) | BIT(3) },
+ { /* Sentinel */ }
+};
+
+static const struct rvin_info rcar_info_r8a77990 = {
+ .model = RCAR_GEN3,
+ .use_mc = true,
+ .max_width = 4096,
+ .max_height = 4096,
+ .routes = rcar_info_r8a77990_routes,
+};
+
static const struct rvin_group_route rcar_info_r8a77995_routes[] = {
{ /* Sentinel */ }
};
@@ -1143,6 +1159,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.data = _info_r8a77970,
},
{
+ .compatible = "renesas,vin-r8a77990",
+ .data = _info_r8a77990,
+ },
+ {
.compatible = "renesas,vin-r8a77995",
.data = _info_r8a77995,
},
--
2.7.4
[PATCH/RFT v2 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hello renesas list, this series add supports for the HDMI and CVBS input to R-Car E3 R8A77990 Ebisu board. It's an RFT, as I don't have an Ebisu to test with :( The series adds supports for the following items: - PFC: add VIN groups and functions - R-Car VIN and R-Car CSI-2: add support for R8A77990 - R8A77990: Add I2C, VIN and CSI-2 nodes (v1 re-sent by Laurent in D3 DU series) - Ebisu: describe HDMI and CVBS inputs Laurent has tested v1 and confirmed that the current mainline implementation of the adv748x driver does not work in the configuration used by the Ebisu board. This series should then be applied on top of the just sent: [PATCH v2 0/5] media: adv748x: Allow probe with a single output endpoint To allow the adv7482 to probe with a single output port enabled. This series, based on v4.19-rc2 with adv748x series on top, is available at: git://jmondi.org/linux ebisu/linus-master/hdmi_cvbs_v2 Thanks j Jacopo Mondi (6): media: dt-bindings: rcar-vin: Add R8A77990 support media: rcar-vin: Add support for R-Car R8A77990 media: dt-bindings: rcar-csi2: Add R8A77990 media: rcar-csi2: Add R8A77990 support pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions arm64: dts: renesas: ebisu: Add HDMI and CVBS input Koji Matsuoka (1): arm64: dts: r8a77990: Add VIN and CSI-2 device nodes Takeshi Kihara (1): arm64: dts: r8a77990: Add I2C device nodes .../devicetree/bindings/media/rcar_vin.txt | 1 + .../bindings/media/renesas,rcar-csi2.txt | 1 + arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 86 +++ arch/arm64/boot/dts/renesas/r8a77990.dtsi | 202 + drivers/media/platform/rcar-vin/rcar-core.c| 20 ++ drivers/media/platform/rcar-vin/rcar-csi2.c| 9 + drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 250 + 7 files changed, 569 insertions(+) -- 2.7.4
[PATCH v2 6/8] arm64: dts: r8a77990: Add VIN and CSI-2 device nodes
From: Koji Matsuoka
Add device nodes for VIN4, VIN5 and CSI40 to R-Car E3 R8A77990 device tree.
Signed-off-by: Koji Matsuoka
Signed-off-by: Takeshi Kihara
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 79 +++
1 file changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index ae89260..0ae7bbe 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -337,6 +337,85 @@
status = "disabled";
};
+ csi40: csi2@feaa {
+ compatible = "renesas,r8a77990-csi2",
"renesas,rcar-gen3-csi2";
+ reg = <0 0xfeaa 0 0x1>;
+ interrupts = ;
+ clocks = < CPG_MOD 716>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 716>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg = <1>;
+
+ csi40vin4: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <>;
+ };
+ csi40vin5: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <>;
+ };
+ };
+ };
+ };
+
+ vin4: video@e6ef4000 {
+ compatible = "renesas,vin-r8a77990";
+ reg = <0 0xe6ef4000 0 0x1000>;
+ interrupts = ;
+ clocks = < CPG_MOD 807>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 807>;
+ renesas,id = <4>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ vin4csi40: endpoint {
+ remote-endpoint= <>;
+ };
+ };
+ };
+ };
+
+ vin5: video@e6ef5000 {
+ compatible = "renesas,vin-r8a77990";
+ reg = <0 0xe6ef5000 0 0x1000>;
+ interrupts = ;
+ clocks = < CPG_MOD 806>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 806>;
+ renesas,id = <5>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ vin5csi40: endpoint {
+ remote-endpoint= <>;
+ };
+ };
+ };
+ };
+
scif2: serial@e6e88000 {
compatible = "renesas,scif-r8a77990",
"renesas,rcar-gen3-scif", "renesas,scif";
--
2.7.4
[PATCH v2 1/8] media: dt-bindings: rcar-vin: Add R8A77990 support
Add compatible string for R-Car E3 R8A77990 to the list of SoCs supported by rcar-vin driver. Signed-off-by: Jacopo Mondi Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/media/rcar_vin.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt index 2f42005..dfd6058 100644 --- a/Documentation/devicetree/bindings/media/rcar_vin.txt +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt @@ -23,6 +23,7 @@ on Gen3 platforms to a CSI-2 receiver. - "renesas,vin-r8a7796" for the R8A7796 device - "renesas,vin-r8a77965" for the R8A77965 device - "renesas,vin-r8a77970" for the R8A77970 device + - "renesas,vin-r8a77990" for the R8A77990 device - "renesas,vin-r8a77995" for the R8A77995 device - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible device. -- 2.7.4
[PATCH v2 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
Signed-off-by: Jacopo Mondi
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 250 ++
1 file changed, 250 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index b81c807..0797940 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1831,6 +1831,194 @@ static const unsigned int usb30_id_mux[] = {
USB3HS0_ID_MARK,
};
+/* - VIN4 ---
*/
+static const union vin_data vin4_data_a_pins = {
+ .data24 = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_a_mux = {
+ .data24 = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const union vin_data vin4_data_b_pins = {
+ .data24 = {
+ RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 11),
+ RCAR_GP_PIN(1, 21), RCAR_GP_PIN(1, 22),
+ RCAR_GP_PIN(0, 5), RCAR_GP_PIN(0, 6),
+ RCAR_GP_PIN(0, 16), RCAR_GP_PIN(0, 17),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 15),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+ },
+};
+
+static const union vin_data vin4_data_b_mux = {
+ .data24 = {
+ VI4_DATA0_B_MARK, VI4_DATA1_B_MARK,
+ VI4_DATA2_B_MARK, VI4_DATA3_B_MARK,
+ VI4_DATA4_B_MARK, VI4_DATA5_B_MARK,
+ VI4_DATA6_B_MARK, VI4_DATA7_B_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+ VI4_DATA20_MARK, VI4_DATA21_MARK,
+ VI4_DATA22_MARK, VI4_DATA23_MARK,
+ },
+};
+
+static const unsigned int vin4_sync_pins[] = {
+ /* HSYNC, VSYNC */
+ RCAR_GP_PIN(2, 25), RCAR_GP_PIN(2, 24),
+};
+
+static const unsigned int vin4_sync_mux[] = {
+ VI4_HSYNC_N_MARK, VI4_VSYNC_N_MARK,
+};
+
+static const unsigned int vin4_field_pins[] = {
+ RCAR_GP_PIN(2, 23),
+};
+
+static const unsigned int vin4_field_mux[] = {
+ VI4_FIELD_MARK,
+};
+
+static const unsigned int vin4_clkenb_pins[] = {
+ RCAR_GP_PIN(1, 2),
+};
+
+static const unsigned int vin4_clkenb_mux[] = {
+ VI4_CLKENB_MARK,
+};
+
+static const unsigned int vin4_clk_pins[] = {
+ RCAR_GP_PIN(2, 22),
+};
+
+static const unsigned int vin4_clk_mux[] = {
+ VI4_CLK_MARK,
+};
+
+/* - VIN5 ---
*/
+static const union vin_data vin5_data_a_pins = {
+ .data16 = {
+ RCAR_GP_PIN(1, 1), RCAR_GP_PIN(1, 2),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(0, 12), RCAR_GP_PIN(0, 13),
+ RCAR_GP_PIN(0, 9), RCAR_GP_PIN(0, 11),
+ RCAR_GP_PIN(0, 8), RCAR_GP_PIN(0, 10),
+ RCAR_GP_PIN(0, 2), RCAR_GP_PIN(0, 3),
+ },
+};
+
+static const union vin_data vin5_data_a_mux = {
+ .data16 = {
+ VI5_DATA0_A_MARK, VI5_DATA1_A_MARK
[PATCH v2 7/8] arm64: dts: r8a77990: Add I2C device nodes
From: Takeshi Kihara
Add device nodes for I2C ch[0-7] to R-Car E3 R8A77990 device tree.
Signed-off-by: Takeshi Kihara
Signed-off-by: Jacopo Mondi
Reviewed-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 123 ++
1 file changed, 123 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
index 0ae7bbe..a1badfe 100644
--- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
@@ -14,6 +14,17 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 =
+ i2c1 =
+ i2c2 =
+ i2c3 =
+ i2c4 =
+ i2c5 =
+ i2c6 =
+ i2c7 =
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -185,6 +196,118 @@
resets = < 906>;
};
+ i2c0: i2c@e650 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a77990",
+"renesas,rcar-gen3-i2c";
+ reg = <0 0xe650 0 0x40>;
+ interrupts = ;
+ clocks = < CPG_MOD 931>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 931>;
+ i2c-scl-internal-delay-ns = <110>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@e6508000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a77990",
+"renesas,rcar-gen3-i2c";
+ reg = <0 0xe6508000 0 0x40>;
+ interrupts = ;
+ clocks = < CPG_MOD 930>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 930>;
+ i2c-scl-internal-delay-ns = <6>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@e651 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a77990",
+"renesas,rcar-gen3-i2c";
+ reg = <0 0xe651 0 0x40>;
+ interrupts = ;
+ clocks = < CPG_MOD 929>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 929>;
+ i2c-scl-internal-delay-ns = <6>;
+ status = "disabled";
+ };
+
+ i2c3: i2c@e66d {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a77990",
+"renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d 0 0x40>;
+ interrupts = ;
+ clocks = < CPG_MOD 928>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 928>;
+ i2c-scl-internal-delay-ns = <110>;
+ status = "disabled";
+ };
+
+ i2c4: i2c@e66d8000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a77990",
+"renesas,rcar-gen3-i2c";
+ reg = <0 0xe66d8000 0 0x40>;
+ interrupts = ;
+ clocks = < CPG_MOD 927>;
+ power-domains = < R8A77990_PD_ALWAYS_ON>;
+ resets = < 927>;
+ i2c-scl-internal-delay-ns = <6>;
+ status = "disabled";
+ };
+
+ i2c5: i2c@e66e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "renesas,i2c-r8a77990",
+"renesas,rcar-gen3-i2c";
+ reg = <0 0xe66e 0 0x40>;
+ interrupts = ;
+ clocks = < CPG_MOD 919>;
+ power-dom
[PATCH v2 4/8] media: rcar-csi2: Add R8A77990 support
Add support for R-Car E3 R8A77965 to R-Car CSI-2 driver.
Based on the experimental patch from Magnus Damm.
Signed-off-by: Jacopo Mondi
---
drivers/media/platform/rcar-vin/rcar-csi2.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
b/drivers/media/platform/rcar-vin/rcar-csi2.c
index dc5ae80..f82b668 100644
--- a/drivers/media/platform/rcar-vin/rcar-csi2.c
+++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
@@ -959,6 +959,11 @@ static const struct rcar_csi2_info rcar_csi2_info_r8a77970
= {
.confirm_start = rcsi2_confirm_start_v3m_e3,
};
+static const struct rcar_csi2_info rcar_csi2_info_r8a77990 = {
+ .init_phtw = rcsi2_init_phtw_v3m_e3,
+ .confirm_start = rcsi2_confirm_start_v3m_e3,
+};
+
static const struct of_device_id rcar_csi2_of_table[] = {
{
.compatible = "renesas,r8a7795-csi2",
@@ -976,6 +981,10 @@ static const struct of_device_id rcar_csi2_of_table[] = {
.compatible = "renesas,r8a77970-csi2",
.data = _csi2_info_r8a77970,
},
+ {
+ .compatible = "renesas,r8a77990-csi2",
+ .data = _csi2_info_r8a77990,
+ },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, rcar_csi2_of_table);
--
2.7.4
[PATCH v2 3/8] media: dt-bindings: rcar-csi2: Add R8A77990
Add compatible string for R-Car E3 R8A77990 to the list of supported SoCs. Signed-off-by: Jacopo Mondi Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt index 2d385b6..2824489 100644 --- a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt +++ b/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt @@ -12,6 +12,7 @@ Mandatory properties - "renesas,r8a7796-csi2" for the R8A7796 device. - "renesas,r8a77965-csi2" for the R8A77965 device. - "renesas,r8a77970-csi2" for the R8A77970 device. + - "renesas,r8a77990-csi2" for the R8A77990 device. - reg: the register base and size for the device registers - interrupts: the interrupt for the device -- 2.7.4
Re: [RFT 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Hi Geert,
On Tue, Aug 28, 2018 at 09:46:57AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Mon, Aug 20, 2018 at 12:17 PM Jacopo Mondi
> wrote:
> > From: Takeshi Kihara
> >
> > This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
> >
> > Signed-off-by: Takeshi Kihara
> > Signed-off-by: Jacopo Mondi
>
> Thanks for your patch!
Thanks for review.
>
> > --- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
> > @@ -1982,6 +1982,446 @@ static const unsigned int usb30_id_mux[] = {
> > USB3HS0_ID_MARK,
> > };
> >
> > +/* - VIN4
> > --- */
> > +static const unsigned int vin4_data8_a_pins[] = {
> > + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
> > + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
> > + RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
> > + RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
> > +};
> > +
> > +static const unsigned int vin4_data8_a_mux[] = {
> > + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
> > + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
> > + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
> > + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
> > +};
> > +
> > +static const unsigned int vin4_data10_a_pins[] = {
> > + RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
> > + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
> > + RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
> > + RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> > +};
> > +
> > +static const unsigned int vin4_data10_a_mux[] = {
> > + VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
> > + VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
> > + VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
> > + VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
> > + VI4_DATA8_MARK, VI4_DATA9_MARK,
> > +};
>
> Can you please use union vin_data and VIN_DATA_PIN_GROUP(), to reduce
> redundancies, cfr. commit 9942a5b52990b8d5 ("pinctrl: sh-pfc: r8a7795:
> Deduplicate VIN4 pin definitions")?
> Or do you want to do that in a follow-up patch (which means more
> review work)?
I will have to resend anyhow, so I can make this change in v2.
>
> > +static const unsigned int vin4_data8_sft8_pins[] = {
> > + RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
> > + RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
> > + RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
> > + RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
> > +};
>
> R-Car H3 and M3-W don't have the data8_sft8 groups yet (the BSP has).
> IIRC, that's due to rcar-vin not yet supporting that mode. Niklas?
Not sure what SFT mode is. The only registers naming this are related
to "Shift Down Volume" and RGB->YCrCb conversion. I'll wait for
Niklas, and eventually remove the pin group.
>
> > +static const unsigned int vin5_sync_a_pins[] = {
> > + /* HSYNC_N, VSYNC_N */
> > + RCAR_GP_PIN(1, 8), RCAR_GP_PIN(1, 9),
> > +};
> > +
> > +static const unsigned int vin5_sync_a_mux[] = {
> > + VI5_HSYNC_N_A_MARK, VI5_VSYNC_N_A_MARK,
> > +};
> > +
> > +static const unsigned int vin5_field_a_pins[] = {
> > + RCAR_GP_PIN(1, 10),
> > +};
> > +
> > +static const unsigned int vin5_field_a_mux[] = {
> > + VI5_FIELD_A_MARK,
> > +};
> > +
> > +static const unsigned int vin5_clkenb_a_pins[] = {
> > + RCAR_GP_PIN(0, 1),
> > +};
> > +
> > +static const unsigned int vin5_clkenb_a_mux[] = {
> > + VI5_CLKENB_A_MARK,
> > +};
>
> "A" groups without "B" groups? Usually we drop the "_A" suffix in that case.
>
> They're actually named like that in hardware user manual rev. 1.00 (and no
> update in the errata)?
It's true, the sync signal pins of VI4 do not have any "_a" or "_b"
mark, while the VI5 ones do. Eg. we have "VI5_VSYNC#_A" and
"VI4_VSYNC#". This might be an error in the chip manual or a
suggestion that VIN5_DATA.*_B pins do not support synchronism signals
and can only work with embedded synchronization. This seems unlikely
to me, and checking Table 26.20.3 that lists the supported input format
for each channel, I don't see anything like that mentioned.
Morimoto-san, Shimoda-san, could you please verify why those pins,
have a different naming scheme?
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
signature.asc
Description: PGP signature
Re: [RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hi Niklas, On Mon, Aug 27, 2018 at 03:23:45PM +0200, Niklas Söderlund wrote: > Hi Jacopo, > > On 2018-08-27 11:49:56 +0200, Jacopo Mondi wrote: > > Hi Niklas, > > A few more talk on the adv748x link handling, please bear with me... > > > > On Sat, Aug 25, 2018 at 03:18:06PM +0200, jacopo mondi wrote: > > > Hi Laurent, Niklas, > > > > > > On Sat, Aug 25, 2018 at 08:37:15AM +0200, Niklas Söderlund wrote: > > > > Hi Laurent and Jacopo, > > > > > > > > On 2018-08-25 02:54:44 +0300, Laurent Pinchart wrote: > > > > > Hi Jacopo, > > > > > > > > > > On Monday, 20 August 2018 13:16:34 EEST Jacopo Mondi wrote: > > > > > > Hello renesas list, > > > > > >this series add supports for the HDMI and CVBS input to R-Car E3 > > > > > > R8A77990 > > > > > > Ebisu board. > > > > > > > > > > > > It's an RFT, as I don't have an Ebisu to test with :( > > > > > > > > > > > > The series adds supports for the following items: > > > > > > > > > > > > - PFC: add VIN groups and functions > > > > > > - R-Car VIN and R-Car CSI-2: add support for R8A77990 > > > > > > - R8A77990: Add I2C, VIN and CSI-2 nodes > > > > > > - Ebisu: describe HDMI and CVBS inputs > > > > > > > > > > > > Each patch, when relevant reports difference between the upported > > > > > > BSP patch > > > > > > and the proposed one. > > > > > > > > > > > > I know Laurent should receive an Ebisu sooner or later, maybe we > > > > > > can sync > > > > > > for testing :) > > > > > > > > > > I've given the series a first test, and I think a bit more work is > > > > > needed :-) > > > > > > > > > > [1.455533] adv748x 0-0070: Endpoint > > > > > /soc/i2c@e650/video-receiver@70/ > > > > > port@7/endpoint on port 7 > > > > > [1.464683] adv748x 0-0070: Endpoint > > > > > /soc/i2c@e650/video-receiver@70/ > > > > > port@8/endpoint on port 8 > > > > > [1.473728] adv748x 0-0070: Endpoint > > > > > /soc/i2c@e650/video-receiver@70/ > > > > > port@a/endpoint on port 10 > > > > > [1.484835] adv748x 0-0070: chip found @ 0xe0 revision 2143 > > > > > [1.639470] adv748x 0-0070: No endpoint found for txb > > > > > [1.644653] adv748x 0-0070: Failed to probe TXB > > > > > > > > I fear this is a design choice in the adv748x driver. Currently the > > > > driver requires both of its two CSI-2 transmitters to be connected/used > > > > else probe fails. Furthermore the HDMI capture is always routed to TXA > > > > while the analog capture is always routed to TXB. > > > > > > > > Now that we have a board where only TXA is connected but both HDMI and > > > > analog captures are used maybe it's time to do some more work on v4l2 > > > > and the adv748x driver ;-P What's missing: > > > > > > > > - Probe should be OK with either TXA or TXB connected and not bail if > > > > not both are used. > > > > > > I have three patches for this I hope to share as soon as I'll be able > > > to do some more testing > > > > > > > - The media_device_ops or at least the .link_notify() callback of that > > > > struct must be changed so not one driver in the media graph is > > > > responsible for all links. In this case rcar-vin provides the callback > > > > and rcar-vin should not judge which links between the adv748x > > > > subdevices are OK to enable/disable. Currently the links between the > > > > adv748x subdevices are immutably enabled to avoid this particular > > > > problem. > > > > > > Uh, I didn't get this :/ Care to elaborate more? > > > > > > > I'm thinking if it is not enough to just provide a .link_setup() > > callback to the (enabled) csi-2 sink pads of the adv748x and handle > > routing between the afe/hdmi sources and that sink, without the vin's > > registered link_notify playing any role in that. > > That is my point, the v4l2 framework needs work to allow all drivers to > provide a .link_setup() callback. And this as you describe will conflict > with the current
Re: [RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hi Niklas, A few more talk on the adv748x link handling, please bear with me... On Sat, Aug 25, 2018 at 03:18:06PM +0200, jacopo mondi wrote: > Hi Laurent, Niklas, > > On Sat, Aug 25, 2018 at 08:37:15AM +0200, Niklas Söderlund wrote: > > Hi Laurent and Jacopo, > > > > On 2018-08-25 02:54:44 +0300, Laurent Pinchart wrote: > > > Hi Jacopo, > > > > > > On Monday, 20 August 2018 13:16:34 EEST Jacopo Mondi wrote: > > > > Hello renesas list, > > > >this series add supports for the HDMI and CVBS input to R-Car E3 > > > > R8A77990 > > > > Ebisu board. > > > > > > > > It's an RFT, as I don't have an Ebisu to test with :( > > > > > > > > The series adds supports for the following items: > > > > > > > > - PFC: add VIN groups and functions > > > > - R-Car VIN and R-Car CSI-2: add support for R8A77990 > > > > - R8A77990: Add I2C, VIN and CSI-2 nodes > > > > - Ebisu: describe HDMI and CVBS inputs > > > > > > > > Each patch, when relevant reports difference between the upported BSP > > > > patch > > > > and the proposed one. > > > > > > > > I know Laurent should receive an Ebisu sooner or later, maybe we can > > > > sync > > > > for testing :) > > > > > > I've given the series a first test, and I think a bit more work is needed > > > :-) > > > > > > [1.455533] adv748x 0-0070: Endpoint > > > /soc/i2c@e650/video-receiver@70/ > > > port@7/endpoint on port 7 > > > [1.464683] adv748x 0-0070: Endpoint > > > /soc/i2c@e650/video-receiver@70/ > > > port@8/endpoint on port 8 > > > [1.473728] adv748x 0-0070: Endpoint > > > /soc/i2c@e650/video-receiver@70/ > > > port@a/endpoint on port 10 > > > [1.484835] adv748x 0-0070: chip found @ 0xe0 revision 2143 > > > [1.639470] adv748x 0-0070: No endpoint found for txb > > > [1.644653] adv748x 0-0070: Failed to probe TXB > > > > I fear this is a design choice in the adv748x driver. Currently the > > driver requires both of its two CSI-2 transmitters to be connected/used > > else probe fails. Furthermore the HDMI capture is always routed to TXA > > while the analog capture is always routed to TXB. > > > > Now that we have a board where only TXA is connected but both HDMI and > > analog captures are used maybe it's time to do some more work on v4l2 > > and the adv748x driver ;-P What's missing: > > > > - Probe should be OK with either TXA or TXB connected and not bail if > > not both are used. > > I have three patches for this I hope to share as soon as I'll be able > to do some more testing > > > - The media_device_ops or at least the .link_notify() callback of that > > struct must be changed so not one driver in the media graph is > > responsible for all links. In this case rcar-vin provides the callback > > and rcar-vin should not judge which links between the adv748x > > subdevices are OK to enable/disable. Currently the links between the > > adv748x subdevices are immutably enabled to avoid this particular > > problem. > > Uh, I didn't get this :/ Care to elaborate more? > I'm thinking if it is not enough to just provide a .link_setup() callback to the (enabled) csi-2 sink pads of the adv748x and handle routing between the afe/hdmi sources and that sink, without the vin's registered link_notify playing any role in that. > What I was about to do, instead, given the fixed HDMI->TXA and AFE->TXB > routing in the adv748x driver was to insert a .link_validate() callback for > both the HDMI and AFE backends, that checks for the availability of > the corresponding output endpoint. This seems to me that this makes > easy when dynamic routing will be added to do the same on the > dynamically configured sink pad. > What do you think? On a second thought if a CSI-2 sink it's not enabled it is not part of the media graph neither, so it should not be possible to link it in any pipeline, so no link validation is required. The link simply can't exist. It seems to me that to support Ebisu-like designs is then enough to make the adv748x driver probe with a single csi-2 output enabled and handle power management accordingly. I will share patches for this briefly. > > Thanks > j > > > > > > > > > > PS: the list of upported patches will be sent separately. > > > > > > > > Jacopo Mondi (5): > > > > media: dt-bindings: media: rcar-vin: Add R8A77990 su
Re: [RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hi Laurent, Niklas, On Sat, Aug 25, 2018 at 08:37:15AM +0200, Niklas Söderlund wrote: > Hi Laurent and Jacopo, > > On 2018-08-25 02:54:44 +0300, Laurent Pinchart wrote: > > Hi Jacopo, > > > > On Monday, 20 August 2018 13:16:34 EEST Jacopo Mondi wrote: > > > Hello renesas list, > > >this series add supports for the HDMI and CVBS input to R-Car E3 > > > R8A77990 > > > Ebisu board. > > > > > > It's an RFT, as I don't have an Ebisu to test with :( > > > > > > The series adds supports for the following items: > > > > > > - PFC: add VIN groups and functions > > > - R-Car VIN and R-Car CSI-2: add support for R8A77990 > > > - R8A77990: Add I2C, VIN and CSI-2 nodes > > > - Ebisu: describe HDMI and CVBS inputs > > > > > > Each patch, when relevant reports difference between the upported BSP > > > patch > > > and the proposed one. > > > > > > I know Laurent should receive an Ebisu sooner or later, maybe we can sync > > > for testing :) > > > > I've given the series a first test, and I think a bit more work is needed > > :-) > > > > [1.455533] adv748x 0-0070: Endpoint /soc/i2c@e650/video-receiver@70/ > > port@7/endpoint on port 7 > > [1.464683] adv748x 0-0070: Endpoint /soc/i2c@e650/video-receiver@70/ > > port@8/endpoint on port 8 > > [1.473728] adv748x 0-0070: Endpoint /soc/i2c@e650/video-receiver@70/ > > port@a/endpoint on port 10 > > [1.484835] adv748x 0-0070: chip found @ 0xe0 revision 2143 > > [1.639470] adv748x 0-0070: No endpoint found for txb > > [1.644653] adv748x 0-0070: Failed to probe TXB > > I fear this is a design choice in the adv748x driver. Currently the > driver requires both of its two CSI-2 transmitters to be connected/used > else probe fails. Furthermore the HDMI capture is always routed to TXA > while the analog capture is always routed to TXB. > > Now that we have a board where only TXA is connected but both HDMI and > analog captures are used maybe it's time to do some more work on v4l2 > and the adv748x driver ;-P What's missing: > > - Probe should be OK with either TXA or TXB connected and not bail if > not both are used. I have three patches for this I hope to share as soon as I'll be able to do some more testing > - The media_device_ops or at least the .link_notify() callback of that > struct must be changed so not one driver in the media graph is > responsible for all links. In this case rcar-vin provides the callback > and rcar-vin should not judge which links between the adv748x > subdevices are OK to enable/disable. Currently the links between the > adv748x subdevices are immutably enabled to avoid this particular > problem. Uh, I didn't get this :/ Care to elaborate more? What I was about to do, instead, given the fixed HDMI->TXA and AFE->TXB routing in the adv748x driver was to insert a .link_validate() callback for both the HDMI and AFE backends, that checks for the availability of the corresponding output endpoint. This seems to me that this makes easy when dynamic routing will be added to do the same on the dynamically configured sink pad. What do you think? Thanks j > > > > > > PS: the list of upported patches will be sent separately. > > > > > > Jacopo Mondi (5): > > > media: dt-bindings: media: rcar-vin: Add R8A77990 support > > > media: rcar-vin: Add support for R-Car R8A77990 > > > dt-bindings: media: rcar-csi2: Add R8A77990 > > > media: rcar-csi2: Add R8A77990 support > > > arm64: dts: renesas: ebisu: Add HDMI and CVBS input > > > > > > Koji Matsuoka (1): > > > arm64: dts: r8a77990: Add VIN and CSI-2 device nodes > > > > > > Takeshi Kihara (2): > > > pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions > > > arm64: dts: r8a77990: Add I2C device nodes > > > > > > .../devicetree/bindings/media/rcar_vin.txt | 1 + > > > .../bindings/media/renesas,rcar-csi2.txt | 1 + > > > arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 86 > > > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 202 + > > > drivers/media/platform/rcar-vin/rcar-core.c| 20 + > > > drivers/media/platform/rcar-vin/rcar-csi2.c| 9 + > > > drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 504 > > > ++ > > > 7 files changed, 823 insertions(+) > > > > -- > > Regards, > > > > Laurent Pinchart > > > > > > > > -- > Regards, > Niklas Söderlund signature.asc Description: PGP signature
Re: [PATCH v2 4/4] vin-tests: yavta-hdmi: Add VIN4 and parallel link
Hi Niklas, On Fri, Aug 24, 2018 at 06:27:02PM +0200, Niklas Söderlund wrote: > Hi Jacopo, > > Thanks for your patch. > > On 2018-08-24 12:24:22 +0200, Jacopo Mondi wrote: > > Add support for VIN4 to yavta-hdmi and check if format propagation should > > go through 'mc_propagate_parallel()' if the HDMI receiver chip is an > > ADV7612 one. > > > > Signed-off-by: Jacopo Mondi > > --- > > yavta-hdmi | 13 +++-- > > 1 file changed, 11 insertions(+), 2 deletions(-) > > > > diff --git a/yavta-hdmi b/yavta-hdmi > > index fdec546..2e3b625 100755 > > --- a/yavta-hdmi > > +++ b/yavta-hdmi > > @@ -33,14 +33,23 @@ case $vc in > > dev=/dev/$vin3 > > csipad=4 > > ;; > > +4) > > +vinname=$vinname4 > > +dev=/dev/$vin4 > > I think you should also add a csipad declaration here as if the script > is used on a board which is not D3 VIN4 would be connected to a CSI-2 > bus. Writing that I realise a new var 'csidev' or something would be > needed here to expand this to cover the full range of VIN0-VIN7. > > > +;; > > *) > > echo "Unkown VC '$vc'" > > exit 1 > > esac > > > > mc_reset > > -mc_set_link "$csi40name" $csipad "$vinname" 1 > > -mc_propagate_format "$hdminame" 1 "$txaname" 0 "$csi40name" $csipad > > "$vinname" > > +if [[ "$hdminame" == "adv7612 0-004c" ]]; then > > > You should use $parallelname here not $hdminame. Furthermore I thin you > should check if the variable is empty or not and not target it for a > specific board. > > A good (or only) example of how I think this should be done can be found > in test-qv4l2.sh. > > if [[ "$csi20name" != "" ]]; then > mc_set_link "$csi20name" 1 "$vinname1" 1 > mc_propagate_cvbs "$vinname1" > qv4l2 -d /dev/$vin1 > fi > > if [[ "$parallelname" != "" ]]; then > mc_reset > mc_set_link "$parallelname" 1 "$vinname0" 1 > mc_propagate_parallel "$vinname0" > qv4l2 -d /dev/$vin0 > fi > This will solve the naming thing in boards.sh I'll try that and have a look at test-qv4l2.sh too! Thanks j > > + mc_set_link "$hdminame" 1 "$vinname" 1 > > + mc_propagate_parallel "$vinname" > > +else > > + mc_set_link "$csi40name" $csipad "$vinname" 1 > > + mc_propagate_format "$hdminame" 1 "$txaname" 0 "$csi40name" $csipad > > "$vinname" > > +fi > > > > out=/tmp/vin-tests > > rm -fr $out > > -- > > 2.7.4 > > > > -- > Regards, > Niklas Söderlund signature.asc Description: PGP signature
Re: [PATCH v2 1/4] vin-tests: Add support for D3 Draak
Hi Niklas, On Fri, Aug 24, 2018 at 06:12:29PM +0200, Niklas Söderlund wrote: > Hi Jacopo, > > Thanks for your work. > > On 2018-08-24 12:24:19 +0200, Jacopo Mondi wrote: > > Add support for D3 Draak board. > > > > Draak has its HDMI input connected to an ADV7612 which connects to VIN4 > > parallel data inputs. > > > > Signed-off-by: Jacopo Mondi > > --- > > scripts/boards.sh | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/scripts/boards.sh b/scripts/boards.sh > > index 26fdab9..7eb3a27 100644 > > --- a/scripts/boards.sh > > +++ b/scripts/boards.sh > > @@ -29,6 +29,13 @@ case $info in > > # for V3M, but results in an image. > > parallelformat="YUYV8_1X16" > > ;; > > +"Renesas Draak board based on r8a77995") > > +gen="gen3" > > +vins="4" > > +parallelname="adv7612 0-004c" > > +# FIXME: This is a hackfor D3, but results in an image. > > +parallelformat="YUYV8_1X16" > > +;; > > "Koelsch") > > gen="gen2" > > > > @@ -70,6 +77,8 @@ if [[ "$gen" == "gen3" ]]; then > > > > txaname="adv748x 0-0070 txa" > > txbname="adv748x 0-0070 txb" > > +elif [[ "$info" == "Renesas Draak board based on r8a77995" ]]; then > > +hdminame="adv7612 0-004c" > > I don't have the D3 schematics at hand but this feels wrong. Why do you > define the adv7612 as both a parallel and CSI-2 source? IIRC the D3 have > no CSI-2 IP? > Why is "hdminame" variable the CSI-2 source? It might as well be the VIN source, as for D3. To me, and I have added it here because it is used in yavta-hdmi in this way, is the HDMI input component. Want to change the name? > The reason this exists for V3M is that it has both parallel input in the > form of a adv7612 and a CSI-2 input in the for of a adv7482 connected to > the CSI40 IP. > > > else > > cvbsname="adv748x 4-0070 afe" > > hdminame="adv748x 4-0070 hdmi" > > -- > > 2.7.4 > > > > -- > Regards, > Niklas Söderlund signature.asc Description: PGP signature
Re: [PATCH v2 3/4] vin-tests: Add capture format for parallel input
Hi Niklas,
On Fri, Aug 24, 2018 at 06:18:13PM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> On 2018-08-24 12:24:21 +0200, Jacopo Mondi wrote:
> > Add configurable capture format to propagate_parallel() function.
> > The capture format is the image format set on the VIN nodes.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > scripts/boards.sh| 2 ++
> > scripts/vin-tests.sh | 2 +-
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/boards.sh b/scripts/boards.sh
> > index 7eb3a27..b379af6 100644
> > --- a/scripts/boards.sh
> > +++ b/scripts/boards.sh
> > @@ -28,6 +28,7 @@ case $info in
> > # FIXME: This is a hack and not the correct mbus format
> > # for V3M, but results in an image.
> > parallelformat="YUYV8_1X16"
> > + parallel_captureformat="RGB565"
>
> I'm sorry I don't see the value of this change, am I missing something?
> There is no functional change but I assume you use this for something
> but until I figure out what I will leave this change hanging.
> > ;;
> > "Renesas Draak board based on r8a77995")
> > gen="gen3"
> > @@ -35,6 +36,7 @@ case $info in
> > parallelname="adv7612 0-004c"
> > # FIXME: This is a hackfor D3, but results in an image.
> > parallelformat="YUYV8_1X16"
> > + parallel_captureformat="RGB565"
Oops, this was supposed to be a different format, that's why I have
added this new variable.
I'll fix it in next iteration.
> > ;;
> > "Koelsch")
> > gen="gen2"
> > diff --git a/scripts/vin-tests.sh b/scripts/vin-tests.sh
> > index 0c5b29a..e7b7a48 100644
> > --- a/scripts/vin-tests.sh
> > +++ b/scripts/vin-tests.sh
> > @@ -111,5 +111,5 @@ mc_propagate_parallel() {
> > echo "format: $format size: $size/$vinsize field: $field/$vinfield
> > vdev: $vdev"
> >
> > $mediactl -d $mdev -V "$cam [fmt:$format/$size field:$field]"
> > -yavta -f RGB565 -s $vinsize --field $vinfield $vdev
> > +yavta -f $parallel_captureformat -s $vinsize --field $vinfield $vdev
> > }
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas Söderlund
signature.asc
Description: PGP signature
Testing HDMI on E3
Hi Laurent +Niklas in CC for support +renesas-socs to document the procedure In order to test HDMI capture on D3 and Salvator-x boards, I have always used Niklas' great vin-tests suite git://git.ragnatech.se/vin-tests And I suggest to do the same for E3. * Add E3 support to vin-tests/boards.sh E3 has a video input pipeline similar to Salvator-X, and HDMI input connected to an adv7482, connected to a CSI-2 port, then to VIN. I cannot tell the exact entity names, but it is easy enough for you to find them out. I think you only need to tweak vin-tests/boards.sh to add Ebisu board there (look at my series doing that for D3, for E3 it's even simpler). Once the board is recognized, you can use other scripts. * Set EDID on the HDMI port #vin-tests/set-edid You need to cross-compile vin-tests/src/edid/ in advance If this succeeds, the board is recognized. * Capture with yavta Run #vin-tests/yavta-hdmi $VIN_INSTANCE The script configure links and set formats on all entities along the pipeline. At this point, I think the better thing to do is to try, see where it fails and adjust the entity names as required. Again, being this a 'standard' Gen3 capture pipeline, it should be easy enough. - Before all that, I hope my Ebisu support series creates a proper media graph with all entities in place. No need to tell you, but check with media-ctl if everything looks correct for the E3 board. Hope this helps. j signature.asc Description: PGP signature
[PATCH v2 2/4] vin-tests: Fix vdev name in propagate_parallel
The $vdev variable was not defined in propagate_parallel() function.
Signed-off-by: Jacopo Mondi
---
scripts/vin-tests.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/vin-tests.sh b/scripts/vin-tests.sh
index ebb1477..0c5b29a 100644
--- a/scripts/vin-tests.sh
+++ b/scripts/vin-tests.sh
@@ -83,6 +83,7 @@ mc_propagate_cvbs() {
}
mc_propagate_parallel() {
+vin="$1"
mdev=$(mc_get_mdev)
cam="'$parallelname':1"
--
2.7.4
[PATCH v2 3/4] vin-tests: Add capture format for parallel input
Add configurable capture format to propagate_parallel() function.
The capture format is the image format set on the VIN nodes.
Signed-off-by: Jacopo Mondi
---
scripts/boards.sh| 2 ++
scripts/vin-tests.sh | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/boards.sh b/scripts/boards.sh
index 7eb3a27..b379af6 100644
--- a/scripts/boards.sh
+++ b/scripts/boards.sh
@@ -28,6 +28,7 @@ case $info in
# FIXME: This is a hack and not the correct mbus format
# for V3M, but results in an image.
parallelformat="YUYV8_1X16"
+ parallel_captureformat="RGB565"
;;
"Renesas Draak board based on r8a77995")
gen="gen3"
@@ -35,6 +36,7 @@ case $info in
parallelname="adv7612 0-004c"
# FIXME: This is a hackfor D3, but results in an image.
parallelformat="YUYV8_1X16"
+ parallel_captureformat="RGB565"
;;
"Koelsch")
gen="gen2"
diff --git a/scripts/vin-tests.sh b/scripts/vin-tests.sh
index 0c5b29a..e7b7a48 100644
--- a/scripts/vin-tests.sh
+++ b/scripts/vin-tests.sh
@@ -111,5 +111,5 @@ mc_propagate_parallel() {
echo "format: $format size: $size/$vinsize field: $field/$vinfield vdev:
$vdev"
$mediactl -d $mdev -V "$cam [fmt:$format/$size field:$field]"
-yavta -f RGB565 -s $vinsize --field $vinfield $vdev
+yavta -f $parallel_captureformat -s $vinsize --field $vinfield $vdev
}
--
2.7.4
[PATCH v2 4/4] vin-tests: yavta-hdmi: Add VIN4 and parallel link
Add support for VIN4 to yavta-hdmi and check if format propagation should go through 'mc_propagate_parallel()' if the HDMI receiver chip is an ADV7612 one. Signed-off-by: Jacopo Mondi --- yavta-hdmi | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/yavta-hdmi b/yavta-hdmi index fdec546..2e3b625 100755 --- a/yavta-hdmi +++ b/yavta-hdmi @@ -33,14 +33,23 @@ case $vc in dev=/dev/$vin3 csipad=4 ;; +4) +vinname=$vinname4 +dev=/dev/$vin4 +;; *) echo "Unkown VC '$vc'" exit 1 esac mc_reset -mc_set_link "$csi40name" $csipad "$vinname" 1 -mc_propagate_format "$hdminame" 1 "$txaname" 0 "$csi40name" $csipad "$vinname" +if [[ "$hdminame" == "adv7612 0-004c" ]]; then + mc_set_link "$hdminame" 1 "$vinname" 1 + mc_propagate_parallel "$vinname" +else + mc_set_link "$csi40name" $csipad "$vinname" 1 + mc_propagate_format "$hdminame" 1 "$txaname" 0 "$csi40name" $csipad "$vinname" +fi out=/tmp/vin-tests rm -fr $out -- 2.7.4
[PATCH v2 1/4] vin-tests: Add support for D3 Draak
Add support for D3 Draak board. Draak has its HDMI input connected to an ADV7612 which connects to VIN4 parallel data inputs. Signed-off-by: Jacopo Mondi --- scripts/boards.sh | 9 + 1 file changed, 9 insertions(+) diff --git a/scripts/boards.sh b/scripts/boards.sh index 26fdab9..7eb3a27 100644 --- a/scripts/boards.sh +++ b/scripts/boards.sh @@ -29,6 +29,13 @@ case $info in # for V3M, but results in an image. parallelformat="YUYV8_1X16" ;; +"Renesas Draak board based on r8a77995") +gen="gen3" +vins="4" +parallelname="adv7612 0-004c" +# FIXME: This is a hackfor D3, but results in an image. +parallelformat="YUYV8_1X16" +;; "Koelsch") gen="gen2" @@ -70,6 +77,8 @@ if [[ "$gen" == "gen3" ]]; then txaname="adv748x 0-0070 txa" txbname="adv748x 0-0070 txb" +elif [[ "$info" == "Renesas Draak board based on r8a77995" ]]; then +hdminame="adv7612 0-004c" else cvbsname="adv748x 4-0070 afe" hdminame="adv748x 4-0070 hdmi" -- 2.7.4
[PATCH v2 0/4] vin-tests: Add D3 Draak support
Hi Niklas, with these patches I can use yavta-hdmi script on Draak D3 board. Compared to v1 I have rebased on top of your latest changes, with the V3M integration that greatly simplified my life. There are a few hack though [3/4] in particular, so I let you judge if you want to include these changes or not. For the record, the capture procedure on D3 is: [root@alarm vin-tests]# ./set-edid EDID set successfully. [root@alarm vin-tests]# ./yavta-hdmi 4 WARING: overriding parallel format to: RGB888_1X24 format: RGB888_1X24 size: 640x480/640x480 field: none/none vdev: /dev/video3 Device /dev/video3 opened. Device `R_Car_VIN' on `platform:e6ef4000.video' (driver 'rcar_vin') supports video, capture, without mplanes. Video format set: XBGR32 (34325258) 640x480 (stride 2560) field none buffer size 1228800 Video format: XBGR32 (34325258) 640x480 (stride 2560) field none buffer size 1228800 Device /dev/video3 opened. Device `R_Car_VIN' on `platform:e6ef4000.video' (driver 'rcar_vin') supports video, capture, without mplanes. Video format: XBGR32 (34325258) 640x480 (stride 2560) field none buffer size 1228800 4 buffers requested. length: 1228800 offset: 0 timestamp type/source: mono/EoF Buffer 0/0 mapped at address 0xa3034000. length: 1228800 offset: 1228800 timestamp type/source: mono/EoF Buffer 1/0 mapped at address 0xa2f08000. length: 1228800 offset: 2457600 timestamp type/source: mono/EoF Buffer 2/0 mapped at address 0xa2ddc000. length: 1228800 offset: 3686400 timestamp type/source: mono/EoF Buffer 3/0 mapped at address 0xa2cb. 0 (1) [-] none 0 1228800 B 6196.484974 6196.485053 22.681 fps ts mono/EoF 1 (2) [-] none 1 1228800 B 6196.501657 6196.508303 59.941 fps ts mono/EoF 2 (0) [-] none 2 1228800 B 6196.518341 6196.531824 59.938 fps ts mono/EoF 3 (3) [-] none 3 1228800 B 6196.535027 6196.555485 59.930 fps ts mono/EoF 4 (1) [-] none 5 1228800 B 6196.568386 6196.579076 29.977 fps ts mono/EoF 5 (2) [-] none 6 1228800 B 6196.585073 6196.602437 59.927 fps ts mono/EoF 6 (0) [-] none 8 1228800 B 6196.618447 6196.625953 29.963 fps ts mono/EoF 7 (3) [-] none 9 1228800 B 6196.635130 6196.649540 59.941 fps ts mono/EoF 8 (1) [-] none 11 1228800 B 6196.668488 6196.673171 29.978 fps ts mono/EoF 9 (2) [-] none 12 1228800 B 6196.685175 6196.696770 59.927 fps ts mono/EoF Captured 10 frames in 0.255885 seconds (39.080054 fps, 48021569.750941 B/s). And I have converted images with: $for i in `ls frame-*.bin`; do raw2rgbpnm -f BGR32 -s640x480 $i /tmp/$i.pnm; done I am not sure about the formats I have used, but they give me the best results, even if the images are flickered and not completely centered :/ Thanks j Jacopo Mondi (4): vin-tests: Add support for D3 Draak vin-tests: Fix vdev name in propagate_parallel vin-tests: Add capture format for parallel input vin-tests: yavta-hdmi: Add VIN4 and parallel link scripts/boards.sh| 11 +++ scripts/vin-tests.sh | 3 ++- yavta-hdmi | 13 +++-- 3 files changed, 24 insertions(+), 3 deletions(-) -- 2.7.4
[RFT 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
From: Takeshi Kihara
This patch adds VIN{4,5} pins, groups and functions to the R8A77990 SoC.
Signed-off-by: Takeshi Kihara
Signed-off-by: Jacopo Mondi
---
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 504 ++
1 file changed, 504 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
index 5ea63e5..46c0b06 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a77990.c
@@ -1982,6 +1982,446 @@ static const unsigned int usb30_id_mux[] = {
USB3HS0_ID_MARK,
};
+/* - VIN4 ---
*/
+static const unsigned int vin4_data8_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+};
+
+static const unsigned int vin4_data8_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+};
+
+static const unsigned int vin4_data10_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+};
+
+static const unsigned int vin4_data10_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+};
+
+static const unsigned int vin4_data12_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+};
+
+static const unsigned int vin4_data12_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+};
+
+static const unsigned int vin4_data16_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+};
+
+static const unsigned int vin4_data16_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+};
+
+static const unsigned int vin4_data20_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+};
+
+static const unsigned int vin4_data20_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK, VI4_DATA3_A_MARK,
+ VI4_DATA4_A_MARK, VI4_DATA5_A_MARK,
+ VI4_DATA6_A_MARK, VI4_DATA7_A_MARK,
+ VI4_DATA8_MARK, VI4_DATA9_MARK,
+ VI4_DATA10_MARK, VI4_DATA11_MARK,
+ VI4_DATA12_MARK, VI4_DATA13_MARK,
+ VI4_DATA14_MARK, VI4_DATA15_MARK,
+ VI4_DATA16_MARK, VI4_DATA17_MARK,
+ VI4_DATA18_MARK, VI4_DATA19_MARK,
+};
+
+static const unsigned int vin4_data24_a_pins[] = {
+ RCAR_GP_PIN(2, 6), RCAR_GP_PIN(2, 7),
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 9),
+ RCAR_GP_PIN(2, 10), RCAR_GP_PIN(2, 11),
+ RCAR_GP_PIN(2, 12), RCAR_GP_PIN(2, 13),
+ RCAR_GP_PIN(1, 4), RCAR_GP_PIN(1, 5),
+ RCAR_GP_PIN(1, 6), RCAR_GP_PIN(1, 7),
+ RCAR_GP_PIN(1, 3), RCAR_GP_PIN(1, 10),
+ RCAR_GP_PIN(1, 13), RCAR_GP_PIN(1, 14),
+ RCAR_GP_PIN(1, 9), RCAR_GP_PIN(1, 12),
+ RCAR_GP_PIN(1, 15), RCAR_GP_PIN(1, 16),
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+ RCAR_GP_PIN(1, 19), RCAR_GP_PIN(0, 1),
+};
+
+static const unsigned int vin4_data24_a_mux[] = {
+ VI4_DATA0_A_MARK, VI4_DATA1_A_MARK,
+ VI4_DATA2_A_MARK
[RFT 0/8] arm64: dts: renesas: Ebisu: Add HDMI and CVBS input
Hello renesas list, this series add supports for the HDMI and CVBS input to R-Car E3 R8A77990 Ebisu board. It's an RFT, as I don't have an Ebisu to test with :( The series adds supports for the following items: - PFC: add VIN groups and functions - R-Car VIN and R-Car CSI-2: add support for R8A77990 - R8A77990: Add I2C, VIN and CSI-2 nodes - Ebisu: describe HDMI and CVBS inputs Each patch, when relevant reports difference between the upported BSP patch and the proposed one. I know Laurent should receive an Ebisu sooner or later, maybe we can sync for testing :) Thanks j PS: the list of upported patches will be sent separately. Jacopo Mondi (5): media: dt-bindings: media: rcar-vin: Add R8A77990 support media: rcar-vin: Add support for R-Car R8A77990 dt-bindings: media: rcar-csi2: Add R8A77990 media: rcar-csi2: Add R8A77990 support arm64: dts: renesas: ebisu: Add HDMI and CVBS input Koji Matsuoka (1): arm64: dts: r8a77990: Add VIN and CSI-2 device nodes Takeshi Kihara (2): pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions arm64: dts: r8a77990: Add I2C device nodes .../devicetree/bindings/media/rcar_vin.txt | 1 + .../bindings/media/renesas,rcar-csi2.txt | 1 + arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 86 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 202 + drivers/media/platform/rcar-vin/rcar-core.c| 20 + drivers/media/platform/rcar-vin/rcar-csi2.c| 9 + drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 504 + 7 files changed, 823 insertions(+) -- 2.7.4
[RFT 1/8] media: dt-bindings: media: rcar-vin: Add R8A77990 support
Add compatible string for R-Car E3 R8A77990 to the list of SoCs supported by rcar-vin driver. Signed-off-by: Jacopo Mondi --- Documentation/devicetree/bindings/media/rcar_vin.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt index 2f42005..dfd6058 100644 --- a/Documentation/devicetree/bindings/media/rcar_vin.txt +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt @@ -23,6 +23,7 @@ on Gen3 platforms to a CSI-2 receiver. - "renesas,vin-r8a7796" for the R8A7796 device - "renesas,vin-r8a77965" for the R8A77965 device - "renesas,vin-r8a77970" for the R8A77970 device + - "renesas,vin-r8a77990" for the R8A77990 device - "renesas,vin-r8a77995" for the R8A77995 device - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible device. -- 2.7.4
[RFT 2/8] media: rcar-vin: Add support for R-Car R8A77990
Add R-Car E3 R8A77990 SoC to the rcar-vin supported ones.
Based on the experimental patch from Magnus Damm.
Signed-off-by: Jacopo Mondi
---
drivers/media/platform/rcar-vin/rcar-core.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 8843367..907985d 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1089,6 +1089,22 @@ static const struct rvin_info rcar_info_r8a77970 = {
.routes = rcar_info_r8a77970_routes,
};
+static const struct rvin_group_route rcar_info_r8a77990_routes[] = {
+ { .csi = RVIN_CSI40, .channel = 0, .vin = 4, .mask = BIT(0) | BIT(3) },
+ { .csi = RVIN_CSI40, .channel = 0, .vin = 5, .mask = BIT(2) },
+ { .csi = RVIN_CSI40, .channel = 1, .vin = 4, .mask = BIT(2) },
+ { .csi = RVIN_CSI40, .channel = 1, .vin = 5, .mask = BIT(1) | BIT(3) },
+ { /* Sentinel */ }
+};
+
+static const struct rvin_info rcar_info_r8a77990 = {
+ .model = RCAR_GEN3,
+ .use_mc = true,
+ .max_width = 4096,
+ .max_height = 4096,
+ .routes = rcar_info_r8a77990_routes,
+};
+
static const struct rvin_group_route rcar_info_r8a77995_routes[] = {
{ /* Sentinel */ }
};
@@ -1147,6 +1163,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.data = _info_r8a77970,
},
{
+ .compatible = "renesas,vin-r8a77990",
+ .data = _info_r8a77990,
+ },
+ {
.compatible = "renesas,vin-r8a77995",
.data = _info_r8a77995,
},
--
2.7.4
Re: [PATCH 09/14] dt-bindings: arm: Document Renesas R-Car M3-N-based ULCB board
Hello Engeniu, On Fri, Aug 10, 2018 at 03:48:44PM +0200, Eugeniu Rosca wrote: > Hi again Jacopo, > > On Mon, Aug 06, 2018 at 12:40:02AM +0200, Eugeniu Rosca wrote: > > Hi Jacopo, > > > > Thanks for your comments. Please, find my replies below. > > > > On Sun, Aug 05, 2018 at 10:15:43AM +0200, jacopo mondi wrote: > > > Helle Eugeniu, > > > > > > On Sun, Aug 05, 2018 at 01:11:09AM +0200, Eugeniu Rosca wrote: > > > > In harmony with ATF and U-Boot outputs [1] and [2], the new board is > > > > based on M3-N revision ES1.1 and the amount of memory present on SiP > > > > is 2GiB, contiguously addressed. > > > > > > Not sure why the amount of installed system memory is relevant for > > > this commit.. > > > > To be honest, I don't know precisely what's encoded in the board string > > (particularly the one documented in this commit RTP0RC77965SKBX010SA00). > > > > The only thing unmistakenly present there is the SoC model 77965 (i.e. > > M3-N), but I am quite clueless about the rest. > > > > What I can say for sure is that the end-user experience of a R-Car Gen3 > > reference board clearly depends on below parameters: > > - [A] SoC (model, revision) including SRAM and on-chip peripherals > > - [B] DRAM (amount, linear/2ch/4ch split) > > - [C] Hyperflash (amount) > > - [D] board's PCB (revision) > > - [E] board's off-chip peripherals (model, revision) > > > > I don't know how many of these parameters are embedded in the board > > string, but since you are suggesting that RAM amount is not (IOW > > Renesas will potentially release several RTP0RC77965SKBX010SA00 > > boards with different amounts of memory), I will happily update > > the commit description. > > Since I found two H3-ES2.0 Starter Kit samples with different amount of > RAM (4 vs 8 GiB) each having a unique board id [1], I take this as > evidence that Renesas encodes the amount of RAM in the board id. > Therefore, I will not change the description of this patch in v2, > unless you comment/NAK. Thank you. > Thanks for digging into this, feel free to ignore my comment. > [1] https://patchwork.kernel.org/patch/10555957/#22169325 > > Best regards, > Eugeniu. signature.asc Description: PGP signature
Re: [PATCH 14/14] arm64: dts: renesas: r8a77965: ulcb-kf: Initial device tree
Hi Eugeniu,
On Sun, Aug 05, 2018 at 01:11:14AM +0200, Eugeniu Rosca wrote:
> Signed-off-by: Eugeniu Rosca
> ---
> arch/arm64/boot/dts/renesas/Makefile | 1 +
> arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts | 20
> 2 files changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/Makefile
> b/arch/arm64/boot/dts/renesas/Makefile
> index ad7be9a8ca56..3e2c5be65a14 100644
> --- a/arch/arm64/boot/dts/renesas/Makefile
> +++ b/arch/arm64/boot/dts/renesas/Makefile
> @@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-ulcb-kf.dtb
> dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
> dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb
> r8a77965-salvator-xs.dtb
> dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb.dtb
> +dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb-kf.dtb
> dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
> dtb-$(CONFIG_ARCH_R8A77980) += r8a77980-condor.dtb r8a77980-v3hsk.dtb
> dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts
> b/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts
> new file mode 100644
> index ..5c719fb87d8b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a77965-ulcb-kf.dts
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for the M3-N ULCB Kingfisher board
> + *
> + * Copyright (C) 2018 Renesas Electronics Corp.
> + * Copyright (C) 2018 Cogent Embedded, Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
Drop the license text please :)
Thanks
j
> +
> +#include "r8a77965-ulcb.dts"
> +#include "ulcb-kf.dtsi"
> +
> +/ {
> + model = "Renesas ULCB Kingfisher board based on r8a77965";
> + compatible = "shimafuji,kingfisher", "renesas,ulcb",
> + "renesas,r8a77965";
> +};
> --
> 2.18.0
>
signature.asc
Description: PGP signature
Re: [PATCH 10/14] arm64: dts: renesas: r8a77965: ulcb: Initial device tree
Hi Engeniu,
On Sun, Aug 05, 2018 at 01:11:10AM +0200, Eugeniu Rosca wrote:
> Allow the bare M3-N-based ULCB board to boot.
>
> Signed-off-by: Eugeniu Rosca
> ---
> arch/arm64/boot/dts/renesas/Makefile | 1 +
> arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts | 37
> +
> 2 files changed, 38 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/Makefile
> b/arch/arm64/boot/dts/renesas/Makefile
> index 5debb02fad2c..ad7be9a8ca56 100644
> --- a/arch/arm64/boot/dts/renesas/Makefile
> +++ b/arch/arm64/boot/dts/renesas/Makefile
> @@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb
> r8a7796-ulcb.dtb
> dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-ulcb-kf.dtb
> dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-xs.dtb
> dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-x.dtb
> r8a77965-salvator-xs.dtb
> +dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb.dtb
> dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb r8a77970-v3msk.dtb
> dtb-$(CONFIG_ARCH_R8A77980) += r8a77980-condor.dtb r8a77980-v3hsk.dtb
> dtb-$(CONFIG_ARCH_R8A77990) += r8a77990-ebisu.dtb
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts
> b/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts
> new file mode 100644
> index ..4dde14738fb0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a77965-ulcb.dts
> @@ -0,0 +1,37 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for the M3-N ULCB (R-Car Starter Kit Pro) board
> + *
> + * Copyright (C) 2018 Renesas Electronics Corp.
> + * Copyright (C) 2018 Cogent Embedded, Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
With SPDX identifier you can drop the license text from the patch
> +
> +/dts-v1/;
> +#include "r8a77965.dtsi"
> +#include "ulcb.dtsi"
> +
> +/ {
> + model = "Renesas ULCB board based on r8a77965";
> + compatible = "renesas,ulcb", "renesas,r8a77965";
> +
> + memory@4800 {
> + device_type = "memory";
> + /* first 128MB is reserved for secure area. */
> + reg = <0x0 0x4800 0x0 0x7800>;
> + };
> +};
I failed to find schematics for this board but comparing this with the M3-N
revision of Salvator-X, this seems correct to me.
> +
> + {
> + clocks = < CPG_MOD 724>,
> + < CPG_MOD 723>,
> + < CPG_MOD 721>,
> + < 1>,
> + < 3>,
> + < 2>;
> + clock-names = "du.0", "du.1", "du.3",
> + "dclkin.0", "dclkin.1", "dclkin.3";
> +};
Ditto.
With the license things fixed,
Reviewed-by: Jacopo Mondi
Thanks
j
> --
> 2.18.0
>
signature.asc
Description: PGP signature
Re: [PATCH 09/14] dt-bindings: arm: Document Renesas R-Car M3-N-based ULCB board
Helle Eugeniu, On Sun, Aug 05, 2018 at 01:11:09AM +0200, Eugeniu Rosca wrote: > In harmony with ATF and U-Boot outputs [1] and [2], the new board is > based on M3-N revision ES1.1 and the amount of memory present on SiP > is 2GiB, contiguously addressed. Not sure why the amount of installed system memory is relevant for this commit.. > > [1] BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.21 > BL2: PRR is R-Car M3N Ver.1.1 > > [2] U-Boot 2015.04-00295-* > CPU: Renesas Electronics R8A77965 rev 1.1 > ---8< > DRAM: 1.9 GiB > Bank #0: 0x04800 - 0x0bfff, 1.9 GiB > ---8< > > Signed-off-by: Eugeniu Rosca > --- > 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 f391dba10574..2f3494a0107c 100644 > --- a/Documentation/devicetree/bindings/arm/shmobile.txt > +++ b/Documentation/devicetree/bindings/arm/shmobile.txt > @@ -106,6 +106,8 @@ Boards: > compatible = "renesas,lager", "renesas,r8a7790" >- M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)) > compatible = "renesas,ulcb", "renesas,r8a7796" > + - M3-N ULCB (R-Car Starter Kit Pro, RTP0RC77965SKBX010SA00 (M3-N ES1.1)) Other documented ULCB description entries in this file are H3ULCB and M3ULCB, so for consistency you should add M3NULCB, which isn't that nice. Imo, or you either replace "[H|M]3ULCB" with "[H|M]3 ULCB" in other entries and you keep your "M3-N ULCB" here, which is nicer (you could do that in patch 2). Or maybe could you consider doing what has been done for Salvator-x(s), which do not have the SoC model name in the entry description at all (but please wait for others to comment before doing something like that): - Salvator-X (RTP0RC7795SIPB0010S) compatible = "renesas,salvator-x", "renesas,r8a7795" - Salvator-X (RTP0RC7796SIPB0011S) compatible = "renesas,salvator-x", "renesas,r8a7796" - Salvator-X (RTP0RC7796SIPB0011S (M3-N)) compatible = "renesas,salvator-x", "renesas,r8a77965" - Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S) compatible = "renesas,salvator-xs", "renesas,r8a7795" - Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S) compatible = "renesas,salvator-xs", "renesas,r8a7796" - Salvator-XS (Salvator-X 2nd version, RTP0RC77965SIPB012S) compatible = "renesas,salvator-xs", "renesas,r8a77965" This would then be - ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) compatible = "renesas,ulcb", "renesas,r8a7795 - ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0) compatible = "renesas,ulcb", "renesas,r8a7796" - ULCB (R-Car Starter Kit Pro, RTP0RC77965SKBX010SA00 (M3-N ES1.1)) compatible = "renesas,ulcb", "renesas,r8a77965" Thanks j PS: why the r8a7795-es1 version of Salvator-X is not listed? I assume it has a different part number than the ES2.0 one, as ULCB with es1 does. > +compatible = "renesas,ulcb", "renesas,r8a77965" >- Marzen (R0P7779A00010S) > compatible = "renesas,marzen", "renesas,r8a7779" >- Porter (M2-LCDP) > -- > 2.18.0 > signature.asc Description: PGP signature
[RFC/RTF] drm: rcar-du: lvds: Handle LVDS interface reset
The processor manual prescribes to clear reset of LVDS interface in CPG/MSSR
module before display on, and to assert the same reset line at display off
time, to have the module resuming in a known state.
The module is said to be in "standby state" at initialization time, and this
requires, according to section 37.3.7 of the manual, to de-assert the reset to
have it functional.
Based on the original patch from
Koji Matsuoka
Signed-off-by: Jacopo Mondi
---
This patch upports commit:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/
?id=23b62b82a5a705d28ddac1d973ee98e6f51d54ea
Even without this patch the LVDS interface has been succesfully tested on
V3M/Eagle boards, and this makes me wonder on the real need for reset to
be handled by the driver.
I've been able to 'test' the reset assertion/deassertion on Draak, whose LVDS
interface is not yet being enabled due to missing LVDS PLL support.
If someone with a V3M/Eagle could test this to make sure this doesn't break
anything, we can then discuss on the real need for this patch to be mainlined.
Also, a series of patches to add reset to R8A7795/R8A7796/R8A77965 LVDS device
nodes will be upported if this patch is considered useful.
For the interested ones (Laurent, Geert) reset de-assertion at display on time
takes in average a hundreds of micro seconds.
Thanks
j
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 20e8c34..acf4238 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -53,6 +54,7 @@ struct rcar_lvds {
void __iomem *mmio;
struct clk *clock;
+ struct reset_control *rst;
bool enabled;
struct drm_display_mode display_mode;
@@ -175,6 +177,12 @@ static void rcar_lvds_enable(struct drm_bridge *bridge)
if (ret < 0)
return;
+ ret = reset_control_deassert(lvds->rst);
+ if (ret < 0) {
+ clk_disable_unprepare(lvds->clock);
+ return;
+ }
+
/*
* Hardcode the channels and control signals routing for now.
*
@@ -265,6 +273,7 @@ static void rcar_lvds_disable(struct drm_bridge *bridge)
rcar_lvds_write(lvds, LVDCR0, 0);
rcar_lvds_write(lvds, LVDCR1, 0);
+ reset_control_assert(lvds->rst);
clk_disable_unprepare(lvds->clock);
lvds->enabled = false;
@@ -481,6 +490,12 @@ static int rcar_lvds_probe(struct platform_device *pdev)
return PTR_ERR(lvds->clock);
}
+ lvds->rst = devm_reset_control_get_optional_exclusive(>dev, NULL);
+ if (IS_ERR(lvds->rst)) {
+ dev_err(>dev, "failed to get reset\n");
+ return PTR_ERR(lvds->rst);
+ }
+
drm_bridge_add(>bridge);
return 0;
--
2.7.4
[v2 2/2] media: i2c: Add driver for Aptina MT9V111
From: Jacopo Mondi Add V4L2 sensor driver for Aptina MT9V111 CMOS image sensor. The MT9V111 is a 1/4-Inch CMOS image sensor based on MT9V011 with an integrated Image Flow Processor. Reviewed-by: Kieran Bingham Signed-off-by: Jacopo Mondi --- drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v111.c | 1298 +++ 3 files changed, 1310 insertions(+) create mode 100644 drivers/media/i2c/mt9v111.c diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 8669853..b6fea81 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -861,6 +861,17 @@ config VIDEO_MT9V032 This is a Video4Linux2 sensor-level driver for the Micron MT9V032 752x480 CMOS sensor. +config VIDEO_MT9V111 + tristate "Aptina MT9V111 sensor support" + depends on I2C && VIDEO_V4L2 + depends on MEDIA_CAMERA_SUPPORT + help + This is a Video4Linux2 sensor driver for the Aptina/Micron + MT9V111 sensor. + + To compile this driver as a module, choose M here: the + module will be called mt9v111. + config VIDEO_SR030PC30 tristate "Siliconfile SR030PC30 sensor support" depends on I2C && VIDEO_V4L2 diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 837c428..ba9a1e4 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -86,6 +86,7 @@ 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_MT9V111) += mt9v111.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_RJ54N1) += rj54n1cb0c.o diff --git a/drivers/media/i2c/mt9v111.c b/drivers/media/i2c/mt9v111.c new file mode 100644 index 000..da8f6ab --- /dev/null +++ b/drivers/media/i2c/mt9v111.c @@ -0,0 +1,1298 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * V4L2 sensor driver for Aptina MT9V111 image sensor + * Copyright (C) 2018 Jacopo Mondi + * + * Based on mt9v032 driver + * Copyright (C) 2010, Laurent Pinchart + * Copyright (C) 2008, Guennadi Liakhovetski + * + * Based on mt9v011 driver + * Copyright (c) 2009 Mauro Carvalho Chehab + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +/* + * MT9V111 is a 1/4-Inch CMOS digital image sensor with an integrated + * Image Flow Processing (IFP) engine and a sensor core loosely based on + * MT9V011. + * + * The IFP can produce several output image formats from the sensor core + * output. This driver currently supports only YUYV format permutations. + * + * The driver allows manual frame rate control through s_frame_interval subdev + * operation or V4L2_CID_V/HBLANK controls, but it is known that the + * auto-exposure algorithm might modify the programmed frame rate. While the + * driver initially programs the sensor with auto-exposure and + * auto-white-balancing enabled, it is possible to disable them and more + * precisely control the frame rate. + * + * While it seems possible to instruct the auto-exposure control algorithm to + * respect a programmed frame rate when adjusting the pixel integration time, + * registers controlling this feature are not documented in the public + * available sensor manual used to develop this driver (09005aef80e90084, + * MT9V111_1.fm - Rev. G 1/05 EN). + */ + +#define MT9V111_CHIP_ID_HIGH 0x82 +#define MT9V111_CHIP_ID_LOW0x3a + +#define MT9V111_R01_ADDR_SPACE 0x01 +#define MT9V111_R01_IFP0x01 +#define MT9V111_R01_CORE 0x04 + +#define MT9V111_IFP_R06_OPMODE_CTRL0x06 +#defineMT9V111_IFP_R06_OPMODE_CTRL_AWB_EN BIT(1) +#defineMT9V111_IFP_R06_OPMODE_CTRL_AE_EN BIT(14) +#define MT9V111_IFP_R07_IFP_RESET 0x07 +#defineMT9V111_IFP_R07_IFP_RESET_MASK BIT(0) +#define MT9V111_IFP_R08_OUTFMT_CTRL0x08 +#defineMT9V111_IFP_R08_OUTFMT_CTRL_FLICKER BIT(11) +#defineMT9V111_IFP_R08_OUTFMT_CTRL_PCLKBIT(5) +#define MT9V111_IFP_R3A_OUTFMT_CTRL2 0x3a +#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_CBCR BIT(0) +#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_YCBIT(1) +#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_MASK GENMASK(2, 0) +#define MT9V111_IFP_RA5_HPAN 0xa5 +#define MT9V111_IFP_RA6_HZOOM 0xa6 +#define MT9V111_IFP_RA7_HOUT 0xa7 +#define MT9V111_IFP_RA8_VPAN
[v2 1/2] dt-bindings: media: i2c: Document MT9V111 bindings
From: Jacopo Mondi
Add documentation for Aptina MT9V111 image sensor.
Reviewed-by: Rob Herring
Signed-off-by: Jacopo Mondi
---
.../bindings/media/i2c/aptina,mt9v111.txt | 46 ++
MAINTAINERS| 8
2 files changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
new file mode 100644
index 000..bd896e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
@@ -0,0 +1,46 @@
+* Aptina MT9V111 CMOS sensor
+
+
+The Aptina MT9V111 is a 1/4-Inch VGA-format digital image sensor with a core
+based on Aptina MT9V011 sensor and an integrated Image Flow Processor (IFP).
+
+The sensor has an active pixel array of 640x480 pixels and can output a number
+of image resolution and formats controllable through a simple two-wires
+interface.
+
+Required properties:
+
+
+- compatible: shall be "aptina,mt9v111".
+- clocks: reference to the system clock input provider.
+
+Optional properties:
+
+
+- enable-gpios: output enable signal, pin name "OE#". Active low.
+- standby-gpios: low power state control signal, pin name "STANDBY".
+ Active high.
+- reset-gpios: chip reset signal, pin name "RESET#". Active low.
+
+The device node must contain one 'port' child node with one 'endpoint' child
+sub-node for its digital output video port, in accordance with the video
+interface bindings defined in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+
+ {
+camera@48 {
+compatible = "aptina,mt9v111";
+reg = <0x48>;
+
+clocks = <_clk>;
+
+port {
+mt9v111_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index bbd9b9b..4ab113c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9651,6 +9651,14 @@ F:
Documentation/devicetree/bindings/media/i2c/mt9v032.txt
F: drivers/media/i2c/mt9v032.c
F: include/media/i2c/mt9v032.h
+MT9V111 APTINA CAMERA SENSOR
+M: Jacopo Mondi
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
+F: drivers/media/i2c/mt9v111.c
+
MULTIFUNCTION DEVICES (MFD)
M: Lee Jones
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
--
2.7.4
[v2 0/2] media: i2c: mt9v111 sensor driver
Hello, this is a sensor level driver for Aptina MT9V111. Compared to v1 the biggest difference is that now auto-exposure and auto-white-balancing are exposed through the v4l2-ctrl framework, and can be activated/deactivated by the user. For this reason, while auto-exposure algorithm still controls the frame rate in low light conditions, the driver now enables it by default and let the user disable it to more precisely control the framerate. (Most of the) comments from Sakari and Kieran have been addressed, see changelog for a more precise list. Tested VGA, QVGA QQVGA resolutions at 5, 10, 15 and 30 frame per second. v4l2-compliance fails on some tests, and I've not been able to identify what's wrong with the driver. Copy of the failures reported here below: fail: v4l2-test-subdevs.cpp(69): doioctl(node, VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL, ) != EINVAL fail: v4l2-test-subdevs.cpp(180): ret && ret != ENOTTY fail: v4l2-test-subdevs.cpp(248): ret && ret != ENOTTY test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: FAIL I've found no mention of ENOTTY to be reported by enum_frame_interval in the documentation, but apparently v4l2-compliance checks for that. v1: https://lkml.org/lkml/2018/6/11/467 Thanks j v1 -> v2: - Addressed syntax mistakes pointed out by Kieran - Drop spinlock around address space change - Extend mutex to cover frame rate and format get/set operations - Add controls for auto-exposure and auto-white-balancing - Move MAINTAINERS modifications to bindings patch - Fix resolution in bindings document - Drop dependency on OF - Drop subdev 'open' function in favour of pad operation init_cfg and use a default configuration to initialize the sensor - Turn off power if sensor identification fails Jacopo Mondi (2): dt-bindings: media: i2c: Document MT9V111 bindings media: i2c: Add driver for Aptina MT9V111 .../bindings/media/i2c/aptina,mt9v111.txt | 46 + MAINTAINERS|8 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v111.c| 1299 5 files changed, 1365 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt create mode 100644 drivers/media/i2c/mt9v111.c -- 2.7.4
[PATCH] ARM: dts: gr-peach: Add GR-Peach audiocamerashield support
Add device tree header for GR-Peach's audiocamerashield with MT9V111
image sensor.
Signed-off-by: Jacopo Mondi
---
The GR-Peach audiocamera shield is an expansion board for the GR-Peach that
comes with an MT9V111 camera module.
https://www.core.co.jp/product/m2m/gr-peach/audio-camera.html
https://www.digikey.com/product-detail/en/renesas-electronics-america/YGRPEACHAUDIOCAMERASHIELD/YGRPEACHAUDIOCAMERASHIELD-ND/5800301
The series functionally depends on the already sent support for the MT9V111
sensor, but does not have any compile time dependency on it (a checkpatch
warning on the un-documented "aptina-mt9v111" compatible string apart).
https://lkml.org/lkml/2018/6/11/469
(copied the linux-media list to which I'll send a gentle ping for the
driver later ;)
Thanks
j
---
arch/arm/boot/dts/gr-peach-audiocamerashield.dtsi | 79 +++
1 file changed, 79 insertions(+)
create mode 100644 arch/arm/boot/dts/gr-peach-audiocamerashield.dtsi
diff --git a/arch/arm/boot/dts/gr-peach-audiocamerashield.dtsi
b/arch/arm/boot/dts/gr-peach-audiocamerashield.dtsi
new file mode 100644
index 000..e31a9e3
--- /dev/null
+++ b/arch/arm/boot/dts/gr-peach-audiocamerashield.dtsi
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the GR-Peach audiocamera shield expansion board
+ *
+ * Copyright (C) 2017 Jacopo Mondi
+ */
+
+#include "r7s72100.dtsi"
+#include
+#include
+
+/ {
+ /* On-board camera clock. */
+ camera_clk: camera_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2700>;
+ };
+};
+
+ {
+ i2c1_pins: i2c1 {
+ /* P1_2 as SCL; P1_3 as SDA */
+ pinmux = , ;
+ };
+
+ vio_pins: vio {
+ /* CEU pins: VIO_D[0-10], VIO_VD, VIO_HD, VIO_CLK */
+ pinmux = , /* VIO_VD */
+, /* VIO_HD */
+, /* VIO_D0 */
+, /* VIO_D1 */
+, /* VIO_D2 */
+, /* VIO_D3 */
+, /* VIO_D4 */
+, /* VIO_D5 */
+, /* VIO_D6 */
+, /* VIO_D7 */
+; /* VIO_CLK */
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+ clock-frequency = <10>;
+
+ camera@48 {
+ compatible = "aptina,mt9v111";
+ reg = <0x48>;
+
+ clocks = <_clk>;
+
+ port {
+ mt9v111_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+
+ port {
+ ceu_in: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ bus-width = <8>;
+ pclk-sample = <1>;
+ remote-endpoint = <_out>;
+ };
+ };
+};
--
2.7.4
[PATCH 1/2] dt-bindings: media: i2c: Document MT9V111 bindings
Add documentation for Aptina MT9V111 image sensor.
Signed-off-by: Jacopo Mondi
---
.../bindings/media/i2c/aptina,mt9v111.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
new file mode 100644
index 000..bac4bf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
@@ -0,0 +1,46 @@
+* Aptina MT9V111 CMOS sensor
+
+
+The Aptina MT9V111 is a 1/4-Inch VGA-format digital image sensor with a core
+based on Aptina MT9V011 sensor and an integrated Image Flow Processor (IFP).
+
+The sensor has an active pixel array of 649x489 pixels and can output a number
+of image resolution and formats controllable through a simple two-wires
+interface.
+
+Required properties:
+
+
+- compatible: shall be "aptina,mt9v111".
+- clocks: reference to the system clock input provider.
+
+Optional properties:
+
+
+- enable-gpios: output enable signal, pin name "OE#". Active low.
+- standby-gpios: low power state control signal, pin name "STANDBY".
+ Active high.
+- reset-gpios: chip reset signal, pin name "RESET#". Active low.
+
+The device node must contain one 'port' child node with one 'endpoint' child
+sub-node for its digital output video port, in accordance with the video
+interface bindings defined in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+
+ {
+camera@48 {
+compatible = "aptina,mt9v111";
+reg = <0x48>;
+
+clocks = <_clk>;
+
+port {
+mt9v111_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
--
2.7.4
[PATCH 2/2] media: i2c: Add driver for Aptina MT9V111
Add V4L2 sensor driver for Aptina MT9V111 CMOS image sensor. The MT9V111 is a 1/4-Inch CMOS image sensor based on MT9V011 with an integrated Image Flow Processor. Signed-off-by: Jacopo Mondi --- MAINTAINERS |8 + drivers/media/i2c/Kconfig | 12 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v111.c | 1297 +++ 4 files changed, 1318 insertions(+) create mode 100644 drivers/media/i2c/mt9v111.c diff --git a/MAINTAINERS b/MAINTAINERS index a38e24a..2c2fe60 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9523,6 +9523,14 @@ F: Documentation/devicetree/bindings/media/i2c/mt9v032.txt F: drivers/media/i2c/mt9v032.c F: include/media/i2c/mt9v032.h +MT9V111 APTINA CAMERA SENSOR +M: Jacopo Mondi +L: linux-me...@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt +F: drivers/media/i2c/mt9v111.c + MULTIFUNCTION DEVICES (MFD) M: Lee Jones T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 341452f..0bd867d 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -841,6 +841,18 @@ config VIDEO_MT9V032 This is a Video4Linux2 sensor-level driver for the Micron MT9V032 752x480 CMOS sensor. +config VIDEO_MT9V111 + tristate "Aptina MT9V111 sensor support" + depends on I2C && VIDEO_V4L2 + depends on MEDIA_CAMERA_SUPPORT + depends on OF + help + This is a Video4Linux2 sensor-level driver for the Aptina/Micron + MT9V111 sensor. + + To compile this driver as a module, choose M here: the + module will be called mt9v111. + config VIDEO_SR030PC30 tristate "Siliconfile SR030PC30 sensor support" depends on I2C && VIDEO_V4L2 diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index d679d57..f0e8618 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -84,6 +84,7 @@ 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_MT9V111) += mt9v111.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o diff --git a/drivers/media/i2c/mt9v111.c b/drivers/media/i2c/mt9v111.c new file mode 100644 index 000..36e7424 --- /dev/null +++ b/drivers/media/i2c/mt9v111.c @@ -0,0 +1,1297 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * V4L2 sensor driver for Aptina MT9V111 image sensor + * Copyright (C) 2018 Jacopo Mondi + * + * Based on mt9v032 driver + * Copyright (C) 2010, Laurent Pinchart + * Copyright (C) 2008, Guennadi Liakhovetski + * + * Base on mt9v011 driver + * Copyright (c) 2009 Mauro Carvalho Chehab + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +/* + * MT9V111 is a 1/4-Inch CMOS digital image sensor with an integrated + * Image Flow Processing (IFP) engine and a sensor core loosely based on + * MT9V011. + * + * The IFP can produce several output image formats from the sensor core + * output, this driver currently supports only YUYV format permutations. + * + * As the auto exposure algorithms controls exposure time and modifies the + * frame rate, this driver disables auto exposure control, auto white balancing + * and auto flickering avoidance to allow manual frame rate control through + * s_frame_interval subdev operation or V4L2_CID_V/HBLANK controls. + * + * While it seems possible to instruct the auto-exposure control algorithm to + * respect a programmed frame rate when adjusting the pixel integration time, + * registers controlling this feature are not documented in the public + * available sensor manual used to develop this driver (09005aef80e90084, + * MT9V111_1.fm - Rev. G 1/05 EN). + */ + +#define MT9V111_CHIP_ID_HIGH 0x82 +#define MT9V111_CHIP_ID_LOW0x3a + +#define MT9V111_R01_ADDR_SPACE 0x01 +#define MT9V111_R01_IFP0x01 +#define MT9V111_R01_CORE 0x04 + +#define MT9V111_IFP_R06_OPMODE_CTRL0x06 +#defineMT9V111_IFP_R06_OPMODE_CTRL_AWB_EN BIT(1) +#defineMT9V111_IFP_R06_OPMODE_CTRL_AE_EN BIT(14) +#define MT9V111_IFP_R07_IFP_RESET 0x07 +#defineMT9V111_IFP_R07_IFP_RESET_MASK BIT(0) +#define MT9V111_IFP_R08_OUTFMT_CTRL0x08 +#defineMT9V111_IFP_R08_OUTFMT_CTRL_FLICKER BIT(11) +#defineMT9V111_I
[PATCH 0/2] media: i2c: mt9v111 sensor driver
Hello, this is a sensor level driver for Aptina MT9V111. The driver supports YUYV_2X8 output formats and VGA,QVGA,QQVGA,CIF and QCIF resolution. The driver allows control of frame rate through s_frame_interval or V4L2_CID_H/VBLANK control. In order to allow manual frame control, the chip is initialized with auto-exposure control, auto white balancing and flickering control disabled. Tested VGA, QVGA QQVGA resolutions at 5, 10, 15 and 30 frame per second. Thanks j Jacopo Mondi (2): dt-bindings: media: i2c: Document MT9V111 bindings media: i2c: Add driver for Aptina MT9V111 .../bindings/media/i2c/aptina,mt9v111.txt | 46 + MAINTAINERS|8 + drivers/media/i2c/Kconfig | 12 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v111.c| 1297 5 files changed, 1364 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt create mode 100644 drivers/media/i2c/mt9v111.c -- 2.7.4
[PATCH 3/5] arch: sh: kfr2r09: Use new renesas-ceu camera driver
Use the new renesas-ceu camera driver in kfr2r09 board file instead of
the soc_camera based sh_mobile_ceu_camera driver.
Get rid of soc_camera specific components, and move clk and gpio handling
away from board file, registering the clock source and the enable gpios
for driver consumption.
Memory for the 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.
While at there update license to SPDX header and sort headers alphabetically.
No need to udapte the clock source names, as
commit c2f9b05fd5c1 ("media: arch: sh: ecovec: Use new renesas-ceu camera
driver")
already updated it to the new ceu driver name for all SH7724 boards (possibly
breaking kfr2r09 before this commit).
Compile tested only.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
---
arch/sh/boards/mach-kfr2r09/setup.c | 217 +---
1 file changed, 103 insertions(+), 114 deletions(-)
diff --git a/arch/sh/boards/mach-kfr2r09/setup.c
b/arch/sh/boards/mach-kfr2r09/setup.c
index 6af..e59c577 100644
--- a/arch/sh/boards/mach-kfr2r09/setup.c
+++ b/arch/sh/boards/mach-kfr2r09/setup.c
@@ -1,41 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* KFR2R09 board support code
*
* Copyright (C) 2009 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
+#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
+
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu_dma_membase;
+
+/* set VIO_CKO clock to 25MHz */
+#define CEU_MCLK_FREQ 2500
+#define DRVCRB 0xA405018C
static struct mtd_partition kfr2r09_nor_flash_partitions[] =
{
@@ -230,8 +242,17 @@ static struct platform_device kfr2r09_usb0_gadget_device =
{
.resource = kfr2r09_usb0_gadget_resources,
};
-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= 1,
+ .subdevs = {
+ { /* [0] = rj54n1cb0c */
+ .flags = 0,
+ .bus_width = 8,
+ .bus_shift = 0,
+ .i2c_adapter_id = 1,
+ .i2c_address= 0x50,
+ },
+ },
};
static struct resource kfr2r09_ceu_resources[] = {
@@ -246,109 +267,35 @@ static struct resource kfr2r09_ceu_resources[] = {
.end= evt2irq(0x880),
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* place holder for contiguous memory */
- },
};
static struct platform_device kfr2r09_ceu_device = {
- .name = "sh_mobile_ceu",
+ .name = "renesas-ceu",
.id = 0, /* "ceu0" clock */
.num_resources = ARRAY_SIZE(kfr2r09_ceu_resources),
.resource = kfr2r09_ceu_resources,
.dev= {
- .platform_data = _mobile_ceu_info,
+ .platform_data = _pdata,
},
};
-static struct i2c_board_info kfr2r09_i2c_camera = {
- I2C_BOARD_INFO("rj54n1cb0c", 0x50),
-};
-
-static struct clk *camera_clk;
-
-/* set VIO_CKO clock to 25MHz */
-#define CEU_MCLK_FREQ 2500
-
-#define DRVCRB 0xA405018C
-static int camera_power(struct device *dev, int mode)
-{
- int ret;
-
- if (mode) {
- long rate;
-
- camera_clk = clk_get(NULL, "video_clk");
- if (IS_ERR(camera_clk))
- return PTR_ERR(camera_clk);
-
- rate = clk_round_rate(camera_clk, CEU_MCLK_FREQ);
- ret = clk_set_rate(camera_clk, rate);
- if (ret < 0)
- goto eclkrate;
-
- /* set DRVCRB
-*
-* use 1.8 V for VccQ_VIO
-* use 2.85V for VccQ_SR
-*/
- __raw_writew((__raw_readw(DRVCRB) & ~0x0003) | 0x0001, DRVCRB);
-
- /* reset clear */
- ret = gpio_request(GPIO_PTB4, NULL);
- if (ret < 0)
- goto eptb4;
- ret = gp
[PATCH 0/5] Remove sh_mobile_ceu_camera from arch/sh
Hello, this series removes dependencies on the soc_camera based sh_mobile_ceu_camera driver from 3 board files in arch/sh and from one sensor driver used by one of those boards. Hans, this means there are no more user of the soc_camera framework that I know of in Linux, and I guess we can now plan of to remove that framework. A note on the sensor driver: I haven't been able to find any documentation for the SHARP RJ54N1CB0C sensor and so I inferred as much as possible from the existing code. It seems to me that the sensor needs to power-up/enable gpios (both active high) and I have registered them from the kfr2r09 board file, assuming this was not a platform-specific design, but something the sensor requires. As per the previous drivers ported away from soc_camera, I'm in favour of moving them to staging if they do not match the quality expected from a modern V4L2 sensor driver. Ie. framerate control is missing, and I know this has been a blocker for other drivers in the past. What I've done to three board files closely resembles what I done already for Migo-R and Ecovec, and it listed in the single commit messages. The only tough one is probably ap325rxa, which had an additional sensor registered but controlled from i2c transaction of magic blobs from the board file. I dare to remove that sensor registration completely as it seems to me there is no diver for that at all in mainline. Last, this patch is based on the media tree master branch, with Akinobu Mita's patches on ov772x driver on top, which I strangely see only partially applied to the media master tree [1] Hans, as this is mostly media-related work, but mostly on SH architecture, I would like to ask if these should go through you or SH tree. All of that has only been compile tested. It's pretty hard to find this platforms around and testing would be awesome if somebody happens to have one of these. Thanks j [1] https://patchwork.linuxtv.org/patch/49318/ https://patchwork.linuxtv.org/patch/49317/ https://patchwork.linuxtv.org/patch/49312/ Jacopo Mondi (5): media: i2c: Copy rj54n1cb0c soc_camera sensor driver media: i2c: rj54n1: Remove soc_camera dependencies arch: sh: kfr2r09: Use new renesas-ceu camera driver arch: sh: ms7724se: Use new renesas-ceu camera driver arch: sh: ap325rxa: Use new renesas-ceu camera driver arch/sh/boards/mach-ap325rxa/setup.c | 282 ++- arch/sh/boards/mach-kfr2r09/setup.c| 216 +++-- arch/sh/boards/mach-se/7724/setup.c| 120 ++- arch/sh/kernel/cpu/sh4a/clock-sh7723.c |2 +- drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/rj54n1cb0c.c | 1437 7 files changed, 1710 insertions(+), 359 deletions(-) create mode 100644 drivers/media/i2c/rj54n1cb0c.c -- 2.7.4
[PATCH 1/5] media: i2c: Copy rj54n1cb0c 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 <jacopo+rene...@jmondi.org> --- drivers/media/i2c/rj54n1cb0c.c | 1416 1 file changed, 1416 insertions(+) create mode 100644 drivers/media/i2c/rj54n1cb0c.c diff --git a/drivers/media/i2c/rj54n1cb0c.c b/drivers/media/i2c/rj54n1cb0c.c new file mode 100644 index 000..02398d0 --- /dev/null +++ b/drivers/media/i2c/rj54n1cb0c.c @@ -0,0 +1,1416 @@ +/* + * Driver for RJ54N1CB0C CMOS Image Sensor from Sharp + * + * Copyright (C) 2009, Guennadi Liakhovetski <g.liakhovet...@gmx.de> + * + * 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 + +#define RJ54N1_DEV_CODE0x0400 +#define RJ54N1_DEV_CODE2 0x0401 +#define RJ54N1_OUT_SEL 0x0403 +#define RJ54N1_XY_OUTPUT_SIZE_S_H 0x0404 +#define RJ54N1_X_OUTPUT_SIZE_S_L 0x0405 +#define RJ54N1_Y_OUTPUT_SIZE_S_L 0x0406 +#define RJ54N1_XY_OUTPUT_SIZE_P_H 0x0407 +#define RJ54N1_X_OUTPUT_SIZE_P_L 0x0408 +#define RJ54N1_Y_OUTPUT_SIZE_P_L 0x0409 +#define RJ54N1_LINE_LENGTH_PCK_S_H 0x040a +#define RJ54N1_LINE_LENGTH_PCK_S_L 0x040b +#define RJ54N1_LINE_LENGTH_PCK_P_H 0x040c +#define RJ54N1_LINE_LENGTH_PCK_P_L 0x040d +#define RJ54N1_RESIZE_N0x040e +#define RJ54N1_RESIZE_N_STEP 0x040f +#define RJ54N1_RESIZE_STEP 0x0410 +#define RJ54N1_RESIZE_HOLD_H 0x0411 +#define RJ54N1_RESIZE_HOLD_L 0x0412 +#define RJ54N1_H_OBEN_OFS 0x0413 +#define RJ54N1_V_OBEN_OFS 0x0414 +#define RJ54N1_RESIZE_CONTROL 0x0415 +#define RJ54N1_STILL_CONTROL 0x0417 +#define RJ54N1_INC_USE_SEL_H 0x0425 +#define RJ54N1_INC_USE_SEL_L 0x0426 +#define RJ54N1_MIRROR_STILL_MODE 0x0427 +#define RJ54N1_INIT_START 0x0428 +#define RJ54N1_SCALE_1_2_LEV 0x0429 +#define RJ54N1_SCALE_4_LEV 0x042a +#define RJ54N1_Y_GAIN 0x04d8 +#define RJ54N1_APT_GAIN_UP 0x04fa +#define RJ54N1_RA_SEL_UL 0x0530 +#define RJ54N1_BYTE_SWAP 0x0531 +#define RJ54N1_OUT_SIGPO 0x053b +#define RJ54N1_WB_SEL_WEIGHT_I 0x054e +#define RJ54N1_BIT8_WB 0x0569 +#define RJ54N1_HCAPS_WB0x056a +#define RJ54N1_VCAPS_WB0x056b +#define RJ54N1_HCAPE_WB0x056c +#define RJ54N1_VCAPE_WB0x056d +#define RJ54N1_EXPOSURE_CONTROL0x058c +#define RJ54N1_FRAME_LENGTH_S_H0x0595 +#define RJ54N1_FRAME_LENGTH_S_L0x0596 +#define RJ54N1_FRAME_LENGTH_P_H0x0597 +#define RJ54N1_FRAME_LENGTH_P_L0x0598 +#define RJ54N1_PEAK_H 0x05b7 +#define RJ54N1_PEAK_50 0x05b8 +#define RJ54N1_PEAK_60 0x05b9 +#define RJ54N1_PEAK_DIFF 0x05ba +#define RJ54N1_IOC 0x05ef +#define RJ54N1_TG_BYPASS 0x0700 +#define RJ54N1_PLL_L 0x0701 +#define RJ54N1_PLL_N 0x0702 +#define RJ54N1_PLL_EN 0x0704 +#define RJ54N1_RATIO_TG0x0706 +#define RJ54N1_RATIO_T 0x0707 +#define RJ54N1_RATIO_R 0x0708 +#define RJ54N1_RAMP_TGCLK_EN 0x0709 +#define RJ54N1_OCLK_DSP0x0710 +#define RJ54N1_RATIO_OP0x0711 +#define RJ54N1_RATIO_O 0x0712 +#define RJ54N1_OCLK_SEL_EN 0x0713 +#define RJ54N1_CLK_RST 0x0717 +#define RJ54N1_RESET_STANDBY 0x0718 +#define RJ54N1_FWFLG 0x07fe + +#define E_EXCLK(1 << 7) +#define SOFT_STDBY (1 << 4) +#define SEN_RSTX (1 << 2) +#define TG_RSTX(1 << 1) +#define DSP_RSTX (1 << 0) + +#define RESIZE_HOLD_SEL(1 << 2) +#define RESIZE_GO (1 << 1) + +/* + * When cropping, the camera automatically centers the cropped region, there + * doesn't seem to be a way to specify an explicit location of the rectangle. + */ +#define RJ54N1_COLUMN_SKIP 0 +#define RJ54N1_ROW_SKIP0 +#define RJ54N1_MAX_WIDTH 1600 +#defin
[PATCH 5/5] arch: sh: ap325rxa: Use new renesas-ceu camera driver
Use the new renesas-ceu camera driver in ap325rxa board file instead of
the soc_camera based sh_mobile_ceu_camera driver.
Get rid of soc_camera specific components, and register CEU0 with a single
video sensor (ov7725).
Memory for the 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.
The ap325rxa board file registers another camera (ncm03j) for which I found no
driver in mainline kernel version, and that was configured/probed by sending
i2c messages (of 'magic blobs) from the board file itself. I removed the
sensor registration from this new version as it used soc_camera components
that will be later removed.
While at there update license to SPDX header and sort headers alphabetically.
Compile tested only.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
---
arch/sh/boards/mach-ap325rxa/setup.c | 282 +
arch/sh/kernel/cpu/sh4a/clock-sh7723.c | 2 +-
2 files changed, 80 insertions(+), 204 deletions(-)
diff --git a/arch/sh/boards/mach-ap325rxa/setup.c
b/arch/sh/boards/mach-ap325rxa/setup.c
index de8393c..8f234d04 100644
--- a/arch/sh/boards/mach-ap325rxa/setup.c
+++ b/arch/sh/boards/mach-ap325rxa/setup.c
@@ -1,40 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Renesas - AP-325RXA
* (Compatible with Algo System ., LTD. - AP-320A)
*
* Copyright (C) 2008 Renesas Solutions Corp.
* Author : Yusuke Goda <goda.yu...@renesas.com>
- *
- * 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
+#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 CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu_dma_membase;
/* Dummy supplies, where voltage doesn't matter */
static struct regulator_consumer_supply dummy_supplies[] = {
@@ -253,150 +258,25 @@ static struct platform_device lcdc_device = {
},
};
-static void camera_power(int val)
-{
- gpio_set_value(GPIO_PTZ5, val); /* RST_CAM/RSTB */
- mdelay(10);
-}
-
-#ifdef CONFIG_I2C
-/* support for the old ncm03j camera */
-static unsigned char camera_ncm03j_magic[] =
-{
- 0x87, 0x00, 0x88, 0x08, 0x89, 0x01, 0x8A, 0xE8,
- 0x1D, 0x00, 0x1E, 0x8A, 0x21, 0x00, 0x33, 0x36,
- 0x36, 0x60, 0x37, 0x08, 0x3B, 0x31, 0x44, 0x0F,
- 0x46, 0xF0, 0x4B, 0x28, 0x4C, 0x21, 0x4D, 0x55,
- 0x4E, 0x1B, 0x4F, 0xC7, 0x50, 0xFC, 0x51, 0x12,
- 0x58, 0x02, 0x66, 0xC0, 0x67, 0x46, 0x6B, 0xA0,
- 0x6C, 0x34, 0x7E, 0x25, 0x7F, 0x25, 0x8D, 0x0F,
- 0x92, 0x40, 0x93, 0x04, 0x94, 0x26, 0x95, 0x0A,
- 0x99, 0x03, 0x9A, 0xF0, 0x9B, 0x14, 0x9D, 0x7A,
- 0xC5, 0x02, 0xD6, 0x07, 0x59, 0x00, 0x5A, 0x1A,
- 0x5B, 0x2A, 0x5C, 0x37, 0x5D, 0x42, 0x5E, 0x56,
- 0xC8, 0x00, 0xC9, 0x1A, 0xCA, 0x2A, 0xCB, 0x37,
- 0xCC, 0x42, 0xCD, 0x56, 0xCE, 0x00, 0xCF, 0x1A,
- 0xD0, 0x2A, 0xD1, 0x37, 0xD2, 0x42, 0xD3, 0x56,
- 0x5F, 0x68, 0x60, 0x87, 0x61, 0xA3, 0x62, 0xBC,
- 0x63, 0xD4, 0x64, 0xEA, 0xD6, 0x0F,
-};
-
-static int camera_probe(void)
-{
- struct i2c_adapter *a = i2c_get_adapter(0);
- struct i2c_msg msg;
- int ret;
-
- if (!a)
- return -ENODEV;
-
- camera_power(1);
- msg.addr = 0x6e;
- msg.buf = camera_ncm03j_magic;
- msg.len = 2;
- msg.flags = 0;
- ret = i2c_transfer(a, , 1);
- camera_power(0);
-
- return ret;
-}
-
-static int camera_set_capture(struct soc_camera_platform_info *info,
- int enable)
-{
- struct i2c_adapter *a = i2c_get_adapter(0);
- struct i2c_msg msg;
- int ret = 0;
- int i;
-
- camera_power(0);
- if (!enable)
- return 0; /* no disable for now */
-
- camera_power(1);
- for (i = 0; i < ARRAY_SIZE(camera_ncm03j_magic); i += 2) {
- u_int8_t buf[8];
-
- msg.addr = 0x6e;
- msg.buf = buf;
- msg.len = 2;
- msg.flags = 0;
-
- buf[0] = camera_ncm03j_magic[i];
- buf[1] = camera_ncm03j_magic[i + 1];
-
- ret = (ret < 0) ? ret : i2c_transfer(a, , 1);
- }
-
- return ret;
-}
-
-static int ap325rxa_camera_add(struct soc_camera_device *icd);
-static void ap325rxa_camera_del(struct soc_camera_device *icd);
-
-static struct soc_camera_platform_info camera_inf
[PATCH 4/5] arch: sh: ms7724se: Use new renesas-ceu camera driver
Use the new renesas-ceu camera driver is ms7724se board file instead of
the soc_camera based sh_mobile_ceu_camera driver.
Get rid of soc_camera specific components, and register CEU0 and CEU1 with
no active video subdevices.
Memory for the 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.
While at there update license to SPDX header and sort headers
alphabetically.
No need to udapte the clock source names, as
commit c2f9b05fd5c1 ("media: arch: sh: ecovec: Use new renesas-ceu camera
driver")
already updated it to the new ceu driver name for all SH7724 boards
(possibly breaking ms7724se before this commit).
Compile tested only.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
---
arch/sh/boards/mach-se/7724/setup.c | 120
1 file changed, 79 insertions(+), 41 deletions(-)
diff --git a/arch/sh/boards/mach-se/7724/setup.c
b/arch/sh/boards/mach-se/7724/setup.c
index 2559525..fdbec22a 100644
--- a/arch/sh/boards/mach-se/7724/setup.c
+++ b/arch/sh/boards/mach-se/7724/setup.c
@@ -1,43 +1,49 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* linux/arch/sh/boards/se/7724/setup.c
*
* Copyright (C) 2009 Renesas Solutions Corp.
*
* Kuninori Morimoto <morimoto.kunin...@renesas.com>
- *
- * 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
+#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
+
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu0_dma_membase;
+static phys_addr_t ceu1_dma_membase;
/*
* SWx1234 5678
@@ -216,8 +222,8 @@ static struct platform_device lcdc_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 = 0,
};
static struct resource ceu0_resources[] = {
@@ -231,24 +237,21 @@ 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" clock */
.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 = 0,
};
static struct resource ceu1_resources[] = {
@@ -262,18 +265,15 @@ 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" clock */
.num_resources = ARRAY_SIZE(ceu1_resources),
.resource = ceu1_resources,
.dev= {
- .platform_data = _mobile_ceu1_info,
+ .platform_data = _pdata,
},
};
@@ -574,13 +574,16 @@ static struct platform_device vou_device = {
},
};
+static struct platform_device *ms7724se_ceu_devices[] __initdata = {
+ _device,
+ _device,
+};
+
static struct platform_device *ms7724se_devices[] __initdata = {
_device,
_eth_device,
_device,
_flash_device,
- _device,
- _device,
_device,
_eth_device,
_usb0_host_device,
@@ -797,7 +800,6 @@ static int __init devices_setup(void)
gpio_request(GPIO_FN_VIO0_CLK, NULL);
gpio_request(GPIO_FN_VIO0_FLD, NULL);
gpio_request(GPIO_FN_VIO0_HD, NULL);
- platform_resource_setup_memory(_device, &quo
[PATCH 2/5] media: i2c: rj54n1: Remove soc_camera dependencies
Remove soc_camera framework dependencies from rj54n1 sensor driver.
- Handle clock
- Handle GPIOs (named 'powerup' and 'enable')
- Register the async subdevice
- Remove g/s_mbus_config as they're deprecated.
- Adjust build system
- List the driver as maintained for 'Odd Fixes' as I don't have HW to test.
This commits does not remove the original soc_camera based driver.
Compiled tested only.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
---
MAINTAINERS| 8 +++
drivers/media/i2c/Kconfig | 11 +++
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/rj54n1cb0c.c | 153 +++--
4 files changed, 107 insertions(+), 66 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cbcd5ab..0dd7532 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12680,6 +12680,14 @@ W:
http://www.ibm.com/developerworks/linux/linux390/
S: Supported
F: net/smc/
+SHARP RJ54N1CB0C SENSOR DRIVER
+M: Jacopo Mondi <jac...@jmondi.org>
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Odd fixes
+F: drivers/media/i2c/rj54n1cb0c.c
+F: include/media/i2c/rj54n1cb0c.h
+
SH_VEU V4L2 MEM2MEM DRIVER
L: linux-me...@vger.kernel.org
S: Orphan
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index b95b447..7b5a224 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -846,6 +846,17 @@ config VIDEO_NOON010PC30
source "drivers/media/i2c/m5mols/Kconfig"
+config VIDEO_RJ54N1
+ tristate "Sharp RJ54N1CB0C sensor support"
+ depends on I2C && VIDEO_V4L2
+ depends on MEDIA_CAMERA_SUPPORT
+ help
+ This is a V4L2 sensor-level driver for Sharp RJ54N1CB0C CMOS image
+ sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called rj54n1.
+
config VIDEO_S5K6AA
tristate "Samsung S5K6AAFX sensor support"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index ff6e291..3f9c1f7 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -86,6 +86,7 @@ obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
+obj-$(CONFIG_VIDEO_RJ54N1) += rj54n1cb0c.o
obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
obj-$(CONFIG_VIDEO_S5K6A3) += s5k6a3.o
obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o
diff --git a/drivers/media/i2c/rj54n1cb0c.c b/drivers/media/i2c/rj54n1cb0c.c
index 02398d0..6ad998a 100644
--- a/drivers/media/i2c/rj54n1cb0c.c
+++ b/drivers/media/i2c/rj54n1cb0c.c
@@ -1,25 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Driver for RJ54N1CB0C CMOS Image Sensor from Sharp
*
- * Copyright (C) 2009, Guennadi Liakhovetski <g.liakhovet...@gmx.de>
+ * Copyright (C) 2018, Jacopo Mondi <jac...@jmondi.org>
*
- * 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.
+ * Copyright (C) 2009, Guennadi Liakhovetski <g.liakhovet...@gmx.de>
*/
+#include
#include
+#include
#include
+#include
#include
#include
#include
-#include
#include
-#include
-#include
-#include
+#include
#include
+#include
#define RJ54N1_DEV_CODE0x0400
#define RJ54N1_DEV_CODE2 0x0401
@@ -151,7 +151,9 @@ struct rj54n1_clock_div {
struct rj54n1 {
struct v4l2_subdev subdev;
struct v4l2_ctrl_handler hdl;
- struct v4l2_clk *clk;
+ struct clk *clk;
+ struct gpio_desc *pwup_gpio;
+ struct gpio_desc *enable_gpio;
struct rj54n1_clock_div clk_div;
const struct rj54n1_datafmt *fmt;
struct v4l2_rect rect; /* Sensor window */
@@ -545,8 +547,7 @@ static int rj54n1_set_selection(struct v4l2_subdev *sd,
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct rj54n1 *rj54n1 = to_rj54n1(client);
const struct v4l2_rect *rect = >r;
- int dummy = 0, output_w, output_h,
- input_w = rect->width, input_h = rect->height;
+ int output_w, output_h, input_w = rect->width, input_h = rect->height;
int ret;
if (sel->which != V4L2_SUBDEV_FORMAT_ACTIVE ||
@@ -554,11 +555,8 @@ static int rj54n1_set_selection(struct v4l2_subdev *sd,
return -EINVAL;
/* arbitrary minimum width and height, edges unimportant */
- soc_camera_limit_side(, _w,
-RJ54N1_COLUMN_SKIP, 8, RJ54N1_MAX_WIDTH);
-
- soc_camera_limit_side(, _h,
-RJ54N1_ROW_SKIP, 8, RJ54N1_MAX_HEIGHT);
+ v4l_bound_align_image(_w, 8, RJ54N1_MAX_WIDTH, 0,
+ _h, 8, RJ54N1_
Re: [PATCH v4 5/9] media: rcar-vin: Parse parallel input on Gen3
Hi Niklas,
I might have another question before sending v5.
On Fri, May 25, 2018 at 12:29:44AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> I really like what you did with this patch in v4.
>
> On 2018-05-25 00:02:15 +0200, Jacopo Mondi wrote:
> > The rcar-vin driver so far had a mutually exclusive code path for
> > handling parallel and CSI-2 video input subdevices, with only the CSI-2
> > use case supporting media-controller. As we add support for parallel
> > inputs to Gen3 media-controller compliant code path now parse both port@0
> > and port@1, handling the media-controller use case in the parallel
> > bound/unbind notifier operations.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> >
> > ---
> > v3 -> v4:
> > - Change the mc/parallel initialization order. Initialize mc first, then
> > parallel
> > - As a consequence no need to delay parallel notifiers registration, the
> > media controller is set up already when parallel input got parsed,
> > this greatly simplify the group notifier complete callback.
> > ---
> > drivers/media/platform/rcar-vin/rcar-core.c | 56
> > ++---
> > 1 file changed, 35 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> > b/drivers/media/platform/rcar-vin/rcar-core.c
> > index a799684..29619c2 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > @@ -399,6 +399,11 @@ static int rvin_parallel_subdevice_attach(struct
> > rvin_dev *vin,
> > ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
> > vin->parallel->sink_pad = ret < 0 ? 0 : ret;
> >
> > + if (vin->info->use_mc) {
> > + vin->parallel->subdev = subdev;
> > + return 0;
> > + }
> > +
> > /* Find compatible subdevices mbus format */
> > vin->mbus_code = 0;
> > code.index = 0;
> > @@ -460,10 +465,12 @@ static int rvin_parallel_subdevice_attach(struct
> > rvin_dev *vin,
> > static void rvin_parallel_subdevice_detach(struct rvin_dev *vin)
> > {
> > rvin_v4l2_unregister(vin);
> > - v4l2_ctrl_handler_free(>ctrl_handler);
> > -
> > - vin->vdev.ctrl_handler = NULL;
> > vin->parallel->subdev = NULL;
> > +
> > + if (!vin->info->use_mc) {
> > + v4l2_ctrl_handler_free(>ctrl_handler);
> > + vin->vdev.ctrl_handler = NULL;
> > + }
> > }
> >
> > static int rvin_parallel_notify_complete(struct v4l2_async_notifier
> > *notifier)
> > @@ -552,18 +559,18 @@ static int rvin_parallel_parse_v4l2(struct device
> > *dev,
> > return 0;
> > }
> >
> > -static int rvin_parallel_graph_init(struct rvin_dev *vin)
> > +static int rvin_parallel_init(struct rvin_dev *vin)
> > {
> > int ret;
> >
> > - ret = v4l2_async_notifier_parse_fwnode_endpoints(
> > - vin->dev, >notifier,
> > - sizeof(struct rvin_parallel_entity), rvin_parallel_parse_v4l2);
> > + ret = v4l2_async_notifier_parse_fwnode_endpoints_by_port(
> > + vin->dev, >notifier, sizeof(struct rvin_parallel_entity),
> > + 0, rvin_parallel_parse_v4l2);
> > if (ret)
> > return ret;
> >
> > if (!vin->parallel)
> > - return -ENODEV;
> > + return -ENOTCONN;
>
> I think you still should return -ENODEV here if !vin->info->use_mc to
> preserve Gen2 which runs without media controller behavior. How about:
>
> return vin->info->use_mc ? -ENOTCONN : -ENODEV;
>
> >
> > vin_dbg(vin, "Found parallel subdevice %pOF\n",
> > to_of_node(vin->parallel->asd.match.fwnode));
> > @@ -784,14 +791,8 @@ static int rvin_mc_init(struct rvin_dev *vin)
> > {
> > int ret;
> >
> > - vin->pad.flags = MEDIA_PAD_FL_SINK;
> > - ret = media_entity_pads_init(>vdev.entity, 1, >pad);
> > - if (ret)
> > - return ret;
> > -
> > - ret = rvin_group_get(vin);
> > - if (ret)
> > - return ret;
> > + if (!vin->info->use_mc)
> > + return 0;
> >
> > ret = rvin_mc_parse_of_graph(vin);
> > if (ret)
> > @@ -1074,11 +1075,24 @@ static int rcar_vin_probe(struct platform_device
> > *pdev)
> > return ret;
> >
> > platform_set_drvdata(pd
Re: [PATCH v4 5/9] media: rcar-vin: Parse parallel input on Gen3
Hi Niklas,
On Fri, May 25, 2018 at 12:29:44AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> I really like what you did with this patch in v4.
Thanks for review and suggestions, what's there comes mostly from your
comments and guidance.
>
> On 2018-05-25 00:02:15 +0200, Jacopo Mondi wrote:
> > The rcar-vin driver so far had a mutually exclusive code path for
> > handling parallel and CSI-2 video input subdevices, with only the CSI-2
> > use case supporting media-controller. As we add support for parallel
> > inputs to Gen3 media-controller compliant code path now parse both port@0
> > and port@1, handling the media-controller use case in the parallel
> > bound/unbind notifier operations.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> >
> > ---
> > v3 -> v4:
> > - Change the mc/parallel initialization order. Initialize mc first, then
> > parallel
> > - As a consequence no need to delay parallel notifiers registration, the
> > media controller is set up already when parallel input got parsed,
> > this greatly simplify the group notifier complete callback.
> > ---
> > drivers/media/platform/rcar-vin/rcar-core.c | 56
> > ++---
> > 1 file changed, 35 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> > b/drivers/media/platform/rcar-vin/rcar-core.c
> > index a799684..29619c2 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > @@ -399,6 +399,11 @@ static int rvin_parallel_subdevice_attach(struct
> > rvin_dev *vin,
> > ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
> > vin->parallel->sink_pad = ret < 0 ? 0 : ret;
> >
> > + if (vin->info->use_mc) {
> > + vin->parallel->subdev = subdev;
> > + return 0;
> > + }
> > +
> > /* Find compatible subdevices mbus format */
> > vin->mbus_code = 0;
> > code.index = 0;
> > @@ -460,10 +465,12 @@ static int rvin_parallel_subdevice_attach(struct
> > rvin_dev *vin,
> > static void rvin_parallel_subdevice_detach(struct rvin_dev *vin)
> > {
> > rvin_v4l2_unregister(vin);
> > - v4l2_ctrl_handler_free(>ctrl_handler);
> > -
> > - vin->vdev.ctrl_handler = NULL;
> > vin->parallel->subdev = NULL;
> > +
> > + if (!vin->info->use_mc) {
> > + v4l2_ctrl_handler_free(>ctrl_handler);
> > + vin->vdev.ctrl_handler = NULL;
> > + }
> > }
> >
> > static int rvin_parallel_notify_complete(struct v4l2_async_notifier
> > *notifier)
> > @@ -552,18 +559,18 @@ static int rvin_parallel_parse_v4l2(struct device
> > *dev,
> > return 0;
> > }
> >
> > -static int rvin_parallel_graph_init(struct rvin_dev *vin)
> > +static int rvin_parallel_init(struct rvin_dev *vin)
> > {
> > int ret;
> >
> > - ret = v4l2_async_notifier_parse_fwnode_endpoints(
> > - vin->dev, >notifier,
> > - sizeof(struct rvin_parallel_entity), rvin_parallel_parse_v4l2);
> > + ret = v4l2_async_notifier_parse_fwnode_endpoints_by_port(
> > + vin->dev, >notifier, sizeof(struct rvin_parallel_entity),
> > + 0, rvin_parallel_parse_v4l2);
> > if (ret)
> > return ret;
> >
> > if (!vin->parallel)
> > - return -ENODEV;
> > + return -ENOTCONN;
>
> I think you still should return -ENODEV here if !vin->info->use_mc to
> preserve Gen2 which runs without media controller behavior. How about:
>
> return vin->info->use_mc ? -ENOTCONN : -ENODEV;
Right, I wish I had some gen2 board to test. I wonder if that's not
better handled in probe though... I'll see how it looks like.
>
> >
> > vin_dbg(vin, "Found parallel subdevice %pOF\n",
> > to_of_node(vin->parallel->asd.match.fwnode));
> > @@ -784,14 +791,8 @@ static int rvin_mc_init(struct rvin_dev *vin)
> > {
> > int ret;
> >
> > - vin->pad.flags = MEDIA_PAD_FL_SINK;
> > - ret = media_entity_pads_init(>vdev.entity, 1, >pad);
> > - if (ret)
> > - return ret;
> > -
> > - ret = rvin_group_get(vin);
> > - if (ret)
> > - return ret;
> > + if (!vin->info->use_mc)
> > + return 0;
> >
> > ret = rvin_mc_parse_of_graph(vin);
> > if (
[PATCH v4 3/9] media: rcar-vin: Create a group notifier
As CSI-2 subdevices are shared between several VIN instances, a shared
notifier to collect the CSI-2 async subdevices is required. So far, the
rcar-vin driver used the notifier of the last VIN instance to probe but
with the forth-coming introduction of parallel input subdevices support
in mc-compliant code path, each VIN may register its own notifier if any
parallel subdevice is connected there.
To avoid registering a notifier twice (once for parallel subdev and one
for the CSI-2 subdevs) create a group notifier, shared by all the VIN
instances.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
---
v3 -> v4:
- Unregister and cleanup group notifier when un-registering the VIN
instance whose v4l2_dev the notifier is associated to.
---
drivers/media/platform/rcar-vin/rcar-core.c | 38 ++---
drivers/media/platform/rcar-vin/rcar-vin.h | 5 ++--
2 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index bcf02de..d3aadf3 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -46,6 +46,8 @@
*/
#define rvin_group_id_to_master(vin) ((vin) < 4 ? 0 : 4)
+#define v4l2_dev_to_vin(d) container_of(d, struct rvin_dev, v4l2_dev)
+
/*
-
* Media Controller link notification
*/
@@ -583,7 +585,7 @@ static int rvin_parallel_graph_init(struct rvin_dev *vin)
static int rvin_group_notify_complete(struct v4l2_async_notifier *notifier)
{
- struct rvin_dev *vin = notifier_to_vin(notifier);
+ struct rvin_dev *vin = v4l2_dev_to_vin(notifier->v4l2_dev);
const struct rvin_group_route *route;
unsigned int i;
int ret;
@@ -649,7 +651,7 @@ static void rvin_group_notify_unbind(struct
v4l2_async_notifier *notifier,
struct v4l2_subdev *subdev,
struct v4l2_async_subdev *asd)
{
- struct rvin_dev *vin = notifier_to_vin(notifier);
+ struct rvin_dev *vin = v4l2_dev_to_vin(notifier->v4l2_dev);
unsigned int i;
for (i = 0; i < RCAR_VIN_NUM; i++)
@@ -673,7 +675,7 @@ static int rvin_group_notify_bound(struct
v4l2_async_notifier *notifier,
struct v4l2_subdev *subdev,
struct v4l2_async_subdev *asd)
{
- struct rvin_dev *vin = notifier_to_vin(notifier);
+ struct rvin_dev *vin = v4l2_dev_to_vin(notifier->v4l2_dev);
unsigned int i;
mutex_lock(>group->lock);
@@ -734,12 +736,6 @@ static int rvin_mc_parse_of_graph(struct rvin_dev *vin)
mutex_lock(>group->lock);
- /* If there already is a notifier something has gone wrong, bail out. */
- if (WARN_ON(vin->group->notifier)) {
- mutex_unlock(>group->lock);
- return -EINVAL;
- }
-
/* If not all VIN's are registered don't register the notifier. */
for (i = 0; i < RCAR_VIN_NUM; i++)
if (vin->group->vin[i])
@@ -751,19 +747,16 @@ static int rvin_mc_parse_of_graph(struct rvin_dev *vin)
}
/*
-* Have all VIN's look for subdevices. Some subdevices will overlap
-* but the parser function can handle it, so each subdevice will
-* only be registered once with the notifier.
+* Have all VIN's look for CSI-2 subdevices. Some subdevices will
+* overlap but the parser function can handle it, so each subdevice
+* will only be registered once with the group notifier.
*/
-
- vin->group->notifier = >notifier;
-
for (i = 0; i < RCAR_VIN_NUM; i++) {
if (!vin->group->vin[i])
continue;
ret = v4l2_async_notifier_parse_fwnode_endpoints_by_port(
- vin->group->vin[i]->dev, vin->group->notifier,
+ vin->group->vin[i]->dev, >group->notifier,
sizeof(struct v4l2_async_subdev), 1,
rvin_mc_parse_of_endpoint);
if (ret) {
@@ -774,9 +767,12 @@ static int rvin_mc_parse_of_graph(struct rvin_dev *vin)
mutex_unlock(>group->lock);
- vin->group->notifier->ops = _group_notify_ops;
+ if (!vin->group->notifier.num_subdevs)
+ return 0;
- ret = v4l2_async_notifier_register(>v4l2_dev, >notifier);
+ vin->group->notifier.ops = _group_notify_ops;
+ ret = v4l2_async_notifier_register(>v4l2_dev,
+ >group->notifier);
if (ret < 0) {
vin_err(vin, "Notifier registration failed\n");
return
[PATCH v4 5/9] media: rcar-vin: Parse parallel input on Gen3
The rcar-vin driver so far had a mutually exclusive code path for
handling parallel and CSI-2 video input subdevices, with only the CSI-2
use case supporting media-controller. As we add support for parallel
inputs to Gen3 media-controller compliant code path now parse both port@0
and port@1, handling the media-controller use case in the parallel
bound/unbind notifier operations.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
---
v3 -> v4:
- Change the mc/parallel initialization order. Initialize mc first, then
parallel
- As a consequence no need to delay parallel notifiers registration, the
media controller is set up already when parallel input got parsed,
this greatly simplify the group notifier complete callback.
---
drivers/media/platform/rcar-vin/rcar-core.c | 56 ++---
1 file changed, 35 insertions(+), 21 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index a799684..29619c2 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -399,6 +399,11 @@ static int rvin_parallel_subdevice_attach(struct rvin_dev
*vin,
ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
vin->parallel->sink_pad = ret < 0 ? 0 : ret;
+ if (vin->info->use_mc) {
+ vin->parallel->subdev = subdev;
+ return 0;
+ }
+
/* Find compatible subdevices mbus format */
vin->mbus_code = 0;
code.index = 0;
@@ -460,10 +465,12 @@ static int rvin_parallel_subdevice_attach(struct rvin_dev
*vin,
static void rvin_parallel_subdevice_detach(struct rvin_dev *vin)
{
rvin_v4l2_unregister(vin);
- v4l2_ctrl_handler_free(>ctrl_handler);
-
- vin->vdev.ctrl_handler = NULL;
vin->parallel->subdev = NULL;
+
+ if (!vin->info->use_mc) {
+ v4l2_ctrl_handler_free(>ctrl_handler);
+ vin->vdev.ctrl_handler = NULL;
+ }
}
static int rvin_parallel_notify_complete(struct v4l2_async_notifier *notifier)
@@ -552,18 +559,18 @@ static int rvin_parallel_parse_v4l2(struct device *dev,
return 0;
}
-static int rvin_parallel_graph_init(struct rvin_dev *vin)
+static int rvin_parallel_init(struct rvin_dev *vin)
{
int ret;
- ret = v4l2_async_notifier_parse_fwnode_endpoints(
- vin->dev, >notifier,
- sizeof(struct rvin_parallel_entity), rvin_parallel_parse_v4l2);
+ ret = v4l2_async_notifier_parse_fwnode_endpoints_by_port(
+ vin->dev, >notifier, sizeof(struct rvin_parallel_entity),
+ 0, rvin_parallel_parse_v4l2);
if (ret)
return ret;
if (!vin->parallel)
- return -ENODEV;
+ return -ENOTCONN;
vin_dbg(vin, "Found parallel subdevice %pOF\n",
to_of_node(vin->parallel->asd.match.fwnode));
@@ -784,14 +791,8 @@ static int rvin_mc_init(struct rvin_dev *vin)
{
int ret;
- vin->pad.flags = MEDIA_PAD_FL_SINK;
- ret = media_entity_pads_init(>vdev.entity, 1, >pad);
- if (ret)
- return ret;
-
- ret = rvin_group_get(vin);
- if (ret)
- return ret;
+ if (!vin->info->use_mc)
+ return 0;
ret = rvin_mc_parse_of_graph(vin);
if (ret)
@@ -1074,11 +1075,24 @@ static int rcar_vin_probe(struct platform_device *pdev)
return ret;
platform_set_drvdata(pdev, vin);
- if (vin->info->use_mc)
- ret = rvin_mc_init(vin);
- else
- ret = rvin_parallel_graph_init(vin);
- if (ret < 0)
+
+ if (vin->info->use_mc) {
+ vin->pad.flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_pads_init(>vdev.entity, 1, >pad);
+ if (ret)
+ return ret;
+
+ ret = rvin_group_get(vin);
+ if (ret)
+ return ret;
+ }
+
+ ret = rvin_mc_init(vin);
+ if (ret)
+ return ret;
+
+ ret = rvin_parallel_init(vin);
+ if (ret < 0 && ret != -ENOTCONN)
goto error;
pm_suspend_ignore_children(>dev, true);
--
2.7.4
[PATCH v4 0/9] rcar-vin: Add support for parallel input on Gen3
Hello, this series adds support for parallel video input to the Gen3 version of rcar-vin driver. Compared to v3, this new iteration closes all comments from Niklas and Sergei. As the meat of the patch series hasn't changed much, please refer to v3 cover letter for more details. The most notable change is the great simplification of the parallel input notifiers registration in [5/9], as now the media controller is initialized before parallel inputs are parsed. As the media device is now properly initialized, parallel input notifiers can be registered as soon as new input devices are discovered, without having to wait for the group notifier complete callback to be called. Thanks Niklas for pointing that out. Testing: Tested image capture on both Draak and Salvator-X M3-W with a fake parallel input device added. Test branch for Salvator-X available at git://jmondi.org d3/media-master/salvator-x-dts_csi2/m3w-add_parallel_to_dts+driver-v4 For Draak at: git://jmondi.org d3/media-master/salvator-x-dts_csi2/d3-vin-driver-v4+enable-HDMI-in-dts (sorry for the horrid branch names :) Niklas, I know you have a V3M with expansion that has both CSI-2 and parallel input. Could you give this one a spin please? No changelog reported here, except from the one reported above. Most of the other changes are minors, the most notable ones are reported in each patch commit message. Thanks j Jacopo Mondi (9): media: rcar-vin: Rename 'digital' to 'parallel' media: rcar-vin: Remove two empty lines media: rcar-vin: Create a group notifier media: rcar-vin: Cache the mbus configuration flags media: rcar-vin: Parse parallel input on Gen3 media: rcar-vin: Link parallel input media entities media: rcar-vin: Handle parallel subdev in link_notify media: rcar-vin: Rename _rcar_info to rcar_info media: rcar-vin: Add support for R-Car R8A77995 SoC drivers/media/platform/rcar-vin/rcar-core.c | 258 ++-- drivers/media/platform/rcar-vin/rcar-dma.c | 36 ++-- drivers/media/platform/rcar-vin/rcar-v4l2.c | 12 +- drivers/media/platform/rcar-vin/rcar-vin.h | 29 ++-- 4 files changed, 215 insertions(+), 120 deletions(-) -- 2.7.4
[PATCH v4 7/9] media: rcar-vin: Handle parallel subdev in link_notify
Handle parallel subdevices in link_notify callback. If the notified link
involves a parallel subdevice, do not change routing of the VIN-CSI-2
devices and mark the VIN instance as using a parallel input. If the
CSI-2 link setup succeeds instead, mark the VIN instance as using CSI-2.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
Acked-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
---
drivers/media/platform/rcar-vin/rcar-core.c | 35 -
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index b69b375..8edf896 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -171,9 +171,37 @@ static int rvin_group_link_notify(struct media_link *link,
u32 flags,
/* Add the new link to the existing mask and check if it works. */
csi_id = rvin_group_entity_to_csi_id(group, link->source->entity);
+
+ if (csi_id == -ENODEV) {
+ struct v4l2_subdev *sd;
+ unsigned int i;
+
+ /*
+* Make sure the source entity subdevice is registered as
+* a parallel input of one of the enabled VINs if it is not
+* one of the CSI-2 subdevices.
+*
+* No hardware configuration required for parallel inputs,
+* we can return here.
+*/
+ sd = media_entity_to_v4l2_subdev(link->source->entity);
+ for (i = 0; i < RCAR_VIN_NUM; i++) {
+ if (group->vin[i] && group->vin[i]->parallel &&
+ group->vin[i]->parallel->subdev == sd) {
+ group->vin[i]->is_csi = false;
+ ret = 0;
+ goto out;
+ }
+ }
+
+ vin_err(vin, "Subdevice %s not registered to any VIN\n",
+ link->source->entity->name);
+ ret = -ENODEV;
+ goto out;
+ }
+
channel = rvin_group_csi_pad_to_channel(link->source->index);
mask_new = mask & rvin_group_get_mask(vin, csi_id, channel);
-
vin_dbg(vin, "Try link change mask: 0x%x new: 0x%x\n", mask, mask_new);
if (!mask_new) {
@@ -183,6 +211,11 @@ static int rvin_group_link_notify(struct media_link *link,
u32 flags,
/* New valid CHSEL found, set the new value. */
ret = rvin_set_channel_routing(group->vin[master_id], __ffs(mask_new));
+ if (ret)
+ goto out;
+
+ vin->is_csi = true;
+
out:
mutex_unlock(>lock);
--
2.7.4
[PATCH v4 8/9] media: rcar-vin: Rename _rcar_info to rcar_info
Remove leading underscore to align all rcar_group_route structure
declarations.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
Acked-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
---
drivers/media/platform/rcar-vin/rcar-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 8edf896..30f6ea7 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1019,7 +1019,7 @@ static const struct rvin_info rcar_info_r8a7796 = {
.routes = rcar_info_r8a7796_routes,
};
-static const struct rvin_group_route _rcar_info_r8a77970_routes[] = {
+static const struct rvin_group_route rcar_info_r8a77970_routes[] = {
{ .csi = RVIN_CSI40, .channel = 0, .vin = 0, .mask = BIT(0) | BIT(3) },
{ .csi = RVIN_CSI40, .channel = 0, .vin = 1, .mask = BIT(2) },
{ .csi = RVIN_CSI40, .channel = 1, .vin = 1, .mask = BIT(3) },
@@ -1035,7 +1035,7 @@ static const struct rvin_info rcar_info_r8a77970 = {
.use_mc = true,
.max_width = 4096,
.max_height = 4096,
- .routes = _rcar_info_r8a77970_routes,
+ .routes = rcar_info_r8a77970_routes,
};
static const struct of_device_id rvin_of_id_table[] = {
--
2.7.4
[PATCH v4 6/9] media: rcar-vin: Link parallel input media entities
When running with media-controller link the parallel input
media entities with the VIN entities at 'complete' callback time.
To create media links the v4l2_device should be registered first.
Check if the device is already registered, to avoid double registrations.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
Acked-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
---
drivers/media/platform/rcar-vin/rcar-core.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 29619c2..b69b375 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -476,6 +476,8 @@ static void rvin_parallel_subdevice_detach(struct rvin_dev
*vin)
static int rvin_parallel_notify_complete(struct v4l2_async_notifier *notifier)
{
struct rvin_dev *vin = notifier_to_vin(notifier);
+ struct media_entity *source;
+ struct media_entity *sink;
int ret;
ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
@@ -484,7 +486,26 @@ static int rvin_parallel_notify_complete(struct
v4l2_async_notifier *notifier)
return ret;
}
- return rvin_v4l2_register(vin);
+ if (!video_is_registered(>vdev)) {
+ ret = rvin_v4l2_register(vin);
+ if (ret < 0)
+ return ret;
+ }
+
+ if (!vin->info->use_mc)
+ return 0;
+
+ /* If we're running with media-controller, link the subdevs. */
+ source = >parallel->subdev->entity;
+ sink = >vdev.entity;
+
+ ret = media_create_pad_link(source, vin->parallel->source_pad,
+ sink, vin->parallel->sink_pad, 0);
+ if (ret)
+ vin_err(vin, "Error adding link from %s to %s: %d\n",
+ source->name, sink->name, ret);
+
+ return ret;
}
static void rvin_parallel_notify_unbind(struct v4l2_async_notifier *notifier,
@@ -604,7 +625,8 @@ static int rvin_group_notify_complete(struct
v4l2_async_notifier *notifier)
/* Register all video nodes for the group. */
for (i = 0; i < RCAR_VIN_NUM; i++) {
- if (vin->group->vin[i]) {
+ if (vin->group->vin[i] &&
+ !video_is_registered(>group->vin[i]->vdev)) {
ret = rvin_v4l2_register(vin->group->vin[i]);
if (ret)
return ret;
--
2.7.4
[PATCH v4 9/9] media: rcar-vin: Add support for R-Car R8A77995 SoC
Add R-Car R8A77995 SoC to the rcar-vin supported ones.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
---
drivers/media/platform/rcar-vin/rcar-core.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 30f6ea7..223310f 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1038,6 +1038,18 @@ static const struct rvin_info rcar_info_r8a77970 = {
.routes = rcar_info_r8a77970_routes,
};
+static const struct rvin_group_route rcar_info_r8a77995_routes[] = {
+ { /* Sentinel */ }
+};
+
+static const struct rvin_info rcar_info_r8a77995 = {
+ .model = RCAR_GEN3,
+ .use_mc = true,
+ .max_width = 4096,
+ .max_height = 4096,
+ .routes = rcar_info_r8a77995_routes,
+};
+
static const struct of_device_id rvin_of_id_table[] = {
{
.compatible = "renesas,vin-r8a7778",
@@ -1079,6 +1091,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.compatible = "renesas,vin-r8a77970",
.data = _info_r8a77970,
},
+ {
+ .compatible = "renesas,vin-r8a77995",
+ .data = _info_r8a77995,
+ },
{ /* Sentinel */ },
};
MODULE_DEVICE_TABLE(of, rvin_of_id_table);
--
2.7.4
[PATCH v4 1/9] media: rcar-vin: Rename 'digital' to 'parallel'
As the term 'digital' is used all over the rcar-vin code in place of
'parallel', rename all the occurrencies.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
Acked-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
---
drivers/media/platform/rcar-vin/rcar-core.c | 72 ++---
drivers/media/platform/rcar-vin/rcar-dma.c | 4 +-
drivers/media/platform/rcar-vin/rcar-v4l2.c | 12 ++---
drivers/media/platform/rcar-vin/rcar-vin.h | 6 +--
4 files changed, 47 insertions(+), 47 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index d3072e1..16d3e01 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -376,12 +376,12 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int
direction)
}
/*
-
- * Digital async notifier
+ * Parallel async notifier
*/
/* The vin lock should be held when calling the subdevice attach and detach */
-static int rvin_digital_subdevice_attach(struct rvin_dev *vin,
-struct v4l2_subdev *subdev)
+static int rvin_parallel_subdevice_attach(struct rvin_dev *vin,
+ struct v4l2_subdev *subdev)
{
struct v4l2_subdev_mbus_code_enum code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
@@ -392,15 +392,15 @@ static int rvin_digital_subdevice_attach(struct rvin_dev
*vin,
ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
if (ret < 0)
return ret;
- vin->digital->source_pad = ret;
+ vin->parallel->source_pad = ret;
ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
- vin->digital->sink_pad = ret < 0 ? 0 : ret;
+ vin->parallel->sink_pad = ret < 0 ? 0 : ret;
/* Find compatible subdevices mbus format */
vin->mbus_code = 0;
code.index = 0;
- code.pad = vin->digital->source_pad;
+ code.pad = vin->parallel->source_pad;
while (!vin->mbus_code &&
!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
code.index++;
@@ -450,21 +450,21 @@ static int rvin_digital_subdevice_attach(struct rvin_dev
*vin,
vin->vdev.ctrl_handler = >ctrl_handler;
- vin->digital->subdev = subdev;
+ vin->parallel->subdev = subdev;
return 0;
}
-static void rvin_digital_subdevice_detach(struct rvin_dev *vin)
+static void rvin_parallel_subdevice_detach(struct rvin_dev *vin)
{
rvin_v4l2_unregister(vin);
v4l2_ctrl_handler_free(>ctrl_handler);
vin->vdev.ctrl_handler = NULL;
- vin->digital->subdev = NULL;
+ vin->parallel->subdev = NULL;
}
-static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
+static int rvin_parallel_notify_complete(struct v4l2_async_notifier *notifier)
{
struct rvin_dev *vin = notifier_to_vin(notifier);
int ret;
@@ -478,28 +478,28 @@ static int rvin_digital_notify_complete(struct
v4l2_async_notifier *notifier)
return rvin_v4l2_register(vin);
}
-static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
- struct v4l2_subdev *subdev,
- struct v4l2_async_subdev *asd)
+static void rvin_parallel_notify_unbind(struct v4l2_async_notifier *notifier,
+ struct v4l2_subdev *subdev,
+ struct v4l2_async_subdev *asd)
{
struct rvin_dev *vin = notifier_to_vin(notifier);
- vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
+ vin_dbg(vin, "unbind parallel subdev %s\n", subdev->name);
mutex_lock(>lock);
- rvin_digital_subdevice_detach(vin);
+ rvin_parallel_subdevice_detach(vin);
mutex_unlock(>lock);
}
-static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
-struct v4l2_subdev *subdev,
-struct v4l2_async_subdev *asd)
+static int rvin_parallel_notify_bound(struct v4l2_async_notifier *notifier,
+ struct v4l2_subdev *subdev,
+ struct v4l2_async_subdev *asd)
{
struct rvin_dev *vin = notifier_to_vin(notifier);
int ret;
mutex_lock(>lock);
- ret = rvin_digital_subdevice_attach(vin, subdev);
+ ret = rvin_parallel_subdevice_attach(vin, subdev);
mutex_unlock(>lock);
if (ret)
return ret;
@@ -507,21 +507,21 @@ static int rvin_digital_notify_bound(struct
v4l2_async_notifier *notifier,
v4l2_set_subdev_hostdata(subdev, vin);
v
[PATCH v4 4/9] media: rcar-vin: Cache the mbus configuration flags
Media bus configuration flags and media bus type were so far a property
of each VIN instance, as the subdevice they were connected to was
immutable during the whole system life time.
With the forth-coming introduction of parallel input devices support,
a VIN instance can have the subdevice it is connected to switched at
runtime, from a CSI-2 subdevice to a parallel one and viceversa, through
the modification of links between media entities in the media controller
graph. To avoid discarding the per-subdevice configuration flags retrieved by
v4l2_fwnode parsing facilities, cache them in the 'rvin_graph_entity'
member of each VIN instance, opportunely renamed to 'rvin_parallel_entity'.
Also modify the register configuration function to take mbus flags into
account when running on a bus type that supports them.
The media bus type currently in use will be updated in a follow-up patch
to the link state change notification function.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
---
drivers/media/platform/rcar-vin/rcar-core.c | 21 ---
drivers/media/platform/rcar-vin/rcar-dma.c | 32 +++--
drivers/media/platform/rcar-vin/rcar-vin.h | 22 ++--
3 files changed, 45 insertions(+), 30 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index d3aadf3..a799684 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -526,30 +526,29 @@ static int rvin_parallel_parse_v4l2(struct device *dev,
struct v4l2_async_subdev *asd)
{
struct rvin_dev *vin = dev_get_drvdata(dev);
- struct rvin_graph_entity *rvge =
- container_of(asd, struct rvin_graph_entity, asd);
+ struct rvin_parallel_entity *rvpe =
+ container_of(asd, struct rvin_parallel_entity, asd);
if (vep->base.port || vep->base.id)
return -ENOTCONN;
- vin->mbus_cfg.type = vep->bus_type;
+ vin->parallel = rvpe;
+ vin->parallel->mbus_type = vep->bus_type;
- switch (vin->mbus_cfg.type) {
+ switch (vin->parallel->mbus_type) {
case V4L2_MBUS_PARALLEL:
vin_dbg(vin, "Found PARALLEL media bus\n");
- vin->mbus_cfg.flags = vep->bus.parallel.flags;
+ vin->parallel->mbus_flags = vep->bus.parallel.flags;
break;
case V4L2_MBUS_BT656:
vin_dbg(vin, "Found BT656 media bus\n");
- vin->mbus_cfg.flags = 0;
+ vin->parallel->mbus_flags = 0;
break;
default:
vin_err(vin, "Unknown media bus type\n");
return -EINVAL;
}
- vin->parallel = rvge;
-
return 0;
}
@@ -559,7 +558,7 @@ static int rvin_parallel_graph_init(struct rvin_dev *vin)
ret = v4l2_async_notifier_parse_fwnode_endpoints(
vin->dev, >notifier,
- sizeof(struct rvin_graph_entity), rvin_parallel_parse_v4l2);
+ sizeof(struct rvin_parallel_entity), rvin_parallel_parse_v4l2);
if (ret)
return ret;
@@ -785,10 +784,6 @@ static int rvin_mc_init(struct rvin_dev *vin)
{
int ret;
- /* All our sources are CSI-2 */
- vin->mbus_cfg.type = V4L2_MBUS_CSI2;
- vin->mbus_cfg.flags = 0;
-
vin->pad.flags = MEDIA_PAD_FL_SINK;
ret = media_entity_pads_init(>vdev.entity, 1, >pad);
if (ret)
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
b/drivers/media/platform/rcar-vin/rcar-dma.c
index f1c3585..d2b7002 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -659,8 +659,12 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
- vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
- VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
+ if (!vin->is_csi &&
+ vin->parallel->mbus_type == V4L2_MBUS_BT656)
+ vnmc |= VNMC_INF_YUV8_BT656;
+ else
+ vnmc |= VNMC_INF_YUV8_BT601;
+
input_is_yuv = true;
break;
case MEDIA_BUS_FMT_RGB888_1X24:
@@ -668,8 +672,12 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY10_2X10:
/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
- vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
- VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
+ if (!vin->is_csi &&
+ vin->parallel->
[PATCH v4 2/9] media: rcar-vin: Remove two empty lines
Remove un-necessary empty lines.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
Acked-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
---
drivers/media/platform/rcar-vin/rcar-core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 16d3e01..bcf02de 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -707,11 +707,9 @@ static int rvin_mc_parse_of_endpoint(struct device *dev,
return -EINVAL;
if (!of_device_is_available(to_of_node(asd->match.fwnode))) {
-
vin_dbg(vin, "OF device %pOF disabled, ignoring\n",
to_of_node(asd->match.fwnode));
return -ENOTCONN;
-
}
if (vin->group->csi[vep->base.id].fwnode) {
--
2.7.4
Re: [PATCH v3 1/9] media: rcar-vin: Rename 'digital' to 'parallel'
Hi Niklas,
On Thu, May 24, 2018 at 12:42:25AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your patch.
>
> On 2018-05-18 16:40:37 +0200, Jacopo Mondi wrote:
> > As the term 'digital' is used all over the rcar-vin code in place of
> > 'parallel', rename all the occurrencies.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> > ---
> > drivers/media/platform/rcar-vin/rcar-core.c | 72
> > ++---
> > drivers/media/platform/rcar-vin/rcar-dma.c | 4 +-
> > drivers/media/platform/rcar-vin/rcar-v4l2.c | 12 ++---
> > drivers/media/platform/rcar-vin/rcar-vin.h | 6 +--
> > 4 files changed, 47 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
> > b/drivers/media/platform/rcar-vin/rcar-core.c
> > index d3072e1..6b80f98 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-core.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> > @@ -376,12 +376,12 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int
> > direction)
> > }
> >
> > /*
> > -
> > - * Digital async notifier
> > + * Parallel async notifier
> > */
> >
> > /* The vin lock should be held when calling the subdevice attach and
> > detach */
> > -static int rvin_digital_subdevice_attach(struct rvin_dev *vin,
> > -struct v4l2_subdev *subdev)
> > +static int rvin_parallel_subdevice_attach(struct rvin_dev *vin,
> > + struct v4l2_subdev *subdev)
> > {
> > struct v4l2_subdev_mbus_code_enum code = {
> > .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> > @@ -392,15 +392,15 @@ static int rvin_digital_subdevice_attach(struct
> > rvin_dev *vin,
> > ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
> > if (ret < 0)
> > return ret;
> > - vin->digital->source_pad = ret;
> > + vin->parallel->source_pad = ret;
> >
> > ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
> > - vin->digital->sink_pad = ret < 0 ? 0 : ret;
> > + vin->parallel->sink_pad = ret < 0 ? 0 : ret;
> >
> > /* Find compatible subdevices mbus format */
> > vin->mbus_code = 0;
> > code.index = 0;
> > - code.pad = vin->digital->source_pad;
> > + code.pad = vin->parallel->source_pad;
> > while (!vin->mbus_code &&
> >!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
> > code.index++;
> > @@ -450,21 +450,21 @@ static int rvin_digital_subdevice_attach(struct
> > rvin_dev *vin,
> >
> > vin->vdev.ctrl_handler = >ctrl_handler;
> >
> > - vin->digital->subdev = subdev;
> > + vin->parallel->subdev = subdev;
> >
> > return 0;
> > }
> >
> > -static void rvin_digital_subdevice_detach(struct rvin_dev *vin)
> > +static void rvin_parallel_subdevice_detach(struct rvin_dev *vin)
> > {
> > rvin_v4l2_unregister(vin);
> > v4l2_ctrl_handler_free(>ctrl_handler);
> >
> > vin->vdev.ctrl_handler = NULL;
> > - vin->digital->subdev = NULL;
> > + vin->parallel->subdev = NULL;
> > }
> >
> > -static int rvin_digital_notify_complete(struct v4l2_async_notifier
> > *notifier)
> > +static int rvin_parallel_notify_complete(struct v4l2_async_notifier
> > *notifier)
> > {
> > struct rvin_dev *vin = notifier_to_vin(notifier);
> > int ret;
> > @@ -478,28 +478,28 @@ static int rvin_digital_notify_complete(struct
> > v4l2_async_notifier *notifier)
> > return rvin_v4l2_register(vin);
> > }
> >
> > -static void rvin_digital_notify_unbind(struct v4l2_async_notifier
> > *notifier,
> > - struct v4l2_subdev *subdev,
> > - struct v4l2_async_subdev *asd)
> > +static void rvin_parallel_notify_unbind(struct v4l2_async_notifier
> > *notifier,
> > + struct v4l2_subdev *subdev,
> > + struct v4l2_async_subdev *asd)
>
> When I run my indentation script this indentation changes from spaces to
> all tabs. If possible I would like to keep that as I usually run it on
> these files before submitting any patches, but it's not a big deal.
Oh I didn't notice that we now have exactly 8 spaces there.
I'll change this for sure!
Thanks
Re: [PATCH v3 2/3] arm64: dts: renesas: draak: Describe CVBS input
HI Laurent,
On Mon, May 21, 2018 at 04:10:34PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Monday, 21 May 2018 15:33:40 EEST jacopo mondi wrote:
> > On Mon, May 21, 2018 at 01:54:55PM +0300, Laurent Pinchart wrote:
> > > On Monday, 21 May 2018 12:57:05 EEST jacopo mondi wrote:
> > >> On Fri, May 18, 2018 at 06:12:15PM +0300, Laurent Pinchart wrote:
> > >>> On Friday, 18 May 2018 17:47:57 EEST Jacopo Mondi wrote:
> > >>>> Describe CVBS video input through analog video decoder ADV7180
> > >>>> connected to video input interface VIN4.
> > >>>>
> > >>>> The video input signal path is shared with HDMI video input, and
> > >>>> selected by on-board switches SW-53 and SW-54 with CVBS input
> > >>>> selected by the default switches configuration.
> > >>>>
> > >>>> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
> > >>>> Reviewed-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> > >>>>
> > >>>> ---
> > >>>> v2 -> v3:
> > >>>> - Add comment to describe the shared input video path
> > >>>> - Add my SoB and Niklas' R-b tags
> > >>>> ---
> > >>>>
> > >>>> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 42 ++
> > >>>> 1 file changed, 42 insertions(+)
> > >>>>
> > >>>> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > >>>> b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts index
> > >>>> 9d73de8..95745fc
> > >>>> 100644
> > >>>> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > >>>> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > >>>> @@ -142,6 +142,11 @@
> > >>>>groups = "usb0";
> > >>>>function = "usb0";
> > >>>>};
> > >>>> +
> > >>>> + vin4_pins_cvbs: vin4 {
> > >>>> + groups = "vin4_data8", "vin4_sync", "vin4_clk";
> > >>>> + function = "vin4";
> > >>>> + };
> > >>>> };
> > >>>>
> > >>>> {
> > >>>> @@ -154,6 +159,23 @@
> > >>>>reg = <0x50>;
> > >>>>pagesize = <8>;
> > >>>>};
> > >>>> +
> > >>>> + analog-video@20 {
> > >>>> + compatible = "adi,adv7180";
> > >>>> + reg = <0x20>;
> > >>>> +
> > >>>> + port {
> > >>>
> > >>> The adv7180 DT bindings document the output port as 3 or 6
> > >>> (respectively for the CP and ST versions of the chip). You should thus
> > >>> number the port. Apart from that the patch looks good.
> > >>
> > >> I admit I have barely copied this from Gen-2 boards DTS, but reading
> > >> the driver code and binding description again, I think this is
> > >> correct, as the output port numbering and mandatory input port (which
> > >> is missing here) only apply to adv7180cp/st chip versions.
> > >>
> > >> Here we describe plain adv7180, no need to number output ports afaict.
> > >
> > > Indeed, my bad.
> > >
> > > Shouldn't you however use "adi,adv7180cp" as that's the chip we are using
> > > ?
> > > The "adi,adv7180" has no port documented in its DT bindings, so it
> > > shouldn't have any port node at all.
> >
> > I'm a bit confused here.
> >
> > The only Gen-2 board using the "adi,adv7180cp" compatible string is
> > Gose, which is also the only one I can get schematics for. That board
> > indeed feature an ADV7180WBCP32Z, as the Draak does. I cannot get
> > schematics for any other Gen-2 board, to compare the ADV7180 variant
> > installed there. If anyone can confirm that all other Gen-2 board uses
> > a different version (or that all other Gen-2 board DTS file use a
> > wrong compatible string value), I'll re-send this with a different
> > compatible value and proper port nodes numbering.
>
> Other Gen2 boards use a ADV7180WBCP32Z as well. The issue here
[PATCH v2 1/4] dt-bindings: media: rcar-vin: Describe optional ep properties
Describe the optional properties for endpoint nodes of port@0
and port@1 of the R-Car VIN driver device tree bindings documentation.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
Acked-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
---
Documentation/devicetree/bindings/media/rcar_vin.txt | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 5c6f2a7..dab3118 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -54,6 +54,16 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
from external SoC pins described in video-interfaces.txt[1].
Describing more then one endpoint in port 0 is invalid. Only VIN
instances that are connected to external pins should have port 0.
+
+ - Optional properties for endpoint nodes of port@0:
+- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
+ respectively. Default is active high.
+- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
+ respectively. Default is active high.
+
+ If both HSYNC and VSYNC polarities are not specified, embedded
+ synchronization is selected.
+
- port 1 - sub-nodes describing one or more endpoints connected to
the VIN from local SoC CSI-2 receivers. The endpoint numbers must
use the following schema.
@@ -63,6 +73,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
- Endpoint 2 - sub-node describing the endpoint connected to CSI40
- Endpoint 3 - sub-node describing the endpoint connected to CSI41
+ Endpoint nodes of port@1 do not support any optional endpoint property.
+
Device node example for Gen2 platforms
--
@@ -113,7 +125,6 @@ Board setup example for Gen2 platforms (vin1 composite
video input)
vin1ep0: endpoint {
remote-endpoint = <>;
-bus-width = <8>;
};
};
};
--
2.7.4
[PATCH v2 4/4] ARM: dts: rcar-gen2: Remove unused VIN properties
The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
driver and only confuse users. Remove them in all Gen2 SoC that use
them.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
---
arch/arm/boot/dts/r8a7790-lager.dts | 3 ---
arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
arch/arm/boot/dts/r8a7791-porter.dts | 1 -
arch/arm/boot/dts/r8a7793-gose.dts| 3 ---
arch/arm/boot/dts/r8a7794-alt.dts | 1 -
arch/arm/boot/dts/r8a7794-silk.dts| 1 -
6 files changed, 12 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 092610e..9cdabfcf 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -885,10 +885,8 @@
port {
vin0ep2: endpoint {
remote-endpoint = <_out>;
- bus-width = <24>;
hsync-active = <0>;
vsync-active = <0>;
- pclk-sample = <1>;
data-active = <1>;
};
};
@@ -904,7 +902,6 @@
port {
vin1ep0: endpoint {
remote-endpoint = <>;
- bus-width = <8>;
};
};
};
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 8ab793d..033c9e3 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -857,10 +857,8 @@
port {
vin0ep2: endpoint {
remote-endpoint = <_out>;
- bus-width = <24>;
hsync-active = <0>;
vsync-active = <0>;
- pclk-sample = <1>;
data-active = <1>;
};
};
@@ -875,7 +873,6 @@
port {
vin1ep: endpoint {
remote-endpoint = <>;
- bus-width = <8>;
};
};
};
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts
b/arch/arm/boot/dts/r8a7791-porter.dts
index a01101b..c16e870 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -388,7 +388,6 @@
port {
vin0ep: endpoint {
remote-endpoint = <>;
- bus-width = <8>;
};
};
};
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
b/arch/arm/boot/dts/r8a7793-gose.dts
index aa209f6..60aaddb 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -765,10 +765,8 @@
port {
vin0ep2: endpoint {
remote-endpoint = <_out>;
- bus-width = <24>;
hsync-active = <0>;
vsync-active = <0>;
- pclk-sample = <1>;
data-active = <1>;
};
};
@@ -784,7 +782,6 @@
port {
vin1ep: endpoint {
remote-endpoint = <_out>;
- bus-width = <8>;
};
};
};
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts
b/arch/arm/boot/dts/r8a7794-alt.dts
index e170275..8ed7a71 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -388,7 +388,6 @@
port {
vin0ep: endpoint {
remote-endpoint = <>;
- bus-width = <8>;
};
};
};
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts
b/arch/arm/boot/dts/r8a7794-silk.dts
index 7808aae..6adfcd6 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -477,7 +477,6 @@
port {
vin0ep: endpoint {
remote-endpoint = <>;
- bus-width = <8>;
};
};
};
--
2.7.4
[PATCH v2 2/4] dt-bindings: media: rcar-vin: Document data-active
Document 'data-active' property in R-Car VIN device tree bindings. Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> v1 -> v2: - HSYNC is used in place of data enable signal only when running with explicit synchronizations. - The property is no more mandatory when running with embedded synchronizations, and default is selected. --- Documentation/devicetree/bindings/media/rcar_vin.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt index dab3118..2c144b4 100644 --- a/Documentation/devicetree/bindings/media/rcar_vin.txt +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt @@ -64,6 +64,12 @@ from local SoC CSI-2 receivers (port1) depending on SoC. If both HSYNC and VSYNC polarities are not specified, embedded synchronization is selected. +- data-active: data enable signal line polarity (CLKENB pin). + 0/1 for LOW/HIGH respectively. If not specified and running with + embedded synchronization, the default is active high. If not + specified and running with explicit synchronization, HSYNC is used + as data enable signal. + - port 1 - sub-nodes describing one or more endpoints connected to the VIN from local SoC CSI-2 receivers. The endpoint numbers must use the following schema. -- 2.7.4
[PATCH v2 3/4] media: rcar-vin: Handle CLOCKENB pin polarity
Handle CLOCKENB pin polarity, or use HSYNC in its place if polarity is
not specified and we're running on parallel data bus with explicit
synchronism signals.
While at there, simplify the media bus handling flags logic, inspecting
flags only if the system is running on parallel media bus type and ignore
flags when on CSI-2. Also change comments style to remove un-necessary
camel case and add a full stop at the end of sentences.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
---
drivers/media/platform/rcar-vin/rcar-dma.c | 34 ++
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 17f291f..ffd3d62 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -123,6 +123,8 @@
/* Video n Data Mode Register 2 bits */
#define VNDMR2_VPS (1 << 30)
#define VNDMR2_HPS (1 << 29)
+#define VNDMR2_CES (1 << 28)
+#define VNDMR2_CHS (1 << 23)
#define VNDMR2_FTEV(1 << 17)
#define VNDMR2_VLV(n) ((n & 0xf) << 12)
@@ -684,21 +686,35 @@ static int rvin_setup(struct rvin_dev *vin)
break;
}
- /* Enable VSYNC Field Toogle mode after one VSYNC input */
+ /* Enable VSYNC field toggle mode after one VSYNC input. */
if (vin->info->model == RCAR_GEN3)
dmr2 = VNDMR2_FTEV;
else
dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
- /* Hsync Signal Polarity Select */
- if (!vin->is_csi &&
- !(vin->parallel->mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
- dmr2 |= VNDMR2_HPS;
+ /* Synchronism signal polarities: only for parallel data bus. */
+ if (!vin->is_csi) {
+ /* Hsync signal polarity select. */
+ if (!(vin->parallel->mbus_flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
+ dmr2 |= VNDMR2_HPS;
- /* Vsync Signal Polarity Select */
- if (!vin->is_csi &&
- !(vin->parallel->mbus_flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
- dmr2 |= VNDMR2_VPS;
+ /* Vsync signal polarity select. */
+ if (!(vin->parallel->mbus_flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
+ dmr2 |= VNDMR2_VPS;
+
+ /*
+* Data enable signal polarity select.
+* Use HSYNC as data-enable if not specified and running
+* with explicit synchronizations; otherwise default 'high'
+* is selected.
+*/
+ if (vin->parallel->mbus_flags & V4L2_MBUS_DATA_ACTIVE_LOW)
+ dmr2 |= VNDMR2_CES;
+ else if (!(vin->parallel->mbus_flags &
+V4L2_MBUS_DATA_ACTIVE_HIGH) &&
+vin->parallel->mbus_type == V4L2_MBUS_PARALLEL)
+ dmr2 |= VNDMR2_CHS;
+ }
/*
* Output format
--
2.7.4
