[PATCH v5 3/3] media: i2c: Introduce a driver for the Techwell TW9900 decoder
The Techwell video decoder supports PAL, NTSC and SECAM input formats, and outputs a BT.656 signal. This commit adds support for this device, with basic support for NTSC and PAL, along with brightness and contrast controls. The TW9900 is capable of doing automatic standard detection, this is implemented with support for PAL and NTSC autodetection. Signed-off-by: Maxime Chevallier --- v1 -> v2: Set the media entity type to decoder, and implement the s_std/g_std ops V2 ->V3 : Fix coding-style issues, and remove the use of the bulk API for regulators. Make the driver select the media-controller and V4L2-subdev APIs. V3->V4: Fix a warning about an uninitialized ret variable in probe() V4->V5: Added .querystd() and .g_tvnorms(), dropped the .open() and unified the g_fmt() / s_fmt(). MAINTAINERS| 6 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile | 1 + drivers/media/i2c/tw9900.c | 664 + 4 files changed, 682 insertions(+) create mode 100644 drivers/media/i2c/tw9900.c diff --git a/MAINTAINERS b/MAINTAINERS index d92f85ca831d..d2e57e174b51 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17549,6 +17549,12 @@ L: linux-me...@vger.kernel.org S: Maintained F: drivers/media/rc/ttusbir.c +TECHWELL TW9900 VIDEO DECODER +M: Maxime Chevallier +L: linux-me...@vger.kernel.org +S: Maintained +F: drivers/media/i2c/tw9900.c + TECHWELL TW9910 VIDEO DECODER L: linux-me...@vger.kernel.org S: Orphan diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 462c0e059754..2dbcee42a915 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -426,6 +426,17 @@ config VIDEO_TW2804 To compile this driver as a module, choose M here: the module will be called tw2804. +config VIDEO_TW9900 + tristate "Techwell TW9900 video decoder" + depends on VIDEO_V4L2 && I2C + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API + help + Support for the Techwell tw9900 multi-standard video decoder. + + To compile this driver as a module, choose M here: the + module will be called tw9900. + config VIDEO_TW9903 tristate "Techwell TW9903 video decoder" depends on VIDEO_V4L2 && I2C diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 0c067beca066..3cc81e00b7da 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -49,6 +49,7 @@ obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o obj-$(CONFIG_VIDEO_TW2804) += tw2804.o +obj-$(CONFIG_VIDEO_TW9900) += tw9900.o obj-$(CONFIG_VIDEO_TW9903) += tw9903.o obj-$(CONFIG_VIDEO_TW9906) += tw9906.o obj-$(CONFIG_VIDEO_TW9910) += tw9910.o diff --git a/drivers/media/i2c/tw9900.c b/drivers/media/i2c/tw9900.c new file mode 100644 index ..d7a3be4f3daa --- /dev/null +++ b/drivers/media/i2c/tw9900.c @@ -0,0 +1,664 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Driver for the Techwell TW9900 multi-standard video decoder. + * + * Copyright (C) 2018 Fuzhou Rockchip Electronics Co., Ltd. + * Copyright (C) 2020 Maxime Chevallier + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define TW9900_REG_CHIP_ID 0x00 +#define TW9900_REG_CHIP_STATUS 0x01 +#define TW9900_REG_CHIP_STATUS_VLOCK 0x08 +#define TW9900_REG_CHIP_STATUS_VDLOSS 0x80 +#define TW9900_REG_OUT_FMT_CTL 0x03 +#define TW9900_REG_OUT_FMT_CTL_STANDBY 0xA7 +#define TW9900_REG_OUT_FMT_CTL_STREAMING 0xA0 +#define TW9900_REG_CKHY_HSDLY 0x04 +#define TW9900_REG_OUT_CTRL_I 0x05 +#define TW9900_REG_ANALOG_CTL 0x06 +#define TW9900_REG_CROP_HI 0x07 +#define TW9900_REG_VDELAY_LO 0x08 +#define TW9900_REG_VACTIVE_LO 0x09 +#define TW9900_REG_HACTIVE_LO 0x0B +#define TW9900_REG_CNTRL1 0x0C +#define TW9900_REG_BRIGHT_CTL 0x10 +#define TW9900_REG_CONTRAST_CTL0x11 +#define TW9900_REG_VBI_CNTL0x19 +#define TW9900_REG_ANAL_CTL_II 0x1A +#define TW9900_REG_OUT_CTRL_II 0x1B +#define TW9900_REG_STD_SEL 0x1C +#defineTW9900_REG_STD_SEL_AUTODETECT_IN_PROGRESS BIT(7) +#define TW9900_REG_STDR0x1D +#define TW9900_REG_MISSCNT 0x26 +#define TW9900_REG_MISC_CTL_II 0x2F +#define TW9900_REG_VVBI0x55 + +#define TW9900_CHIP_ID 0x00 + +#define VSYNC_POLL_INTERVAL_MS 20 +#define VSYNC_WAIT_MAX_POLLS 50 + +#define TW9900_STD_NTSC_M 0 +#define TW9900_STD_PAL_BDGHI 1 +#define TW9900_STD_SECAM 2 +#define TW9900_STD_NTSC_4_43 3 +#define TW9900_STD_PAL_M 4 +#define TW9900_STD_PAL_CN 5 +#define TW9900_STD_PAL_60 6 +#define TW9900_STD_AUTO7 +#define TW9900_STD_UNKOWN 7 + +#define TW9900_VIDEO_POLL_TIMEOUT 20 + +struct regval
[PATCH v5 1/3] dt-bindings: vendor-prefixes: Add techwell vendor prefix
Add prefix for Techwell, Inc. Acked-by: Rob Herring Signed-off-by: Maxime Chevallier --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index f6064d84a424..bd02517ebdbc 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1107,6 +1107,8 @@ patternProperties: description: TechNexion "^technologic,.*": description: Technologic Systems + "^techwell,.*": +description: Techwell, Inc. "^tempo,.*": description: Tempo Semiconductor "^techstar,.*": -- 2.25.4
[PATCH v5 0/3] media: i2c: Introduce driver for the TW9900 decoder
Hello everyone, This is the fifth version of the series adding support for the Techwell TW9900 multi standard decoder. It's a pretty simple decoder compared to the TW9910, since it doesn't have a built-in scaler/crop engine. this fifth version addresses reviews by Hans and Rob, with the notable addition of the querystd ops for standard detection. Any feedback is appreciated, Thanks, Maxime Maxime Chevallier (3): dt-bindings: vendor-prefixes: Add techwell vendor prefix media: dt-bindings: media: i2c: Add bindings for TW9900 media: i2c: Introduce a driver for the Techwell TW9900 decoder .../bindings/media/i2c/techwell,tw9900.yaml | 63 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile| 1 + drivers/media/i2c/tw9900.c| 664 ++ 6 files changed, 747 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml create mode 100644 drivers/media/i2c/tw9900.c -- 2.25.4
[PATCH v5 2/3] media: dt-bindings: media: i2c: Add bindings for TW9900
The Techwell TW9900 is a video decoder supporting multiple input
standards, such as PAL, NTSC and SECAM, and outputs a BT.656 video
signal.
It's designed to be low-power, posesses some features such as a
programmable comb-filter, and automatic input standard detection.
Signed-off-by: Maxime Chevallier
---
V2->V3 : Fix the example not compiling due to a typo in the reset-gpios
node.
V3->V4 : Add the missing reset-gpios node to the binding
V4->V5 : Renamed the file to match the compatible string, and referenced
the graph.yaml schema
.../bindings/media/i2c/techwell,tw9900.yaml | 63 +++
1 file changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml
b/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml
new file mode 100644
index ..b5047c26f0cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/techwell,tw9900.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Techwell TW9900 NTSC/PAL/SECAM video decoder
+
+maintainers:
+ - Maxime Chevallier
+
+description:
+ The tw9900 is a multi-standard video decoder, supporting NTSC, PAL and SECAM
+ standards with auto-detection features.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - techwell,tw9900
+
+ reg:
+maxItems: 1
+
+ vdd-supply:
+description: VDD power supply
+
+ reset-gpios:
+description: GPIO descriptor for the RESET input pin
+maxItems: 1
+
+ port:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Video port for the decoder output.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+tw9900: tw9900@44 {
+compatible = "techwell,tw9900";
+reg = <0x44>;
+
+vdd-supply = <_supply>;
+reset-gpios = < 5 GPIO_ACTIVE_LOW>;
+
+port {
+tw9900_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
--
2.25.4
Re: [PATCH v4 3/3] media: i2c: Introduce a driver for the Techwell TW9900 decoder
Hi Hans, and thanks for the review.
On Thu, 4 Mar 2021 16:37:53 +0100
Hans Verkuil wrote:
>Hi Maxime,
>
>Some more code review comments:
>
>> +static int tw9900_set_fmt(struct v4l2_subdev *sd,
>> + struct v4l2_subdev_pad_config *cfg,
>> + struct v4l2_subdev_format *fmt)
>> +{
>> +struct tw9900 *tw9900 = to_tw9900(sd);
>> +struct v4l2_mbus_framefmt *mbus_fmt = >format;
>> +
>> +tw9900_fill_fmt(tw9900->cur_mode, mbus_fmt);
>> +
>> +mbus_fmt->width = tw9900->cur_mode->width;
>> +mbus_fmt->height = tw9900->cur_mode->height;
>
>These two lines are already done in tw9900_fill_fmt.
Yes right, I'll remove that
[...]
>> +
>> +return 0;
>> +}
>> +
>> +static int tw9900_get_fmt(struct v4l2_subdev *sd,
>> + struct v4l2_subdev_pad_config *cfg,
>> + struct v4l2_subdev_format *fmt)
>> +{
>> +struct tw9900 *tw9900 = to_tw9900(sd);
>> +struct v4l2_mbus_framefmt *mbus_fmt = >format;
>> +
>> +tw9900_fill_fmt(tw9900->cur_mode, mbus_fmt);
>> +
>> +return 0;
>> +}
>
>In fact, tw9900_set_fmt is identical to tw9900_get_fmt. I would just drop
>tw9900_set_fmt and point both .get_fmt and .set_fmt to the same function.
OK, that will be cleaner indeed
[...]
>> +
>> +static int tw9900_enum_mbus_code(struct v4l2_subdev *sd,
>> + struct v4l2_subdev_pad_config *cfg,
>> + struct v4l2_subdev_mbus_code_enum *code)
>> +{
>> +if (code->index >= 1)
>> +return -EINVAL;
>> +
>> +code->code = MEDIA_BUS_FMT_UYVY8_2X8;
>> +
>> +return 0;
>> +}
>> +
>> +static int tw9900_enum_frame_sizes(struct v4l2_subdev *sd,
>> + struct v4l2_subdev_pad_config *cfg,
>> + struct v4l2_subdev_frame_size_enum *fse)
>> +{
>> +u32 index = fse->index;
>> +
>> +if (index >= 1)
>> +return -EINVAL;
>> +
>> +fse->code = MEDIA_BUS_FMT_UYVY8_2X8;
>> +
>> +fse->min_width = supported_modes[index].width;
>> +fse->max_width = supported_modes[index].width;
>> +fse->max_height = supported_modes[index].height;
>> +fse->min_height = supported_modes[index].height;
>> +
>> +return 0;
>> +}
>
>This function is not typically used by video receivers since the framesize is
>fixed depending on the standard. So there is nothing to enumerate.
>
>It is wrong in any case since it reports just supported_modes[0] (i.e. PAL)
>even if the current mode is NTSC. But it can just be dropped for video
>receivers.
Ok thanks, I'll drop that then.
[...]
>> +/* Wait for VSync lock */
>> +for (i = 0; i < VSYNC_WAIT_MAX_POLLS; i++) {
>> +u8 status = tw9900_read_reg(tw9900->client,
>> +TW9900_REG_CHIP_STATUS);
>> +if (!(status & TW9900_REG_CHIP_STATUS_VDLOSS) &&
>> +(status & TW9900_REG_CHIP_STATUS_VLOCK))
>> +break;
>> +
>> +msleep(VSYNC_POLL_INTERVAL_MS);
>> +}
>
>Why do you have to wait for a vsync lock?
>
>Most drivers just start regardless of lock. If there is no lock, then there
>is either no data being streamed (so the DMA of the video bridge will be idle
>as well) or it is just transmitting noise (typical for SDTV receivers). At
>least
>until a valid signal appears eventually.
In this case, it will transmit noise.
As stated a bit below, this was implemented because this decoder
actually supports automatic standard detection, but the reported
standard can only be read once the vsync lock is acquired.
So this is a remainder of what I implemented to try to get the standard
detection work, but I can drop that for now.
[...]
>> +static int tw9900_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
>> +{
>> +struct tw9900 *tw9900 = to_tw9900(sd);
>> +struct v4l2_mbus_framefmt *try_fmt;
>> +
>> +try_fmt = v4l2_subdev_get_try_format(sd, fh->pad, 0);
>> +
>> +/* Initialize try_fmt */
>> +tw9900_fill_fmt(tw9900->cur_mode, try_fmt);
>> +
>> +return 0;
>> +}
>
>Since the format is fixed based on the current standard, there is no point
>in initializing try_fmt as it won't be used. So just drop tw9900_open
>altogether.
Ok I'll drop that :)
[...]
>> +static const struct v4l2_subdev_video_ops tw9900_video_ops = {
>> +.s_std = tw9900_s_std,
>> +.g_std = tw9900_g_std,
>
>Can the tw9900 detect the standard? (I.e. PAL, SECAM, NTSC)
>
>If so, you should implement querystd. I see that none of the other tw*.c
>drivers
>support this, so I suspect there is no hardware support for this.
So, there's hardware support for this, and I've been trying to get this
to work for a while. I've come to a point where the standard detection
"almost" works, but detects the wrong standard about once every 10
occurences. I don't know if this is due to the
[PATCH v4 3/3] media: i2c: Introduce a driver for the Techwell TW9900 decoder
The Techwell video decoder supports PAL, NTSC and SECAM input formats,
and outputs a BT.656 signal.
This commit adds support for this device, with basic support for NTSC
and PAL, along with brightness and contrast controls.
Signed-off-by: Maxime Chevallier
---
v1 -> v2: Set the media entity type to decoder, and implement the
s_std/g_std ops
V2 ->V3 : Fix coding-style issues, and remove the use of the bulk API
for regulators. Make the driver select the media-controller and
V4L2-subdev APIs.
V3->V4: Fix a warning about an uninitialized ret variable in probe()
MAINTAINERS| 6 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/tw9900.c | 617 +
4 files changed, 635 insertions(+)
create mode 100644 drivers/media/i2c/tw9900.c
diff --git a/MAINTAINERS b/MAINTAINERS
index bfc1b86e3e73..dde9f7bdd720 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17425,6 +17425,12 @@ L: linux-me...@vger.kernel.org
S: Maintained
F: drivers/media/rc/ttusbir.c
+TECHWELL TW9900 VIDEO DECODER
+M: Maxime Chevallier
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/i2c/tw9900.c
+
TECHWELL TW9910 VIDEO DECODER
L: linux-me...@vger.kernel.org
S: Orphan
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 2b9d81e4794a..5f902557c8e5 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -426,6 +426,17 @@ config VIDEO_TW2804
To compile this driver as a module, choose M here: the
module will be called tw2804.
+config VIDEO_TW9900
+ tristate "Techwell TW9900 video decoder"
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
+ help
+ Support for the Techwell tw9900 multi-standard video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9900.
+
config VIDEO_TW9903
tristate "Techwell TW9903 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index a3149dce21bb..9e7df99201c6 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
+obj-$(CONFIG_VIDEO_TW9900) += tw9900.o
obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
diff --git a/drivers/media/i2c/tw9900.c b/drivers/media/i2c/tw9900.c
new file mode 100644
index ..635268211982
--- /dev/null
+++ b/drivers/media/i2c/tw9900.c
@@ -0,0 +1,617 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the Techwell TW9900 multi-standard video decoder.
+ *
+ * Copyright (C) 2018 Fuzhou Rockchip Electronics Co., Ltd.
+ * Copyright (C) 2020 Maxime Chevallier
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TW9900_REG_CHIP_ID 0x00
+#define TW9900_REG_CHIP_STATUS 0x01
+#define TW9900_REG_CHIP_STATUS_VLOCK 0x08
+#define TW9900_REG_CHIP_STATUS_VDLOSS 0x80
+#define TW9900_REG_OUT_FMT_CTL 0x03
+#define TW9900_REG_OUT_FMT_CTL_STANDBY 0xA7
+#define TW9900_REG_OUT_FMT_CTL_STREAMING 0xA0
+#define TW9900_REG_CKHY_HSDLY 0x04
+#define TW9900_REG_OUT_CTRL_I 0x05
+#define TW9900_REG_ANALOG_CTL 0x06
+#define TW9900_REG_CROP_HI 0x07
+#define TW9900_REG_VDELAY_LO 0x08
+#define TW9900_REG_VACTIVE_LO 0x09
+#define TW9900_REG_HACTIVE_LO 0x0B
+#define TW9900_REG_CNTRL1 0x0C
+#define TW9900_REG_BRIGHT_CTL 0x10
+#define TW9900_REG_CONTRAST_CTL0x11
+#define TW9900_REG_VBI_CNTL0x19
+#define TW9900_REG_ANAL_CTL_II 0x1A
+#define TW9900_REG_OUT_CTRL_II 0x1B
+#define TW9900_REG_STD_SEL 0x1C
+#define TW9900_REG_MISSCNT 0x26
+#define TW9900_REG_MISC_CTL_II 0x2F
+#define TW9900_REG_VVBI0x55
+
+#define TW9900_CHIP_ID 0x00
+
+#define VSYNC_POLL_INTERVAL_MS 20
+#define VSYNC_WAIT_MAX_POLLS 50
+
+struct regval {
+ u8 addr;
+ u8 val;
+};
+
+struct tw9900_mode {
+ u32 width;
+ u32 height;
+ u32 skip_top;
+ u32 std;
+ u32 field;
+ const struct regval *reg_list;
+ int n_regs;
+};
+
+struct tw9900 {
+ struct i2c_client *client;
+ struct gpio_desc *reset_gpio;
+ struct regulator *regulator;
+
+ bool streaming;
+
+ struct v4l2_subdev subdev;
+ struct v4l2_ctrl_handler hdl;
+ struct media_pad pad;
+
+ struct timer_list timer;
+ struct work_struct work_i2c_poll;
+
+ const struct tw9900_mode *cur_mode;
+};
+
+#define to_tw9900(sd) container_of(sd, struct tw9900, subdev)
+
[PATCH v4 0/3] media: i2c: Introduce driver for the TW9900 decoder
Hello everyone, This is the fourth version of the series adding support for the Techwell TW9900 multi standard decoder. It's a pretty simple decoder compared to the TW9910, since it doesn't have a built-in scaler/crop engine. This V4 addresses one warning detected by the 0day bot, along with a binding example validation error. Any feedback is appreciated, Thanks, Maxime Maxime Chevallier (3): dt-bindings: vendor-prefixes: Add techwell vendor prefix media: dt-bindings: media: i2c: Add bindings for TW9900 media: i2c: Introduce a driver for the Techwell TW9900 decoder .../devicetree/bindings/media/i2c/tw9900.yaml | 64 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile| 1 + drivers/media/i2c/tw9900.c| 617 ++ 6 files changed, 701 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/tw9900.yaml create mode 100644 drivers/media/i2c/tw9900.c -- 2.25.4
[PATCH v4 2/3] media: dt-bindings: media: i2c: Add bindings for TW9900
The Techwell TW9900 is a video decoder supporting multiple input
standards, such as PAL, NTSC and SECAM, and outputs a BT.656 video
signal.
It's designed to be low-power, posesses some features such as a
programmable comb-filter, and automatic input standard detection.
Signed-off-by: Maxime Chevallier
---
V2->V3 : Fix the example not compiling due to a typo in the reset-gpios
node.
V3->V4 : Add the missing reset-gpios node to the binding
.../devicetree/bindings/media/i2c/tw9900.yaml | 64 +++
1 file changed, 64 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tw9900.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
b/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
new file mode 100644
index ..d27196e37416
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/tw9900.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Techwell TW9900 NTSC/PAL/SECAM video decoder
+
+maintainers:
+ - Maxime Chevallier
+
+description:
+ The tw9900 is a multi-standard video decoder, supporting NTSC, PAL and SECAM
+ standards with auto-detection features.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - techwell,tw9900
+
+ reg:
+maxItems: 1
+
+ vdd-supply:
+description: VDD power supply
+
+ reset-gpios:
+description: GPIO descriptor for the RESET input pin
+maxItems: 1
+
+ port:
+type: object
+description:
+ A node containing a single endpoint as doucmented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+tw9900: tw9900@44 {
+compatible = "techwell,tw9900";
+reg = <0x44>;
+
+vdd-supply = <_supply>;
+reset-gpios = < 5 GPIO_ACTIVE_LOW>;
+
+port {
+tw9900_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
--
2.25.4
[PATCH v4 1/3] dt-bindings: vendor-prefixes: Add techwell vendor prefix
Add prefix for Techwell, Inc. Acked-by: Rob Herring Signed-off-by: Maxime Chevallier --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 041ae90b0d8f..467b59d8513b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1095,6 +1095,8 @@ patternProperties: description: TechNexion "^technologic,.*": description: Technologic Systems + "^techwell,.*": +description: Techwell, Inc. "^tempo,.*": description: Tempo Semiconductor "^techstar,.*": -- 2.25.4
[PATCH net-next v2 2/2] net: mvneta: Implement mqprio support
Implement a basic MQPrio support, inserting rules in RX that translate
the TC to prio mapping into vlan prio to queues.
The TX logic stays the same as when we don't offload the qdisc.
Signed-off-by: Maxime Chevallier
---
V2 : Fixed the reverse xmas tree, as per Andrew's review.
Fixed a compile warning from the ktest bot
drivers/net/ethernet/marvell/mvneta.c | 61 +++
1 file changed, 61 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index 8e410fafff8d..a635cf84608a 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -102,6 +102,8 @@
#define MVNETA_TX_NO_DATA_SWAP BIT(5)
#define MVNETA_DESC_SWAPBIT(6)
#define MVNETA_TX_BRST_SZ_MASK(burst) ((burst) << 22)
+#defineMVNETA_VLAN_PRIO_TO_RXQ 0x2440
+#define MVNETA_VLAN_PRIO_RXQ_MAP(prio, rxq) ((rxq) << ((prio) * 3))
#define MVNETA_PORT_STATUS 0x2444
#define MVNETA_TX_IN_PRGRS BIT(1)
#define MVNETA_TX_FIFO_EMPTYBIT(8)
@@ -490,6 +492,7 @@ struct mvneta_port {
u8 mcast_count[256];
u16 tx_ring_size;
u16 rx_ring_size;
+ u8 prio_tc_map[8];
phy_interface_t phy_interface;
struct device_node *dn;
@@ -4922,6 +4925,63 @@ static int mvneta_ethtool_set_eee(struct net_device *dev,
return phylink_ethtool_set_eee(pp->phylink, eee);
}
+static void mvneta_clear_rx_prio_map(struct mvneta_port *pp)
+{
+ mvreg_write(pp, MVNETA_VLAN_PRIO_TO_RXQ, 0);
+}
+
+static void mvneta_setup_rx_prio_map(struct mvneta_port *pp)
+{
+ u32 val = 0;
+ int i;
+
+ for (i = 0; i < rxq_number; i++)
+ val |= MVNETA_VLAN_PRIO_RXQ_MAP(i, pp->prio_tc_map[i]);
+
+ mvreg_write(pp, MVNETA_VLAN_PRIO_TO_RXQ, val);
+}
+
+static int mvneta_setup_mqprio(struct net_device *dev,
+ struct tc_mqprio_qopt *qopt)
+{
+ struct mvneta_port *pp = netdev_priv(dev);
+ u8 num_tc;
+ int i;
+
+ qopt->hw = TC_MQPRIO_HW_OFFLOAD_TCS;
+ num_tc = qopt->num_tc;
+
+ if (num_tc > rxq_number)
+ return -EINVAL;
+
+ if (!num_tc) {
+ mvneta_clear_rx_prio_map(pp);
+ netdev_reset_tc(dev);
+ return 0;
+ }
+
+ memcpy(pp->prio_tc_map, qopt->prio_tc_map, sizeof(pp->prio_tc_map));
+
+ mvneta_setup_rx_prio_map(pp);
+
+ netdev_set_num_tc(dev, qopt->num_tc);
+ for (i = 0; i < qopt->num_tc; i++)
+ netdev_set_tc_queue(dev, i, qopt->count[i], qopt->offset[i]);
+
+ return 0;
+}
+
+static int mvneta_setup_tc(struct net_device *dev, enum tc_setup_type type,
+ void *type_data)
+{
+ switch (type) {
+ case TC_SETUP_QDISC_MQPRIO:
+ return mvneta_setup_mqprio(dev, type_data);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
static const struct net_device_ops mvneta_netdev_ops = {
.ndo_open= mvneta_open,
.ndo_stop= mvneta_stop,
@@ -4934,6 +4994,7 @@ static const struct net_device_ops mvneta_netdev_ops = {
.ndo_do_ioctl= mvneta_ioctl,
.ndo_bpf = mvneta_xdp,
.ndo_xdp_xmit= mvneta_xdp_xmit,
+ .ndo_setup_tc= mvneta_setup_tc,
};
static const struct ethtool_ops mvneta_eth_tool_ops = {
--
2.25.4
[PATCH net-next v2 0/2] net: mvneta: implement basic MQPrio support
Hi everyone, This is V2 for the MQPrio support in mvneta. This small series adds basic support for mqprio offloading, by having the rx queueing mirroring the TCs based on VLAN prio fields. This was tested on Armada 3700, and proves useful to make sure high-priority traffic has a better chance not getting dropped when there's lots of packets incoming. The first patch of the series deals with the per-cpu interrupts on the armada 3700. Since they don't work, there were already some patches applied to keep all queue mappings to CPU0, but there still were some remaining mappings left to be dealt with. The second patch implements the MQPrio offloading for the receive path. Changes in V2 : - Add a Fixes tag for the first patch - Fix some warnings and the xmas tree in the second patch Thanks, Maxime Maxime Chevallier (2): net: mvneta: Remove per-cpu queue mapping for Armada 3700 net: mvneta: Implement mqprio support drivers/net/ethernet/marvell/mvneta.c | 70 ++- 1 file changed, 69 insertions(+), 1 deletion(-) -- 2.25.4
[PATCH net-next v2 1/2] net: mvneta: Remove per-cpu queue mapping for Armada 3700
According to Errata #23 "The per-CPU GbE interrupt is limited to Core
0", we can't use the per-cpu interrupt mechanism on the Armada 3700
familly.
This is correctly checked for RSS configuration, but the initial queue
mapping is still done by having the queues spread across all the CPUs in
the system, both in the init path and in the cpu_hotplug path.
Fixes: 2636ac3cc2b4 ("net: mvneta: Add network support for Armada 3700 SoC")
Signed-off-by: Maxime Chevallier
---
V2: Added Fixes tag, as per Pali's review
drivers/net/ethernet/marvell/mvneta.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index 6290bfb6494e..8e410fafff8d 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3428,7 +3428,9 @@ static int mvneta_txq_sw_init(struct mvneta_port *pp,
return -ENOMEM;
/* Setup XPS mapping */
- if (txq_number > 1)
+ if (pp->neta_armada3700)
+ cpu = 0;
+ else if (txq_number > 1)
cpu = txq->id % num_present_cpus();
else
cpu = pp->rxq_def % num_present_cpus();
@@ -4206,6 +4208,11 @@ static int mvneta_cpu_online(unsigned int cpu, struct
hlist_node *node)
node_online);
struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu);
+ /* Armada 3700's per-cpu interrupt for mvneta is broken, all interrupts
+* are routed to CPU 0, so we don't need all the cpu-hotplug support
+*/
+ if (pp->neta_armada3700)
+ return 0;
spin_lock(>lock);
/*
--
2.25.4
Re: [PATCH net-next 2/2] net: mvneta: Implement mqprio support
Hi Andrew,
On Sat, 13 Feb 2021 20:45:25 +0100
Andrew Lunn wrote:
>On Fri, Feb 12, 2021 at 04:12:20PM +0100, Maxime Chevallier wrote:
>> +static void mvneta_setup_rx_prio_map(struct mvneta_port *pp)
>> +{
>> +int i;
>> +u32 val = 0;
>
>Hi Maxime
>
>Reverse Chrismtass tree please.
Ah yes sorry, I'll fix that in V2.
Thanks for the review,
Maxime
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Re: [PATCH net-next 1/2] net: mvneta: Remove per-cpu queue mapping for Armada 3700
Hi Pali,
On Mon, 15 Feb 2021 00:50:58 +0100
Pali Rohár wrote:
>> According to Errata #23 "The per-CPU GbE interrupt is limited to Core
>> 0", we can't use the per-cpu interrupt mechanism on the Armada 3700
>> familly.
>>
>> This is correctly checked for RSS configuration, but the initial queue
>> mapping is still done by having the queues spread across all the CPUs in
>> the system, both in the init path and in the cpu_hotplug path.
>
>Hello Maxime!
>
>This patch looks like a bug fix for Armada 3700 SoC. What about marking
>this commit with Fixes line? E.g.:
>
>Fixes: 2636ac3cc2b4 ("net: mvneta: Add network support for Armada 3700
> SoC")
Yes you're correct, I'll add that to the V2 !
Thanks for the review,
Maxime
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[PATCH net-next 1/2] net: mvneta: Remove per-cpu queue mapping for Armada 3700
According to Errata #23 "The per-CPU GbE interrupt is limited to Core 0", we can't use the per-cpu interrupt mechanism on the Armada 3700 familly. This is correctly checked for RSS configuration, but the initial queue mapping is still done by having the queues spread across all the CPUs in the system, both in the init path and in the cpu_hotplug path. Signed-off-by: Maxime Chevallier --- drivers/net/ethernet/marvell/mvneta.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c index 6290bfb6494e..8e410fafff8d 100644 --- a/drivers/net/ethernet/marvell/mvneta.c +++ b/drivers/net/ethernet/marvell/mvneta.c @@ -3428,7 +3428,9 @@ static int mvneta_txq_sw_init(struct mvneta_port *pp, return -ENOMEM; /* Setup XPS mapping */ - if (txq_number > 1) + if (pp->neta_armada3700) + cpu = 0; + else if (txq_number > 1) cpu = txq->id % num_present_cpus(); else cpu = pp->rxq_def % num_present_cpus(); @@ -4206,6 +4208,11 @@ static int mvneta_cpu_online(unsigned int cpu, struct hlist_node *node) node_online); struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu); + /* Armada 3700's per-cpu interrupt for mvneta is broken, all interrupts +* are routed to CPU 0, so we don't need all the cpu-hotplug support +*/ + if (pp->neta_armada3700) + return 0; spin_lock(>lock); /* -- 2.25.4
[PATCH net-next 2/2] net: mvneta: Implement mqprio support
Implement a basic MQPrio support, inserting rules in RX that translate
the TC to prio mapping into vlan prio to queues.
The TX logic stays the same as when we don't offload the qdisc.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvneta.c | 65 +++
1 file changed, 65 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index 8e410fafff8d..5389d195d4ce 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -102,6 +102,8 @@
#define MVNETA_TX_NO_DATA_SWAP BIT(5)
#define MVNETA_DESC_SWAPBIT(6)
#define MVNETA_TX_BRST_SZ_MASK(burst) ((burst) << 22)
+#defineMVNETA_VLAN_PRIO_TO_RXQ 0x2440
+#define MVNETA_VLAN_PRIO_RXQ_MAP(prio, rxq) ((rxq) << ((prio) * 3))
#define MVNETA_PORT_STATUS 0x2444
#define MVNETA_TX_IN_PRGRS BIT(1)
#define MVNETA_TX_FIFO_EMPTYBIT(8)
@@ -490,6 +492,7 @@ struct mvneta_port {
u8 mcast_count[256];
u16 tx_ring_size;
u16 rx_ring_size;
+ u8 prio_tc_map[8];
phy_interface_t phy_interface;
struct device_node *dn;
@@ -4922,6 +4925,67 @@ static int mvneta_ethtool_set_eee(struct net_device *dev,
return phylink_ethtool_set_eee(pp->phylink, eee);
}
+static void mvneta_clear_rx_prio_map(struct mvneta_port *pp)
+{
+ mvreg_write(pp, MVNETA_VLAN_PRIO_TO_RXQ, 0);
+}
+
+static void mvneta_setup_rx_prio_map(struct mvneta_port *pp)
+{
+ int i;
+ u32 val = 0;
+
+ for (i = 0; i < rxq_number; i++)
+ val |= MVNETA_VLAN_PRIO_RXQ_MAP(i, pp->prio_tc_map[i]);
+
+ mvreg_write(pp, MVNETA_VLAN_PRIO_TO_RXQ, val);
+}
+
+static int mvneta_setup_mqprio(struct net_device *dev,
+ struct tc_mqprio_qopt *qopt)
+{
+ struct mvneta_port *pp = netdev_priv(dev);
+ u8 num_tc;
+ int i;
+
+ qopt->hw = TC_MQPRIO_HW_OFFLOAD_TCS;
+ num_tc = qopt->num_tc;
+
+ if (num_tc > rxq_number)
+ return -EINVAL;
+
+ if (!num_tc) {
+ mvneta_clear_rx_prio_map(pp);
+ netdev_reset_tc(dev);
+ return 0;
+ }
+
+ if (qopt->prio_tc_map) {
+ memcpy(pp->prio_tc_map, qopt->prio_tc_map,
+ sizeof(pp->prio_tc_map));
+
+ mvneta_setup_rx_prio_map(pp);
+
+ netdev_set_num_tc(dev, qopt->num_tc);
+ for (i = 0; i < qopt->num_tc; i++)
+ netdev_set_tc_queue(dev, i, qopt->count[i],
+ qopt->offset[i]);
+ }
+
+ return 0;
+}
+
+static int mvneta_setup_tc(struct net_device *dev, enum tc_setup_type type,
+ void *type_data)
+{
+ switch (type) {
+ case TC_SETUP_QDISC_MQPRIO:
+ return mvneta_setup_mqprio(dev, type_data);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
static const struct net_device_ops mvneta_netdev_ops = {
.ndo_open= mvneta_open,
.ndo_stop= mvneta_stop,
@@ -4934,6 +4998,7 @@ static const struct net_device_ops mvneta_netdev_ops = {
.ndo_do_ioctl= mvneta_ioctl,
.ndo_bpf = mvneta_xdp,
.ndo_xdp_xmit= mvneta_xdp_xmit,
+ .ndo_setup_tc= mvneta_setup_tc,
};
static const struct ethtool_ops mvneta_eth_tool_ops = {
--
2.25.4
[PATCH net-next 0/2] net: mvneta: Implement basic MQPrio support
Hi everyone, This small series adds basic support for mqprio offloading, by having the rx queueing mirroring the TCs based on VLAN prio fields. This was tested on Armada 3700, and proves useful to make sure high-priority traffic has a better chance not getting dropped when there's lots of packets incoming. The first patch of the series deals with the per-cpu interrupts on the armada 3700. Since they don't work, there were already some patches applied to keep all queue mappings to CPU0, but there still were some remaining mappings left to be dealt with. The second patch implements the MQPrio offloading for the receive path. Thanks ! Maxime Maxime Chevallier (2): net: mvneta: Remove per-cpu queue mapping for Armada 3700 net: mvneta: Implement mqprio support drivers/net/ethernet/marvell/mvneta.c | 74 ++- 1 file changed, 73 insertions(+), 1 deletion(-) -- 2.25.4
[PATCH v5 3/3] arm64: dts: rockchip: Add the camera interface description of the PX30
The PX30 has a camera interface, supporting CSI2 and BT656
modes. Add a DT description for this interface.
Signed-off-by: Maxime Chevallier
---
V3 : Renamed the controlled
V4: Fixed the clock names
v5: No change
arch/arm64/boot/dts/rockchip/px30.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 2695ea8cda14..39987afe5ed5 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1106,6 +1106,18 @@ vopl_mmu: iommu@ff470f00 {
status = "disabled";
};
+ vip: vip@ff49 {
+ compatible = "rockchip,px30-vip";
+ reg = <0x0 0xff49 0x0 0x200>;
+ interrupts = ;
+ clocks = < ACLK_CIF>, < HCLK_CIF>, < PCLK_CIF>,
< SCLK_CIF_OUT>;
+ clock-names = "aclk", "hclk", "pclk";
+ power-domains = < PX30_PD_VI>;
+ resets = < SRST_CIF_A>, < SRST_CIF_H>, <
SRST_CIF_PCLKIN>;
+ reset-names = "axi", "ahb", "pclkin";
+ status = "disabled";
+ };
+
qos_gmac: qos@ff518000 {
compatible = "syscon";
reg = <0x0 0xff518000 0x0 0x20>;
--
2.25.4
[PATCH v5 2/3] media: rockchip: Introduce driver for Rockhip's camera interface
Introduce a driver for the camera interface on some Rockchip platforms. This controller supports CSI2 and BT656 interfaces, but for now only the BT656 interface could be tested, hence it's the only one that's supported in the first version of this driver. This controller can be fond on PX30, RK1808, RK3128, RK3288 and RK3288, but for now it's only be tested on PX30. Most of this driver was written following the BSP driver from rockchip, removing the parts that either didn't fit correctly the guidelines, or that couldn't be tested. In the BSP, this driver is known as the "cif" driver, but this was renamed to "vip" to better fit the controller denomination in the datasheet. This basic version doesn't support cropping nor scaling, and is only designed with one sensor being attached to it a any time. This version uses the "pingpong" mode of the controller, which is a double-buffering mechanism. Signed-off-by: Maxime Chevallier --- V3: - renamed the driver - Took Hans, Robin and Ezequiel's reviews into account - Implemented the ouble-buffering mode v4: - Took Ezequiel's reviews into account - Reworked the imagesize computation - Fixed the bulk API use for clks and rsts v5: - Fixed a compile-time warning - Fixed a v4l2-compliance warning drivers/media/platform/Kconfig| 15 + drivers/media/platform/Makefile |1 + drivers/media/platform/rockchip/vip/Makefile |3 + drivers/media/platform/rockchip/vip/capture.c | 1146 + drivers/media/platform/rockchip/vip/dev.c | 331 + drivers/media/platform/rockchip/vip/dev.h | 203 +++ drivers/media/platform/rockchip/vip/regs.h| 260 7 files changed, 1959 insertions(+) create mode 100644 drivers/media/platform/rockchip/vip/Makefile create mode 100644 drivers/media/platform/rockchip/vip/capture.c create mode 100644 drivers/media/platform/rockchip/vip/dev.c create mode 100644 drivers/media/platform/rockchip/vip/dev.h create mode 100644 drivers/media/platform/rockchip/vip/regs.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 35a18d388f3f..a1778de3774f 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -507,6 +507,21 @@ config VIDEO_ROCKCHIP_RGA To compile this driver as a module choose m here. +config VIDEO_ROCKCHIP_VIP + tristate "Rockchip VIP (Video InPut) Camera Interface" + depends on VIDEO_DEV && VIDEO_V4L2 + depends on ARCH_ROCKCHIP || COMPILE_TEST + select VIDEOBUF2_DMA_SG + select VIDEOBUF2_DMA_CONTIG + select V4L2_FWNODE + select V4L2_MEM2MEM_DEV + help + This is a v4l2 driver for Rockchip SOC Camera interface. It supports + BT.656 and CSI2 inputs. + + To compile this driver as a module choose m here : the module will + be called video_rkvip. + config VIDEO_TI_VPE tristate "TI VPE (Video Processing Engine) driver" depends on VIDEO_DEV && VIDEO_V4L2 diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 1d63aa956bcd..dc82b6932bd0 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/ obj-$(CONFIG_VIDEO_ROCKCHIP_ISP1) += rockchip/rkisp1/ obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip/rga/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VIP) += rockchip/vip/ obj-y += omap/ diff --git a/drivers/media/platform/rockchip/vip/Makefile b/drivers/media/platform/rockchip/vip/Makefile new file mode 100644 index ..c239ee0bb0fe --- /dev/null +++ b/drivers/media/platform/rockchip/vip/Makefile @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_VIDEO_ROCKCHIP_VIP) += video_rkvip.o +video_rkvip-objs += dev.o capture.o diff --git a/drivers/media/platform/rockchip/vip/capture.c b/drivers/media/platform/rockchip/vip/capture.c new file mode 100644 index ..6794b491da85 --- /dev/null +++ b/drivers/media/platform/rockchip/vip/capture.c @@ -0,0 +1,1146 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Rockchip VIP Camera Interface Driver + * + * Copyright (C) 2018 Rockchip Electronics Co., Ltd. + * Copyright (C) 2020 Maxime Chevallier + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "dev.h" +#include "regs.h" + +#define VIP_REQ_BUFS_MIN 3 +#define VIP_MIN_WIDTH 64 +#define VIP_MIN_HEIGHT 64 +#define VIP_MAX_WIDTH 8192 +#define VIP_MAX_HEIGHT 8192 + +#define RK_VIP_PLANE_Y 0 +#define RK_VIP_PLANE_CBCR 1 + +#define VIP_FETCH_Y_LAST_LINE(VAL) ((VAL) & 0x1fff) +/* Check if swap y and c in bt1120 mode */ +#define VIP_FETCH_IS_Y_FIRST(VAL) ((VAL) & 0xf) + +static const struct vip_output_fmt
[PATCH v5 1/3] media: dt-bindings: media: Document Rockchip VIP bindings
Add a documentation for the Rockchip Camera Interface controller
binding.
This controller can be found on platforms such as the PX30 or the
RK3288, the PX30 being the only platform supported so far.
Signed-off-by: Maxime Chevallier
---
v3: Renamed the controller to "vip"
v4: fixed the binding to get a compiling example
v5: Fixed the binding even more, the 'endpoint' description was missing
.../bindings/media/rockchip-vip.yaml | 101 ++
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rockchip-vip.yaml
diff --git a/Documentation/devicetree/bindings/media/rockchip-vip.yaml
b/Documentation/devicetree/bindings/media/rockchip-vip.yaml
new file mode 100644
index ..93055273b32f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-vip.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/rockchip-vip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip VIP Camera Interface
+
+maintainers:
+ - Maxime Chevallier
+
+description: |-
+ Camera Interface for Rockchip platforms
+
+properties:
+ compatible:
+const: rockchip,px30-vip
+
+ reg:
+maxItems: 2
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: ACLK
+ - description: HCLK
+ - description: PCLK IN
+
+ clock-names:
+items:
+ - const: aclk
+ - const: hclk
+ - const: pclkin
+
+ resets:
+items:
+ - description: AXI
+ - description: AHB
+ - description: PCLK IN
+
+ reset-names:
+items:
+ - const: axi
+ - const: ahb
+ - const: pclkin
+
+ power-domains:
+maxItems: 1
+
+ # See ./video-interfaces.txt for details
+ port:
+type: object
+additionalProperties: false
+description: A connection to a sensor or decoder
+
+properties:
+ endpoint:
+type: object
+
+properties:
+ remote-endpoint: true
+
+required:
+ - remote-endpoint
+
+required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+vip: vip@ff49 {
+compatible = "rockchip,px30-vip";
+reg = <0x0 0xff49>, <0x0 0x200>;
+interrupts = ;
+clocks = < ACLK_CIF>, < HCLK_CIF>, < PCLK_CIF>;
+clock-names = "aclk", "hclk", "pclkin";
+resets = < SRST_CIF_A>, < SRST_CIF_H>, < SRST_CIF_PCLKIN>;
+reset-names = "axi", "ahb", "pclkin";
+power-domains = < PX30_PD_VI>;
+port {
+vip_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+...
--
2.25.4
[PATCH v5 0/3] media: rockchip: Introduce driver for Rockchip's camera interface
Hi everyone, This is the fifth iteration of the series introducing a driver for the PX30 camera interface. This was previously known as the "cif" driver in other iterations, but was renamed to "vip" following Ezequiel's advices to match the datasheet name. This is based on a BSP driver, and I'm not fully familiar with the media and V4L2 frameworks, so I guess some review is still needed. On top of the previous series, this series addresses most of the reviews by Ezequiel (Thanks again), and was tested on a PX30 chip. This Fifth iteration addresses some issues uncovered by the kbuild bot and Rob's binding_check bot. The output of v4l2-compliance for this driver is the following : # v4l2-compliance v4l2-compliance SHA: not available, 64 bits Compliance test for rk_vip device /dev/video0: Driver Info: Driver name : rk_vip Card type: rk_vip Bus info : platform:ff49.vip Driver version : 5.11.0 Capabilities : 0x84201000 Video Capture Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04201000 Video Capture Multiplanar Streaming Extended Pix Format Media Driver Info: Driver name : rk_vip Model: rk_vip Serial : Bus info : Media version: 5.11.0 Hardware revision: 0x (0) Driver version : 5.11.0 Interface Info: ID : 0x0302 Type : V4L Video Entity Info: ID : 0x0001 (1) Name : video_rkvip Function : V4L2 I/O Pad 0x0104 : 0: Sink Link 0x0209: from remote pad 0x106 of entity 'tw9900 2-0044': Data, Enabled Required ioctls: test MC information (see 'Media Driver Info' above): OK test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second /dev/video0 open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 1 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls (Input 0): test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls (Input 0): test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls (Input 0): test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls (Input 0): test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK test Requests: OK (Not Supported) Total for rk_vip device /dev/video0: 45, Succeeded: 45, Failed: 0, Warnings: 0 Once again, any review is welcome :) Thanks a lot, Maxime Maxime Chevallier (3): media: dt-bindings: media: Document Rockchip VIP bindings media: rockchip: Introduce driver for Rockhip's camera interface arm64: dts: rockchip: Add the camera interface description of the PX30 .../bindings/media/rockchip-vip.yaml | 101 ++ arch/arm64/boot/dts/rockchip/px3
[PATCH v3 1/3] dt-bindings: vendor-prefixes: Add techwell vendor prefix
Add prefix for Techwell, Inc. Acked-by: Rob Herring Signed-off-by: Maxime Chevallier --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2735be1a8470..ff65b8bff3c5 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1057,6 +1057,8 @@ patternProperties: description: TechNexion "^technologic,.*": description: Technologic Systems + "^techwell,.*": +description: Techwell, Inc. "^tempo,.*": description: Tempo Semiconductor "^techstar,.*": -- 2.25.4
[PATCH v3 3/3] media: i2c: Introduce a driver for the Techwell TW9900 decoder
The Techwell video decoder supports PAL, NTSC and SECAM input formats,
and outputs a BT.656 signal.
This commit adds support for this device, with basic support for NTSC
and PAL, along with brightness and contrast controls.
Signed-off-by: Maxime Chevallier
---
v1 -> v2: Set the media entity type to decoder, and implement the
s_std/g_std ops
V2 ->V3 : Fix coding-style issues, and remove the use of the bulk API
for regulators. Make the driver select the media-controller and
V4L2-subdev APIs.
MAINTAINERS| 6 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/tw9900.c | 617 +
4 files changed, 635 insertions(+)
create mode 100644 drivers/media/i2c/tw9900.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 281de213ef47..1031cbb5dc65 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17163,6 +17163,12 @@ L: linux-me...@vger.kernel.org
S: Maintained
F: drivers/media/rc/ttusbir.c
+TECHWELL TW9900 VIDEO DECODER
+M: Maxime Chevallier
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/i2c/tw9900.c
+
TECHWELL TW9910 VIDEO DECODER
L: linux-me...@vger.kernel.org
S: Orphan
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 878f66ef2719..53a6f1ba082e 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -426,6 +426,17 @@ config VIDEO_TW2804
To compile this driver as a module, choose M here: the
module will be called tw2804.
+config VIDEO_TW9900
+ tristate "Techwell TW9900 video decoder"
+ depends on VIDEO_V4L2 && I2C
+ select MEDIA_CONTROLLER
+ select VIDEO_V4L2_SUBDEV_API
+ help
+ Support for the Techwell tw9900 multi-standard video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9900.
+
config VIDEO_TW9903
tristate "Techwell TW9903 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f0a77473979d..cbc1d9aedd38 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
+obj-$(CONFIG_VIDEO_TW9900) += tw9900.o
obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
diff --git a/drivers/media/i2c/tw9900.c b/drivers/media/i2c/tw9900.c
new file mode 100644
index ..7bb105707060
--- /dev/null
+++ b/drivers/media/i2c/tw9900.c
@@ -0,0 +1,617 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the Techwell TW9900 multi-standard video decoder.
+ *
+ * Copyright (C) 2018 Fuzhou Rockchip Electronics Co., Ltd.
+ * Copyright (C) 2020 Maxime Chevallier
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TW9900_REG_CHIP_ID 0x00
+#define TW9900_REG_CHIP_STATUS 0x01
+#define TW9900_REG_CHIP_STATUS_VLOCK 0x08
+#define TW9900_REG_CHIP_STATUS_VDLOSS 0x80
+#define TW9900_REG_OUT_FMT_CTL 0x03
+#define TW9900_REG_OUT_FMT_CTL_STANDBY 0xA7
+#define TW9900_REG_OUT_FMT_CTL_STREAMING 0xA0
+#define TW9900_REG_CKHY_HSDLY 0x04
+#define TW9900_REG_OUT_CTRL_I 0x05
+#define TW9900_REG_ANALOG_CTL 0x06
+#define TW9900_REG_CROP_HI 0x07
+#define TW9900_REG_VDELAY_LO 0x08
+#define TW9900_REG_VACTIVE_LO 0x09
+#define TW9900_REG_HACTIVE_LO 0x0B
+#define TW9900_REG_CNTRL1 0x0C
+#define TW9900_REG_BRIGHT_CTL 0x10
+#define TW9900_REG_CONTRAST_CTL0x11
+#define TW9900_REG_VBI_CNTL0x19
+#define TW9900_REG_ANAL_CTL_II 0x1A
+#define TW9900_REG_OUT_CTRL_II 0x1B
+#define TW9900_REG_STD_SEL 0x1C
+#define TW9900_REG_MISSCNT 0x26
+#define TW9900_REG_MISC_CTL_II 0x2F
+#define TW9900_REG_VVBI0x55
+
+#define TW9900_CHIP_ID 0x00
+
+#define VSYNC_POLL_INTERVAL_MS 20
+#define VSYNC_WAIT_MAX_POLLS 50
+
+struct regval {
+ u8 addr;
+ u8 val;
+};
+
+struct tw9900_mode {
+ u32 width;
+ u32 height;
+ u32 skip_top;
+ u32 std;
+ u32 field;
+ const struct regval *reg_list;
+ int n_regs;
+};
+
+struct tw9900 {
+ struct i2c_client *client;
+ struct gpio_desc *reset_gpio;
+ struct regulator *regulator;
+
+ bool streaming;
+
+ struct v4l2_subdev subdev;
+ struct v4l2_ctrl_handler hdl;
+ struct media_pad pad;
+
+ struct timer_list timer;
+ struct work_struct work_i2c_poll;
+
+ const struct tw9900_mode *cur_mode;
+};
+
+#define to_tw9900(sd) container_of(sd, struct tw9900, subdev)
+
+static const struct regval tw9900_init_regs[] = {
+ { TW9900_REG_MISC_CTL_II,
[PATCH v3 2/3] media: dt-bindings: media: i2c: Add bindings for TW9900
The Techwell TW9900 is a video decoder supporting multiple input
standards, such as PAL, NTSC and SECAM, and outputs a BT.656 video
signal.
It's designed to be low-power, posesses some features such as a
programmable comb-filter, and automatic input standard detection.
Signed-off-by: Maxime Chevallier
---
V2->V3 : Fix the example not compiling due to a typo in the reset-gpios
node.
.../devicetree/bindings/media/i2c/tw9900.yaml | 60 +++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tw9900.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
b/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
new file mode 100644
index ..91eff26668fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/tw9900.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Techwell TW9900 NTSC/PAL/SECAM video decoder
+
+maintainers:
+ - Maxime Chevallier
+
+description:
+ The tw9900 is a multi-standard video decoder, supporting NTSC, PAL and SECAM
+ standards with auto-detection features.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - techwell,tw9900
+
+ reg:
+maxItems: 1
+
+ vdd-supply:
+description: VDD power supply
+
+ port:
+type: object
+description:
+ A node containing a single endpoint as doucmented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+tw9900: tw9900@44 {
+compatible = "techwell,tw9900";
+reg = <0x44>;
+
+vdd-supply = <_supply>;
+reset-gpios = < 5 GPIO_ACTIVE_LOW>;
+
+port {
+tw9900_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
--
2.25.4
[PATCH v3 0/3] media: i2c: Introduce driver for the TW9900 decoder
Hello everyone, This is the third version of the series adding support for the Techwell TW9900 multi standard decoder. It's a pretty simple decoder compared to the TW9910, since it doesn't have a built-in scaler/crop engine. This V3 addresses coding-style issues reported by Paul, and fixes the example binding. Any feedback is appreciated, Thanks, Maxime Maxime Chevallier (3): dt-bindings: vendor-prefixes: Add techwell vendor prefix media: dt-bindings: media: i2c: Add bindings for TW9900 media: i2c: Introduce a driver for the Techwell TW9900 decoder .../devicetree/bindings/media/i2c/tw9900.yaml | 60 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile| 1 + drivers/media/i2c/tw9900.c| 617 ++ 6 files changed, 697 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/tw9900.yaml create mode 100644 drivers/media/i2c/tw9900.c -- 2.25.4
[PATCH v4 2/3] media: rockchip: Introduce driver for Rockhip's camera interface
Introduce a driver for the camera interface on some Rockchip platforms.
This controller supports CSI2 and BT656 interfaces, but for
now only the BT656 interface could be tested, hence it's the only one
that's supported in the first version of this driver.
This controller can be fond on PX30, RK1808, RK3128, RK3288 and RK3288,
but for now it's only be tested on PX30.
Most of this driver was written following the BSP driver from rockchip,
removing the parts that either didn't fit correctly the guidelines, or
that couldn't be tested.
In the BSP, this driver is known as the "cif" driver, but this was
renamed to "vip" to better fit the controller denomination in the
datasheet.
This basic version doesn't support cropping nor scaling, and is only
designed with one sensor being attached to it a any time.
This version uses the "pingpong" mode of the controller, which is a
double-buffering mechanism.
Signed-off-by: Maxime Chevallier
---
V3:
- renamed the driver
- Took Hans, Robin and Ezequiel's reviews into account
- Implemented the ouble-buffering mode
v4:
- Took Ezequiel's reviews into account
- Reworked the imagesize computation
- Fixed the bulk API use for clks and rsts
drivers/media/platform/Kconfig| 15 +
drivers/media/platform/Makefile |1 +
drivers/media/platform/rockchip/vip/Makefile |3 +
drivers/media/platform/rockchip/vip/capture.c | 1148 +
drivers/media/platform/rockchip/vip/dev.c | 333 +
drivers/media/platform/rockchip/vip/dev.h | 203 +++
drivers/media/platform/rockchip/vip/regs.h| 260
7 files changed, 1963 insertions(+)
create mode 100644 drivers/media/platform/rockchip/vip/Makefile
create mode 100644 drivers/media/platform/rockchip/vip/capture.c
create mode 100644 drivers/media/platform/rockchip/vip/dev.c
create mode 100644 drivers/media/platform/rockchip/vip/dev.h
create mode 100644 drivers/media/platform/rockchip/vip/regs.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index a3cb104956d5..dbbf59e119c0 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -462,6 +462,21 @@ config VIDEO_ROCKCHIP_RGA
To compile this driver as a module choose m here.
+config VIDEO_ROCKCHIP_VIP
+ tristate "Rockchip VIP (Video InPut) Camera Interface"
+ depends on VIDEO_DEV && VIDEO_V4L2
+ depends on ARCH_ROCKCHIP || COMPILE_TEST
+ select VIDEOBUF2_DMA_SG
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_FWNODE
+ select V4L2_MEM2MEM_DEV
+ help
+ This is a v4l2 driver for Rockchip SOC Camera interface. It supports
+ BT.656 and CSI2 inputs.
+
+ To compile this driver as a module choose m here : the module will
+ be called video_rkvip.
+
config VIDEO_TI_VPE
tristate "TI VPE (Video Processing Engine) driver"
depends on VIDEO_DEV && VIDEO_V4L2
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 62b6cdc8c730..d056f5618c2b 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o
obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip/rga/
+obj-$(CONFIG_VIDEO_ROCKCHIP_VIP) += rockchip/vip/
obj-y += omap/
diff --git a/drivers/media/platform/rockchip/vip/Makefile
b/drivers/media/platform/rockchip/vip/Makefile
new file mode 100644
index ..c239ee0bb0fe
--- /dev/null
+++ b/drivers/media/platform/rockchip/vip/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_VIDEO_ROCKCHIP_VIP) += video_rkvip.o
+video_rkvip-objs += dev.o capture.o
diff --git a/drivers/media/platform/rockchip/vip/capture.c
b/drivers/media/platform/rockchip/vip/capture.c
new file mode 100644
index ..b2f22643704c
--- /dev/null
+++ b/drivers/media/platform/rockchip/vip/capture.c
@@ -0,0 +1,1148 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockchip VIP Camera Interface Driver
+ *
+ * Copyright (C) 2018 Rockchip Electronics Co., Ltd.
+ * Copyright (C) 2020 Maxime Chevallier
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dev.h"
+#include "regs.h"
+
+#define VIP_REQ_BUFS_MIN 3
+#define VIP_MIN_WIDTH 64
+#define VIP_MIN_HEIGHT 64
+#define VIP_MAX_WIDTH 8192
+#define VIP_MAX_HEIGHT 8192
+
+#define RK_VIP_PLANE_Y 0
+#define RK_VIP_PLANE_CBCR 1
+
+#define VIP_FETCH_Y_LAST_LINE(VAL) ((VAL) & 0x1fff)
+/* Check if swap y and c in bt1120 mode */
+#define VIP_FETCH_IS_Y_FIRST(VAL) ((VAL) & 0xf)
+
+static const struct vip_output_fmt out_fmts[] = {
+ {
+
[PATCH v4 3/3] arm64: dts: rockchip: Add the camera interface description of the PX30
The PX30 has a camera interface, supporting CSI2 and BT656
modes. Add a DT description for this interface.
Signed-off-by: Maxime Chevallier
---
V3 : Renamed the controlled
V4: Fixed the clock names
arch/arm64/boot/dts/rockchip/px30.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 2695ea8cda14..39987afe5ed5 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1106,6 +1106,18 @@ vopl_mmu: iommu@ff470f00 {
status = "disabled";
};
+ vip: vip@ff49 {
+ compatible = "rockchip,px30-vip";
+ reg = <0x0 0xff49 0x0 0x200>;
+ interrupts = ;
+ clocks = < ACLK_CIF>, < HCLK_CIF>, < PCLK_CIF>,
< SCLK_CIF_OUT>;
+ clock-names = "aclk", "hclk", "pclk";
+ power-domains = < PX30_PD_VI>;
+ resets = < SRST_CIF_A>, < SRST_CIF_H>, <
SRST_CIF_PCLKIN>;
+ reset-names = "axi", "ahb", "pclkin";
+ status = "disabled";
+ };
+
qos_gmac: qos@ff518000 {
compatible = "syscon";
reg = <0x0 0xff518000 0x0 0x20>;
--
2.25.4
[PATCH v4 1/3] media: dt-bindings: media: Document Rockchip VIP bindings
Add a documentation for the Rockchip Camera Interface controller
binding.
This controller can be found on platforms such as the PX30 or the
RK3288, the PX30 being the only platform supported so far.
Signed-off-by: Maxime Chevallier
---
v3: Renmed the controller to "vip"
v4: fixed the binding to get a compiling example
.../bindings/media/rockchip-vip.yaml | 94 +++
1 file changed, 94 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rockchip-vip.yaml
diff --git a/Documentation/devicetree/bindings/media/rockchip-vip.yaml
b/Documentation/devicetree/bindings/media/rockchip-vip.yaml
new file mode 100644
index ..268dbc7662bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-vip.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/rockchip-vip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip VIP Camera Interface
+
+maintainers:
+ - Maxime Chevallier
+
+description: |-
+ Camera Interface for Rockcip platforms
+
+properties:
+ compatible:
+const: rockchip,px30-vip
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: ACLK
+ - description: HCLK
+ - description: PCLK IN
+
+ clock-names:
+items:
+ - const: aclk
+ - const: hclkf
+ - const: pclkin
+
+ resets:
+items:
+ - description: AXI
+ - description: AHB
+ - description: PCLK IN
+
+ reset-names:
+items:
+ - const: axi
+ - const: ahb
+ - const: pclkin
+
+ power-domains:
+maxItems: 1
+
+ # See ./video-interfaces.txt for details
+ port:
+type: object
+additionalProperties: false
+description: A connection to a sensor or decoder
+
+properties:
+remote-endpoint: true
+
+required:
+ - remote-endpoint
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+vip: vip@ff49 {
+ compatible = "rockchip,px30-vip";
+ reg = <0x0 0xff49 0x0 0x200>;
+ interrupts = ;
+ clocks = < ACLK_CIF>, < HCLK_CIF>, < PCLK_CIF>, <
SCLK_CIF_OUT>;
+ clock-names = "aclk", "hclk", "pclkin";
+ resets = < SRST_CIF_A>, < SRST_CIF_H>, < SRST_CIF_PCLKIN>;
+ reset-names = "axi", "ahb", "pclkin";
+ power-domains = < PX30_PD_VI>;
+port {
+vip_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+...
--
2.25.4
[PATCH v4 0/3] media: rockchip: Introduce driver for Rockchip's camera interface
Hi everyone, This is the fourth iteration of the series introducing a driver for the PX30 camera interface. This was previously known as the "cif" driver in other iterations, but was renamed to "vip" following Ezequiel's advices to match the datasheet name. This is based on a BSP driver, and I'm not fully familiar with the media and V4L2 frameworks, so I guess some review is still needed. On top of the previous series, this series addresses most of the reviews by Ezequiel (Thanks again), and was tested on a PX30 chip. Maxime Maxime Chevallier (3): media: dt-bindings: media: Document Rockchip VIP bindings media: rockchip: Introduce driver for Rockhip's camera interface arm64: dts: rockchip: Add the camera interface description of the PX30 .../bindings/media/rockchip-vip.yaml | 94 ++ arch/arm64/boot/dts/rockchip/px30.dtsi| 12 + drivers/media/platform/Kconfig| 15 + drivers/media/platform/Makefile |1 + drivers/media/platform/rockchip/vip/Makefile |3 + drivers/media/platform/rockchip/vip/capture.c | 1148 + drivers/media/platform/rockchip/vip/dev.c | 333 + drivers/media/platform/rockchip/vip/dev.h | 203 +++ drivers/media/platform/rockchip/vip/regs.h| 260 9 files changed, 2069 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/rockchip-vip.yaml create mode 100644 drivers/media/platform/rockchip/vip/Makefile create mode 100644 drivers/media/platform/rockchip/vip/capture.c create mode 100644 drivers/media/platform/rockchip/vip/dev.c create mode 100644 drivers/media/platform/rockchip/vip/dev.h create mode 100644 drivers/media/platform/rockchip/vip/regs.h -- 2.25.4
Re: [PATCH v3 2/3] media: rockchip: Introduce driver for Rockhip's camera interface
t; + vb_done->vb2_buf.timestamp = ktime_get_ns();
>
>vb_done->vb2_buf.sequence = stream->frame_idx; ?
Good catch, thanks !
>> + vb2_buffer_done(_done->vb2_buf, VB2_BUF_STATE_DONE);
>> +}
>> +
[...]
>> diff --git a/drivers/media/platform/rockchip/vip/dev.c
>> b/drivers/media/platform/rockchip/vip/dev.c
>> new file mode 100644
>> index ..d9b64f088c37
>> --- /dev/null
>> +++ b/drivers/media/platform/rockchip/vip/dev.c
>> @@ -0,0 +1,408 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Rockchip VIP Camera Interface Driver
>> + *
>> + * Copyright (C) 2018 Rockchip Electronics Co., Ltd.
>> + * Copyright (C) 2020 Maxime Chevallier
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "dev.h"
>> +#include "regs.h"
>> +
>> +#define RK_VIP_VERNO_LEN 10
>> +
[...]
>> +static const char * const px30_vip_clks[] = {
>> + "aclk_vip",
>> + "hclk_vip",
>> + "pclk_vip",
>> + "vip_out",
>
>These clock names don't seem to match with the devicetree.
>I wonder how have you been testing this, to be honest ^_^ ?
>
>Isn't probe failing with mismatching clock names?
Aw you're correct, the change was in my tree but wasn't commited, my
bad. Sorry about that.
>> +};
>> +
>> +static const char * const px30_vip_rsts[] = {
>> + "rst_vip_a",
>> + "rst_vip_h",
>> + "rst_vip_pclkin",
>> +};
>> +
>> +static const struct vip_match_data px30_vip_match_data = {
>> + .chip_id = CHIP_PX30_VIP,
>> + .clks = px30_vip_clks,
>> + .clks_num = ARRAY_SIZE(px30_vip_clks),
>> + .rsts = px30_vip_rsts,
>> + .rsts_num = ARRAY_SIZE(px30_vip_rsts),
>> +};
>> +
>> +static const struct of_device_id rk_vip_plat_of_match[] = {
>> + {
>> + .compatible = "rockchip,px30-vip",
>> + .data = _vip_match_data,
>> + },
>> + {},
>> +};
>> +
>> +static irqreturn_t rk_vip_irq_handler(int irq, void *ctx)
>> +{
>> + struct device *dev = ctx;
>> + struct rk_vip_device *vip_dev = dev_get_drvdata(dev);
>> +
>> + rk_vip_irq_pingpong(vip_dev);
>> +
>
>Why not just making rk_vip_irq_pingpong the interrupt handler?
You're also correct, this is a remaining piece of code from when both
single-buffer and double-buffer'd acquisition were coexisting.
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static void rk_vip_disable_sys_clk(struct rk_vip_device *vip_dev)
>> +{
>> + int i;
>> +
>> + for (i = vip_dev->clk_size - 1; i >= 0; i--)
>> + clk_disable_unprepare(vip_dev->clks[i]);
>
>Please use clk_bulk_disable_unprepare.
>> +}
>> +
>> +static int rk_vip_enable_sys_clk(struct rk_vip_device *vip_dev)
>> +{
>> + int i, ret = -EINVAL;
>> +
>> + for (i = 0; i < vip_dev->clk_size; i++) {
>> + ret = clk_prepare_enable(vip_dev->clks[i]);
>> +
>
>Please use clk_bulk_prepare_enable.
I'll switch to that, thanks
[...]
>> + ret = of_reserved_mem_device_init(dev);
>> + if (ret)
>> + v4l2_warn(v4l2_dev, "No reserved memory region assign to
>> VIP\n");
>> +
>
>How about
>
>ret = of_reserved_mem_device_init(dev);
>if (ret && ret != -ENODEV)
>return ret;
>
>instead?
>
>Also, it seems you are missing a of_reserved_mem_device_release
>on the error paths and plat_remove.
You're correct, I'll add that.
Thanks again for the thourough review !
Maxime
>Thanks,
>Ezequiel
[PATCH v2 0/3] media: i2c: Introduce driver for the TW9900 decoder
Hello everyone, This is the second version of the series adding support for the Techwell TW9900 multi standard decoder. It's a pretty simple decoder compared to the TW9910, since it doesn't have a built-in scaler/crop engine. Since V2, I've fixed a few issues with the binding, and changed the media entity type from sensor to decoder following Hans' review. Any feedback is appreciated, Thanks, Maxime Maxime Chevallier (3): dt-bindings: vendor-prefixes: Add techwell vendor prefix media: dt-bindings: media: i2c: Add bindings for TW9900 media: i2c: Introduce a driver for the Techwell TW9900 decoder .../devicetree/bindings/media/i2c/tw9900.yaml | 60 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 6 + drivers/media/i2c/Kconfig | 9 + drivers/media/i2c/Makefile| 1 + drivers/media/i2c/tw9900.c| 661 ++ 6 files changed, 739 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/tw9900.yaml create mode 100644 drivers/media/i2c/tw9900.c -- 2.25.4
[PATCH v2 3/3] media: i2c: Introduce a driver for the Techwell TW9900 decoder
The Techwell video decoder supports PAL, NTSC and SECAM input formats,
and outputs a BT.656 signal.
This commit adds support for this device, with basic support for NTSC
and PAL, along with brightness and contrast controls.
Signed-off-by: Maxime Chevallier
---
v1 -> v2: Set the media entity type to decoder, and implement the
s_std/g_std ops
MAINTAINERS| 6 +
drivers/media/i2c/Kconfig | 9 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/tw9900.c | 661 +
4 files changed, 677 insertions(+)
create mode 100644 drivers/media/i2c/tw9900.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 3da6d8c154e4..2890862a8285 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17160,6 +17160,12 @@ L: linux-me...@vger.kernel.org
S: Maintained
F: drivers/media/rc/ttusbir.c
+TECHWELL TW9900 VIDEO DECODER
+M: Maxime Chevallier
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/i2c/tw9900.c
+
TECHWELL TW9910 VIDEO DECODER
L: linux-me...@vger.kernel.org
S: Orphan
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 878f66ef2719..ea55aea4d949 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -426,6 +426,15 @@ config VIDEO_TW2804
To compile this driver as a module, choose M here: the
module will be called tw2804.
+config VIDEO_TW9900
+ tristate "Techwell TW9900 video decoder"
+ depends on VIDEO_V4L2 && I2C
+ help
+ Support for the Techwell tw9900 multi-standard video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9900.
+
config VIDEO_TW9903
tristate "Techwell TW9903 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f0a77473979d..cbc1d9aedd38 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
+obj-$(CONFIG_VIDEO_TW9900) += tw9900.o
obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
diff --git a/drivers/media/i2c/tw9900.c b/drivers/media/i2c/tw9900.c
new file mode 100644
index ..2075c3c120af
--- /dev/null
+++ b/drivers/media/i2c/tw9900.c
@@ -0,0 +1,661 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the Techwell TW9900 multi-standard video decoder.
+ *
+ * Copyright (C) 2018 Fuzhou Rockchip Electronics Co., Ltd.
+ * Copyright (C) 2020 Maxime Chevallier
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TW9900_REG_CHIP_ID 0x00
+#define TW9900_REG_CHIP_STATUS 0x01
+#defineTW9900_REG_CHIP_STATUS_VLOCK0x08
+#defineTW9900_REG_CHIP_STATUS_VDLOSS 0x80
+#define TW9900_REG_OUT_FMT_CTL 0x03
+#define TW9900_REG_CKHY_HSDLY 0x04
+#define TW9900_REG_OUT_CTRL_I 0x05
+#define TW9900_REG_ANALOG_CTL 0x06
+#define TW9900_REG_CROP_HI 0x07
+#define TW9900_REG_VDELAY_LO0x08
+#define TW9900_REG_VACTIVE_LO 0x09
+#define TW9900_REG_HACTIVE_LO 0x0B
+#define TW9900_REG_CNTRL1 0x0C
+#define TW9900_REG_BRIGHT_CTL 0x10
+#define TW9900_REG_CONTRAST_CTL 0x11
+#define TW9900_REG_VBI_CNTL0x19
+#define TW9900_REG_ANAL_CTL_II 0x1A
+#define TW9900_REG_OUT_CTRL_II 0x1B
+#define TW9900_REG_STD_SEL 0x1C
+#define TW9900_REG_MISSCNT 0x26
+#define TW9900_REG_MISC_CTL_II 0x2F
+#define TW9900_REG_VVBI 0x55
+
+#define TW9900_CHIP_ID 0x00
+
+#define REG_SC_CTRL_MODE TW9900_REG_OUT_FMT_CTL
+#define SC_CTRL_MODE_STANDBY 0xA7
+#define SC_CTRL_MODE_STREAMING 0xA0
+
+#define REG_NULL 0xFF
+
+#define VSYNC_POLL_INTERVAL_MS 20
+#define VSYNC_WAIT_MAX_POLLS50
+
+static const char * const tw9900_supply_names[] = {
+ "vdd",
+};
+
+#define TW9900_NUM_SUPPLIES ARRAY_SIZE(tw9900_supply_names)
+
+struct regval {
+ u8 addr;
+ u8 val;
+};
+
+struct tw9900_mode {
+ u32 width;
+ u32 height;
+ u32 skip_top;
+ u32 std;
+ u32 field;
+ const struct regval *reg_list;
+};
+
+struct tw9900 {
+ struct i2c_client *client;
+ struct gpio_desc*reset_gpio;
+ struct regulator_bulk_data supplies[TW9900_NUM_SUPPLIES];
+
+ boolstreaming;
+
+ struct v4l2_subdev subdev;
+ struct v4l2_ctrl_handler hdl;
+ struct media_padpad;
+
+ struct timer_list timer;
+ struct work_struct work_i2c_poll;
+
+ const struct tw9900_mode *cur_mode;
+};
+
+#define to_tw9900(sd) container_of(sd, str
[PATCH v2 2/3] media: dt-bindings: media: i2c: Add bindings for TW9900
The Techwell TW9900 is a video decoder supporting multiple input
standards, such as PAL, NTSC and SECAM, and outputs a BT.656 video
signal.
It's designed to be low-power, posesses some features such as a
programmable comb-filter, and automatic input standard detection.
Signed-off-by: Maxime Chevallier
---
v1->v2: Fix the example not compiling
.../devicetree/bindings/media/i2c/tw9900.yaml | 60 +++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tw9900.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
b/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
new file mode 100644
index ..fa7e237ca7a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/tw9900.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Techwell TW9900 NTSC/PAL/SECAM video decoder
+
+maintainers:
+ - Maxime Chevallier
+
+description:
+ The tw9900 is a multi-standard video decoder, supporting NTSC, PAL and SECAM
+ standards with auto-detection features.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - techwell,tw9900
+
+ reg:
+maxItems: 1
+
+ vdd-supply:
+description: VDD power supply
+
+ port:
+type: object
+description:
+ A node containing a single endpoint as doucmented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+tw9900: tw9900@44 {
+compatible = "techwell,tw9900";
+reg = <0x44>;
+
+vdd-supply = <_supply>;
+reset-gpio = < 5 GPIO_ACTIVE_LOW>;
+
+port {
+tw9900_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
--
2.25.4
[PATCH v2 1/3] dt-bindings: vendor-prefixes: Add techwell vendor prefix
Add prefix for Techwell, Inc. Acked-by: Rob Herring Signed-off-by: Maxime Chevallier --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2735be1a8470..ff65b8bff3c5 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1057,6 +1057,8 @@ patternProperties: description: TechNexion "^technologic,.*": description: Technologic Systems + "^techwell,.*": +description: Techwell, Inc. "^tempo,.*": description: Tempo Semiconductor "^techstar,.*": -- 2.25.4
Re: [PATCH 3/3] media: i2c: Introduce a driver for the Techwell TW9900 decoder
Hi Hans,
On Fri, 25 Sep 2020 14:52:25 +0200
Hans Verkuil wrote:
>Hi Maxime,
>
>Some comments below, this driver needs to be changed:
Thanks for the review !
>On 18/09/2020 16:24, Maxime Chevallier wrote:
>> The Techwell video decoder supports PAL, NTSC and SECAM input formats,
>> and outputs a BT.656 signal.
>>
>> This commit adds support for this device, based on an implementation
>> made by Rockchip. This implemention adds basic support for NTSC and PAL,
>> and some basic brightness and contrast controls.
>>
>> Signed-off-by: Maxime Chevallier
[ ... ]
>> +static const struct v4l2_subdev_ops tw9900_subdev_ops = {
>> +.core = _core_ops,
>> +.video = _video_ops,
>> +.pad= _pad_ops,
>> +.sensor = _sensor_ops,
>> +};
>
>This is wrong. This is not a sensor, so you don't set the format, instead
>you set the TV standard (s_std).
>
>drivers/media/i2c/tw9910.c is a fairly OK template to use. The tw9910 supports
>a simple scaler as well, but I don't know if the tw9900 has the same feature.
>If not, then the format resolution is fixed based on the current selected
>TV standard.
>
>There is definitely no need for g_skip_top_lines: 1) it's a sensor-only op,
>and 2) that function always returns 0, so why keep it?
Thanks for the clarification. Indeed the TW9900 is simpler and doesn't
have a scaler. I'll stick to the s_std / g_std ops then.
I'll also change the denomination from "sensor" to "decoder", you're
right.
>> +
>> +static const struct v4l2_ctrl_ops tw9900_ctrl_ops = {
>> +.s_ctrl = tw9900_s_ctrl,
>> +};
>> +
>> +#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
>> +static const struct v4l2_subdev_internal_ops tw9900_internal_ops = {
>> +.open = tw9900_open,
>> +};
>> +#endif
>> +
>> +static int tw9900_check_sensor_id(struct tw9900 *tw9900,
>
>*Not* a sensor :-)
>
>> + struct i2c_client *client)
>> +{
>> +struct device *dev = >client->dev;
>> +u8 id;
>> +
>> +id = tw9900_read_reg(client, TW9900_CHIP_ID);
>> +
>> +if (id != TW9900_CHIP_ID) {
>> +dev_err(dev, "Wrong camera sensor id(%04x)\n", id);
>> +return -EINVAL;
>> +}
>> +
>> +dev_info(dev, "Detected TW9900 (%04x) sensor\n", TW9900_CHIP_ID);
>> +
>> +return 0;
>> +}
>> +
>> +static int tw9900_configure_regulators(struct tw9900 *tw9900)
>> +{
>> +u32 i;
>> +
>> +for (i = 0; i < TW9900_NUM_SUPPLIES; i++)
>> +tw9900->supplies[i].supply = tw9900_supply_names[i];
>> +
>> +return devm_regulator_bulk_get(>client->dev,
>> + TW9900_NUM_SUPPLIES,
>> + tw9900->supplies);
>> +}
>> +
>> +static int tw9900_probe(struct i2c_client *client,
>> +const struct i2c_device_id *id)
>> +{
>> +struct device *dev = >dev;
>> +struct v4l2_ctrl_handler *hdl;
>> +struct tw9900 *tw9900;
>> +int ret;
>> +
>> +tw9900 = devm_kzalloc(dev, sizeof(*tw9900), GFP_KERNEL);
>> +if (!tw9900)
>> +return -ENOMEM;
>> +
>> +tw9900->client = client;
>> +tw9900->cur_mode = _modes[0];
>> +
>> +tw9900->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
>> +if (IS_ERR(tw9900->reset_gpio))
>> +tw9900->reset_gpio = NULL;
>> +
>> +ret = tw9900_configure_regulators(tw9900);
>> +if (ret) {
>> +dev_err(dev, "Failed to get power regulators\n");
>> +return ret;
>> +}
>> +
>> +v4l2_i2c_subdev_init(>subdev, client, _subdev_ops);
>> +tw9900->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE |
>> V4L2_SUBDEV_FL_HAS_EVENTS;
>> +
>> +hdl = >hdl;
>> +
>> +v4l2_ctrl_handler_init(hdl, 2);
>> +
>> +v4l2_ctrl_new_std(hdl, _ctrl_ops, V4L2_CID_BRIGHTNESS,
>> + -128, 127, 1, 0);
>> +v4l2_ctrl_new_std(hdl, _ctrl_ops, V4L2_CID_CONTRAST,
>> + 0, 255, 1, 0x60);
>> +
>> +tw9900->subdev.ctrl_handler = hdl;
>> +if (hdl->error) {
>> +int err = hdl->error;
>> +
>> +v4l2_ctrl_handler_free(hdl);
>> +return err;
>> +}
>> +
>> +ret = __tw9900_power_on(tw9900);
>> +if (ret)
>> +return ret;
>> +
>> +ret = tw9900_check_sensor_id(tw9900, client);
>> +if (ret)
>> +goto err_power_off;
>> +
>> +#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
>> +tw9900->subdev.internal_ops = _internal_ops;
>> +tw9900->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>> +#endif
>> +#if defined(CONFIG_MEDIA_CONTROLLER)
>> +tw9900->pad.flags = MEDIA_PAD_FL_SOURCE;
>> +tw9900->subdev.entity.function = MEDIA_ENT_F_CAM_SENSOR;
>
>Set to MEDIA_ENT_F_ATV_DECODER.
Will do ! Thanks agains,
Maxime
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[PATCH v3 1/3] media: dt-bindings: media: Document Rockchip VIP bindings
Add a documentation for the Rockchip Camera Interface controller
binding.
This controller can be found on platforms such as the PX30 or the
RK3288, the PX30 being the only platform supported so far.
Signed-off-by: Maxime Chevallier
---
V3 :
- renamed the controller
.../bindings/media/rockchip-vip.yaml | 100 ++
1 file changed, 100 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rockchip-vip.yaml
diff --git a/Documentation/devicetree/bindings/media/rockchip-vip.yaml
b/Documentation/devicetree/bindings/media/rockchip-vip.yaml
new file mode 100644
index ..652c46053b29
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-vip.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/rockchip-vip.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip VIP Camera Interface
+
+maintainers:
+ - Maxime Chevallier
+
+description: |-
+ Camera Interface for Rockcip platforms
+
+properties:
+ compatible:
+const: rockchip,px30-vip
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: ACLK
+ - description: HCLK
+ - description: PCLK IN
+
+ clock-names:
+items:
+ - const: aclk
+ - const: hclkf
+ - const: pclkin
+
+ resets:
+items:
+ - description: AXI
+ - description: AHB
+ - description: PCLK IN
+
+ reset-names:
+items:
+ - const: axi
+ - const: ahb
+ - const: pclkin
+
+ power-domains:
+maxItems: 1
+description: phandle to the associated power domain
+
+ # See ./video-interfaces.txt for details
+ port:
+type: object
+additionalProperties: false
+
+properties:
+ endpoint:
+type: object
+
+properties:
+ remote-endpoint: true
+
+required:
+ - remote-endpoint
+
+required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+vip: vip@ff49 {
+ compatible = "rockchip,px30-vip";
+ reg = <0x0 0xff49 0x0 0x200>;
+ interrupts = ;
+ clocks = < ACLK_CIF>, < HCLK_CIF>, < PCLK_CIF>, <
SCLK_CIF_OUT>;
+ clock-names = "aclk", "hclk", "pclkin";
+ resets = < SRST_CIF_A>, < SRST_CIF_H>, < SRST_CIF_PCLKIN>;
+ reset-names = "axi", "ahb", "pclkin";
+ power-domains = < PX30_PD_VI>;
+port {
+vip_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+...
--
2.25.4
[PATCH v3 2/3] media: rockchip: Introduce driver for Rockhip's camera interface
Introduce a driver for the camera interface on some Rockchip platforms.
This controller supports CSI2 and BT656 interfaces, but for
now only the BT656 interface could be tested, hence it's the only one
that's supported in the first version of this driver.
This controller can be fond on PX30, RK1808, RK3128, RK3288 and RK3288,
but for now it's only be tested on PX30.
Most of this driver was written following the BSP driver from rockchip,
removing the parts that either didn't fit correctly the guidelines, or
that couldn't be tested.
In the BSP, this driver is known as the "cif" driver, but this was
renamed to "vip" to better fit the controller denomination in the
datasheet.
This basic version doesn't support cropping nor scaling, and is only
designed with one sensor being attached to it a any time.
This version uses the "pingpong" mode of the controller, which is a
double-buffering mechanism.
Signed-off-by: Maxime Chevallier
---
V3:
- renamed the driver
- Took Hans, Robin and Ezequiel's reviews into account
- Implemented the ouble-buffering mode
drivers/media/platform/Kconfig| 13 +
drivers/media/platform/Makefile |1 +
drivers/media/platform/rockchip/vip/Makefile |3 +
drivers/media/platform/rockchip/vip/capture.c | 1246 +
drivers/media/platform/rockchip/vip/dev.c | 408 ++
drivers/media/platform/rockchip/vip/dev.h | 206 +++
drivers/media/platform/rockchip/vip/regs.h| 260
7 files changed, 2137 insertions(+)
create mode 100644 drivers/media/platform/rockchip/vip/Makefile
create mode 100644 drivers/media/platform/rockchip/vip/capture.c
create mode 100644 drivers/media/platform/rockchip/vip/dev.c
create mode 100644 drivers/media/platform/rockchip/vip/dev.h
create mode 100644 drivers/media/platform/rockchip/vip/regs.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c57ee78fa99d..5bc67a0bdd69 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -461,6 +461,19 @@ config VIDEO_ROCKCHIP_RGA
To compile this driver as a module choose m here.
+config VIDEO_ROCKCHIP_VIP
+ tristate "Rockchip VIP (Video InPut) Camera Interface"
+ depends on VIDEO_DEV && VIDEO_V4L2
+ depends on ARCH_ROCKCHIP || COMPILE_TEST
+ select VIDEOBUF2_DMA_SG
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_FWNODE
+ select V4L2_MEM2MEM_DEV
+ help
+ This is a v4l2 driver for Rockchip SOC Camera interface.
+
+ To compile this driver as a module choose m here.
+
config VIDEO_TI_VPE
tristate "TI VPE (Video Processing Engine) driver"
depends on VIDEO_DEV && VIDEO_V4L2
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 62b6cdc8c730..d056f5618c2b 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o
obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip/rga/
+obj-$(CONFIG_VIDEO_ROCKCHIP_VIP) += rockchip/vip/
obj-y += omap/
diff --git a/drivers/media/platform/rockchip/vip/Makefile
b/drivers/media/platform/rockchip/vip/Makefile
new file mode 100644
index ..c239ee0bb0fe
--- /dev/null
+++ b/drivers/media/platform/rockchip/vip/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_VIDEO_ROCKCHIP_VIP) += video_rkvip.o
+video_rkvip-objs += dev.o capture.o
diff --git a/drivers/media/platform/rockchip/vip/capture.c
b/drivers/media/platform/rockchip/vip/capture.c
new file mode 100644
index ..6f8e1184695c
--- /dev/null
+++ b/drivers/media/platform/rockchip/vip/capture.c
@@ -0,0 +1,1246 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Rockchip VIP Camera Interface Driver
+ *
+ * Copyright (C) 2018 Rockchip Electronics Co., Ltd.
+ * Copyright (C) 2020 Maxime Chevallier
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dev.h"
+#include "regs.h"
+
+#define VIP_REQ_BUFS_MIN 1
+#define VIP_MIN_WIDTH 64
+#define VIP_MIN_HEIGHT 64
+#define VIP_MAX_WIDTH 8192
+#define VIP_MAX_HEIGHT 8192
+
+#define RK_VIP_PLANE_Y 0
+#define RK_VIP_PLANE_CBCR 1
+
+#define VIP_FETCH_Y_LAST_LINE(VAL) ((VAL) & 0x1fff)
+/* Check if swap y and c in bt1120 mode */
+#define VIP_FETCH_IS_Y_FIRST(VAL) ((VAL) & 0xf)
+
+/* Get xsubs and ysubs for fourcc formats
+ *
+ * @xsubs: horizontal color samples in a 4*4 matrix, for yuv
+ * @ysubs: vertical color samples in a 4*4 matrix, for yuv
+ */
+static int fcc_xysubs(u32 fcc, u32 *xsubs, u32 *ysubs)
+{
+ switch (fcc) {
+ case V4L2_PIX_FMT_NV16:
+ case V4L2_PIX_FMT_NV61:
+
[PATCH v3 3/3] arm64: dts: rockchip: Add the camera interface description of the PX30
The PX30 has a camera interface, supporting CSI2 and BT656
modes. Add a DT description for this interface.
Signed-off-by: Maxime Chevallier
---
V3: Renamed the driver
arch/arm64/boot/dts/rockchip/px30.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 2695ea8cda14..8c81eb35da86 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1106,6 +1106,18 @@ vopl_mmu: iommu@ff470f00 {
status = "disabled";
};
+ vip: vip@ff49 {
+ compatible = "rockchip,px30-vip";
+ reg = <0x0 0xff49 0x0 0x200>;
+ interrupts = ;
+ clocks = < ACLK_CIF>, < HCLK_CIF>, < PCLK_CIF>,
< SCLK_CIF_OUT>;
+ clock-names = "aclk", "hclk", "pclkin";
+ power-domains = < PX30_PD_VI>;
+ resets = < SRST_CIF_A>, < SRST_CIF_H>, <
SRST_CIF_PCLKIN>;
+ reset-names = "axi", "ahb", "pclkin";
+ status = "disabled";
+ };
+
qos_gmac: qos@ff518000 {
compatible = "syscon";
reg = <0x0 0xff518000 0x0 0x20>;
--
2.25.4
[PATCH v3 0/3] media: rockchip: Introduce driver for Rockchip's camera interface
Hi everyone, This is the third iteration of the series introducing a driver for the PX30 camera interface. This was previously known as the "cif" driver in other iterations, but was renamed to "vip" following Ezequiel's advices to match the datasheet name. This is based on a BSP driver, and I'm not fully familiar with the media and V4L2 frameworks, so I guess some review is still needed. This new series adds some stability fixes, and introduces the double-buffering frame handling, giving better performances. Thanks to everyone who reviewed the first two iterations, Maxime Maxime Chevallier (3): media: dt-bindings: media: Document Rockchip VIP bindings media: rockchip: Introduce driver for Rockhip's camera interface arm64: dts: rockchip: Add the camera interface description of the PX30 .../bindings/media/rockchip-vip.yaml | 100 ++ arch/arm64/boot/dts/rockchip/px30.dtsi| 12 + drivers/media/platform/Kconfig| 13 + drivers/media/platform/Makefile |1 + drivers/media/platform/rockchip/vip/Makefile |3 + drivers/media/platform/rockchip/vip/capture.c | 1246 + drivers/media/platform/rockchip/vip/dev.c | 408 ++ drivers/media/platform/rockchip/vip/dev.h | 206 +++ drivers/media/platform/rockchip/vip/regs.h| 260 9 files changed, 2249 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/rockchip-vip.yaml create mode 100644 drivers/media/platform/rockchip/vip/Makefile create mode 100644 drivers/media/platform/rockchip/vip/capture.c create mode 100644 drivers/media/platform/rockchip/vip/dev.c create mode 100644 drivers/media/platform/rockchip/vip/dev.h create mode 100644 drivers/media/platform/rockchip/vip/regs.h -- 2.25.4
[PATCH 1/3] dt-bindings: vendor-prefixes: Add techwell vendor prefix
Add prefix for Techwell, Inc. Signed-off-by: Maxime Chevallier --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 63996ab03521..3fcf071c4467 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1033,6 +1033,8 @@ patternProperties: description: TechNexion "^technologic,.*": description: Technologic Systems + "^techwell,.*": +description: Techwell, Inc. "^tempo,.*": description: Tempo Semiconductor "^techstar,.*": -- 2.25.4
[PATCH 3/3] media: i2c: Introduce a driver for the Techwell TW9900 decoder
The Techwell video decoder supports PAL, NTSC and SECAM input formats,
and outputs a BT.656 signal.
This commit adds support for this device, based on an implementation
made by Rockchip. This implemention adds basic support for NTSC and PAL,
and some basic brightness and contrast controls.
Signed-off-by: Maxime Chevallier
---
drivers/media/i2c/Kconfig | 9 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/tw9900.c | 671 +
3 files changed, 681 insertions(+)
create mode 100644 drivers/media/i2c/tw9900.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c7ba76fee599..9b9f97fa4335 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -426,6 +426,15 @@ config VIDEO_TW2804
To compile this driver as a module, choose M here: the
module will be called tw2804.
+config VIDEO_TW9900
+ tristate "Techwell TW9900 video decoder"
+ depends on VIDEO_V4L2 && I2C
+ help
+ Support for the Techwell tw9900 multi-standard video decoder
+
+ To compile this driver as a module, choose M here: the
+ module will be called tw9900.
+
config VIDEO_TW9903
tristate "Techwell TW9903 video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f0a77473979d..cbc1d9aedd38 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
+obj-$(CONFIG_VIDEO_TW9900) += tw9900.o
obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
diff --git a/drivers/media/i2c/tw9900.c b/drivers/media/i2c/tw9900.c
new file mode 100644
index ..950a7bbda80d
--- /dev/null
+++ b/drivers/media/i2c/tw9900.c
@@ -0,0 +1,671 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the Techwell TW9900 multi-standard video decoder.
+ *
+ * Copyright (C) 2018 Fuzhou Rockchip Electronics Co., Ltd.
+ * Copyright (C) 2020 Maxime Chevallier
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TW9900_REG_CHIP_ID 0x00
+#define TW9900_REG_CHIP_STATUS 0x01
+#defineTW9900_REG_CHIP_STATUS_VLOCK0x08
+#defineTW9900_REG_CHIP_STATUS_VDLOSS 0x80
+#define TW9900_REG_OUT_FMT_CTL 0x03
+#define TW9900_REG_CKHY_HSDLY 0x04
+#define TW9900_REG_OUT_CTRL_I 0x05
+#define TW9900_REG_ANALOG_CTL 0x06
+#define TW9900_REG_CROP_HI 0x07
+#define TW9900_REG_VDELAY_LO0x08
+#define TW9900_REG_VACTIVE_LO 0x09
+#define TW9900_REG_HACTIVE_LO 0x0B
+#define TW9900_REG_CNTRL1 0x0C
+#define TW9900_REG_BRIGHT_CTL 0x10
+#define TW9900_REG_CONTRAST_CTL 0x11
+#define TW9900_REG_VBI_CNTL0x19
+#define TW9900_REG_ANAL_CTL_II 0x1A
+#define TW9900_REG_OUT_CTRL_II 0x1B
+#define TW9900_REG_STD_SEL 0x1C
+#define TW9900_REG_MISSCNT 0x26
+#define TW9900_REG_MISC_CTL_II 0x2F
+#define TW9900_REG_VVBI 0x55
+
+#define TW9900_CHIP_ID 0x00
+
+#define REG_SC_CTRL_MODE TW9900_REG_OUT_FMT_CTL
+#define SC_CTRL_MODE_STANDBY 0xA7
+#define SC_CTRL_MODE_STREAMING 0xA0
+
+#define REG_NULL 0xFF
+
+#define VSYNC_POLL_INTERVAL_MS 20
+#define VSYNC_WAIT_MAX_POLLS50
+
+static const char * const tw9900_supply_names[] = {
+ "vdd",
+};
+
+#define TW9900_NUM_SUPPLIES ARRAY_SIZE(tw9900_supply_names)
+
+struct regval {
+ u8 addr;
+ u8 val;
+};
+
+struct tw9900_mode {
+ u32 width;
+ u32 height;
+ u32 skip_top;
+ u32 std;
+ u32 field;
+ const struct regval *reg_list;
+};
+
+struct tw9900 {
+ struct i2c_client *client;
+ struct gpio_desc*reset_gpio;
+ struct regulator_bulk_data supplies[TW9900_NUM_SUPPLIES];
+
+ boolstreaming;
+
+ struct v4l2_subdev subdev;
+ struct v4l2_ctrl_handler hdl;
+ struct media_padpad;
+
+ struct timer_list timer;
+ struct work_struct work_i2c_poll;
+
+ const struct tw9900_mode *cur_mode;
+};
+
+#define to_tw9900(sd) container_of(sd, struct tw9900, subdev)
+
+static const struct regval tw9900_init_regs[] = {
+ {TW9900_REG_MISC_CTL_II,0xE6},
+ {TW9900_REG_MISSCNT,0x24},
+ {TW9900_REG_OUT_FMT_CTL,0xA7},
+ {TW9900_REG_ANAL_CTL_II,0x0A},
+ {TW9900_REG_VDELAY_LO, 0x19},
+ {TW9900_REG_STD_SEL,0x00},
+ {TW9900_REG_VACTIVE_LO, 0xF0},
+ {TW9900_REG_STD_SEL,0x07},
+ {TW9900_REG_CKHY_HSDLY, 0x40}
[PATCH 2/3] media: dt-bindings: media: i2c: Add bindings for TW9900
The Techwell TW9900 is a video decoder supporting multiple input
standards, such as PAL, NTSC and SECAM, and outputs a BT.656 video
signal.
It's designed to be low-power, posesses some features such as a
programmable comb-filter, and automatic input standard detection.
Signed-off-by: Maxime Chevallier
---
.../devicetree/bindings/media/i2c/tw9900.yaml | 59 +++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tw9900.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
b/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
new file mode 100644
index ..fdc2c35875aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tw9900.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/tw9900.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Techwell TW9900 NTSC/PAL/SECAM video decoder
+
+maintainers:
+ - Maxime Chevallier
+
+description:
+ The tw9900 is a multi-standard video decoder, supporting NTSC, PAL and SECAM
+ standards with auto-detection features.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - techwell,tw9900
+
+ reg:
+maxItems: 1
+
+ vdd-supply:
+description: VDD power supply
+
+ port:
+type: object
+description:
+ A node containing a single endpoint as doucmented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+tw9900: tw9900@44 {
+compatible = "techwell,tw9900";
+reg = <0x44>;
+
+vdd-supply = <_supply>;
+reset-gpio = < RK_PB5 GPIO_ACTIVE_LOW>;
+
+port {
+tw9900_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
--
2.25.4
[PATCH 0/3] media: Add support for the Techwell TW9900 video decoder
Hi everyone, Here's a series to add basic support for the Techwell TW9900 low-power video decoder. This decoder support PAL, NTSC and SECAM inputs, with a built-in comb filter and automatic input standard detection. This series was based on previous work done by Rockchip, and is based on vendor code. I apologise if there are some rough edges remaining in this driver, as I'm not yet fully familiar with the media and V4L2 frameworks, so any review is appreciated. This series adds basic support for NTSC and PAL B/D/G/H/I, along with some very basic controls for brightness and contrast. Thanks, Maxime Maxime Chevallier (3): dt-bindings: vendor-prefixes: Add techwell vendor prefix media: dt-bindings: media: i2c: Add bindings for TW9900 media: i2c: Introduce a driver for the Techwell TW9900 decoder .../devicetree/bindings/media/i2c/tw9900.yaml | 59 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + drivers/media/i2c/Kconfig | 9 + drivers/media/i2c/Makefile| 1 + drivers/media/i2c/tw9900.c| 671 ++ 5 files changed, 742 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/tw9900.yaml create mode 100644 drivers/media/i2c/tw9900.c -- 2.25.4
Re: [PATCH v2 2/3] media: rockchip: Introduce driver for Rockhip's camera interface
Hi Ezequiel, Sorry for the late reply, some answers to your very useful comments below :) On Sun, 31 May 2020 10:40:14 -0300 Ezequiel Garcia wrote: >Hi Maxime, > >Thanks for posting this patch. I think you can still improve it, >but it's a neat first try! :-) > >On Fri, 29 May 2020 at 10:05, Maxime Chevallier > wrote: >> >> Introduce a driver for the camera interface on some Rockchip platforms. >> >> This controller supports CSI2, Parallel and BT656 interfaces, but for >> now only the parallel interface could be tested, hence it's the only one >> that's supported in the first version of this driver. >> > >I'm confused, you mention parallel as the only tested interface, >but the cover letters mentions PAL. Doesn't PAL mean BT.656 >or am I completely lost? No you are correct, this is a misunderstanding on my part about the various formats and naming schemes. The main point I wanted to outline is that the hardware supports a CSI2 interface, which this version of the driver doesn't implement. >(I am not super familiar with parallel sensors). > >> This controller can be fond on PX30, RK1808, RK3128, RK3288 and RK3288, >> but for now it's only be tested on PX30. >> > >My RK3288 and RK3326 (i.e. PX30) refer to this IP block as "Video >Input interface". >I am wondering if it won't be clearer for developers / users if we >rename the driver >to rockchip-vip (and of course s/cif/vip and s/CIF/VIP). After looking into the datasheets for these SoCs, it's clear that the denomination should indeed be "VIP" and not "CIF", thanks ! >> Most of this driver was written follwing the BSP driver from rockchip, >> removing the parts that either didn't fit correctly the guidelines, or >> that couldn't be tested. >> >> This basic version doesn't support cropping nor scaling, and is only >> designed with one sensor being attached to it a any time. >> >> Signed-off-by: Maxime Chevallier >> --- >> >> Changes since V1 : >> >> - Convert to the bulk APIs for clocks and resets > >Note that the bulk API clock conversion was not >properly done. > >> - remove useless references to priv data >> - Move around some init functions at probe time >> - Upate some helpers to more suitable ones >> >> Here is the output from v4l2-compliance. There are no fails in the final >> summary, but there is one in the output that I didn't catch previously. >> >> Still, here's the V2 in the meantime, if you have any further reviews >> ompliance SHA: not available, 64 bits >> >> Compliance test for rkcif device /dev/video0: >> >> Driver Info: >> Driver name : rkcif >> Card type: rkcif >> Bus info : platform:ff49.cif >> Driver version : 5.7.0 >> Capabilities : 0x84201000 >> Video Capture Multiplanar >> Streaming >> Extended Pix Format >> Device Capabilities >> Device Caps : 0x04201000 >> Video Capture Multiplanar >> Streaming >> Extended Pix Format >> Media Driver Info: >> Driver name : rkcif >> Model: rkcif >> Serial : >> Bus info : >> Media version: 5.7.0 >> Hardware revision: 0x (0) >> Driver version : 5.7.0 >> Interface Info: >> ID : 0x0302 >> Type : V4L Video >> Entity Info: >> ID : 0x0001 (1) >> Name : video_rkcif >> Function : V4L2 I/O >> Pad 0x0104 : 0: Sink >> Link 0x0207: from remote pad 0x106 of entity 'tw9900 >> 2-0044': Data, Enabled >> >> Required ioctls: >> test MC information (see 'Media Driver Info' above): OK >> test VIDIOC_QUERYCAP: OK >> >> Allow for multiple opens: >> test second /dev/video0 open: OK >> test VIDIOC_QUERYCAP: OK >> test VIDIOC_G/S_PRIORITY: OK >> test for unlimited opens: OK >> >> Debug ioctls: >> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) >> test VIDIOC_LOG_STATUS: OK (Not Supported) >> >> Input ioctls: >> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) >> test VIDIOC_G/S_FREQUENCY: OK (Not Supported) >> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) >>
Re: [PATCH 2/3] media: rockchip: Introduce driver for Rockhip's camera interface
Hi Hans, On Thu, 16 Apr 2020 11:35:41 +0200 Hans Verkuil wrote: I'm very sorry I missed a lot of your reviews in my V2, that wasn't on purpose. I'll fix this on the next iteration, sorry about that. Thank you very much for your review ! Maxime >+Helen Koike (rkisp1 maintainer) > >A quick review below... > >On 03/04/2020 16:21, Maxime Chevallier wrote: >> Introduce a driver for the camera interface on some Rockchip platforms. >> >> This controller supports CSI2, Parallel and BT656 interfaces, but for >> now only the parallel interface could be tested, hence it's the only one >> that's supported in the first version of this driver. >> >> This controller can be fond on PX30, RK1808, RK3128, RK3288 and RK3288, > >fond -> found > >'RK3288 and RK3288'? Typo? > >> but for now it's only be tested on PX30. >> >> Most of this driver was written follwing the BSP driver from rockchip, > >follwing -> following > >> removing the parts that either didn't fit correctly the guidelines, or >> that couldn't be tested. >> >> This basic version doesn't support cropping nor scaling, and is only >> designed with one sensor being attached to it a any time. > >a any -> at any > >Make sure you test with v4l2-compliance, in fact, I need to see the output >of 'v4l2-compliance -s' when you post v2. There shouldn't be any warnings >or fails. Make sure you build v4l2-compliance from the git repo >(https://git.linuxtv.org//v4l-utils.git) directly, that ensures that you >use the latest and greatest version. > >How does this driver compare to drivers/staging/media/rkisp1? Is the ISP >hardware completely different (it probably is, just checking)? > >How complex is the ISP hardware? This driver is a regular video driver, >but should it move to a media controller based driver instead, like rkisp1? > >I don't know the hardware, so I can't tell. > >> >> Signed-off-by: Maxime Chevallier >> --- >> drivers/media/platform/Kconfig| 13 + >> drivers/media/platform/Makefile |1 + >> drivers/media/platform/rockchip/cif/Makefile |3 + >> drivers/media/platform/rockchip/cif/capture.c | 1170 + >> drivers/media/platform/rockchip/cif/dev.c | 407 ++ >> drivers/media/platform/rockchip/cif/dev.h | 208 +++ >> drivers/media/platform/rockchip/cif/regs.h| 256 >> 7 files changed, 2058 insertions(+) >> create mode 100644 drivers/media/platform/rockchip/cif/Makefile >> create mode 100644 drivers/media/platform/rockchip/cif/capture.c >> create mode 100644 drivers/media/platform/rockchip/cif/dev.c >> create mode 100644 drivers/media/platform/rockchip/cif/dev.h >> create mode 100644 drivers/media/platform/rockchip/cif/regs.h >> >> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig >> index f65e98d3adf2..d2f413a99886 100644 >> --- a/drivers/media/platform/Kconfig >> +++ b/drivers/media/platform/Kconfig >> @@ -460,6 +460,19 @@ config VIDEO_ROCKCHIP_RGA >> >>To compile this driver as a module choose m here. >> >> +config VIDEO_ROCKCHIP_CIF >> +tristate "Rockchip Camera Interface" >> +depends on VIDEO_DEV && VIDEO_V4L2 >> +depends on ARCH_ROCKCHIP || COMPILE_TEST >> +select VIDEOBUF2_DMA_SG >> +select VIDEOBUF2_DMA_CONTIG >> +select V4L2_FWNODE >> +select V4L2_MEM2MEM_DEV >> +help >> + This is a v4l2 driver for Rockchip SOC Camera interface. >> + >> + To compile this driver as a module choose m here. >> + >> config VIDEO_TI_VPE >> tristate "TI VPE (Video Processing Engine) driver" >> depends on VIDEO_DEV && VIDEO_V4L2 >> diff --git a/drivers/media/platform/Makefile >> b/drivers/media/platform/Makefile >> index d13db96e3015..67e7ac034be1 100644 >> --- a/drivers/media/platform/Makefile >> +++ b/drivers/media/platform/Makefile >> @@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o >> obj-$(CONFIG_VIDEO_RENESAS_VSP1)+= vsp1/ >> >> obj-$(CONFIG_VIDEO_ROCKCHIP_RGA)+= rockchip/rga/ >> +obj-$(CONFIG_VIDEO_ROCKCHIP_CIF)+= rockchip/cif/ >> >> obj-y += omap/ >> >> diff --git a/drivers/media/platform/rockchip/cif/Makefile >> b/drivers/media/platform/rockchip/cif/Makefile >> new file mode 100644 >> index ..727990824316 >> --- /dev/null >> +++ b/drivers/media/platform/rockchip/cif/Makefile >> @@ -0,0 +1,3 @@ >> +# SPDX-License-Identif
[PATCH v2 0/3] media: rockchip: Introduce driver for the camera interface on PX30
Hello everyone, Here's a V2 of the series adding very basic support for the camera interface on the Rockchip PX30 SoC. Thanks to everyone that commented on the first series, your reviews were very helpful :) This Camera Interface is also supported on other Rockchip SoC such as the RK1808, RK3128, RK3288 and RK3288, but for now I've only been able to test it on the PX30, using a PAL format. This driver is mostly based on the driver found in Rockchip's BSP, that has been trimmed down to support the set of features that I was able to test, that is pretty much a very basic one-frame capture and video streaming with GStreamer. This first draft only supports the Parallel interface, although the controller has support for BT656 and CSI2. Finally, this controller has an iommu that could be used in this driver, but as of today I've not been able to get it to work. Any review is welcome. Thanks, Maxime --- Changes since V1 --- - Took reviews from Rob, Hans, Robin and Heiko into account : - Renamed the clocks in the binding - Fixed the DT schema compiling - Fixed a few typos - Used the clk bulk API - Used the reset array API - Changed a few helpers for more suitable ones - Rebased on 5.7-rc7 Maxime Chevallier (3): media: dt-bindings: media: Document Rockchip CIF bindings media: rockchip: Introduce driver for Rockhip's camera interface arm64: dts: rockchip: Add the camera interface description of the PX30 .../bindings/media/rockchip-cif.yaml | 100 ++ arch/arm64/boot/dts/rockchip/px30.dtsi| 12 + drivers/media/platform/Kconfig| 13 + drivers/media/platform/Makefile |1 + drivers/media/platform/rockchip/cif/Makefile |3 + drivers/media/platform/rockchip/cif/capture.c | 1170 + drivers/media/platform/rockchip/cif/dev.c | 358 + drivers/media/platform/rockchip/cif/dev.h | 213 +++ drivers/media/platform/rockchip/cif/regs.h| 256 9 files changed, 2126 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/rockchip-cif.yaml create mode 100644 drivers/media/platform/rockchip/cif/Makefile create mode 100644 drivers/media/platform/rockchip/cif/capture.c create mode 100644 drivers/media/platform/rockchip/cif/dev.c create mode 100644 drivers/media/platform/rockchip/cif/dev.h create mode 100644 drivers/media/platform/rockchip/cif/regs.h -- 2.25.4
[PATCH v2 3/3] arm64: dts: rockchip: Add the camera interface description of the PX30
The PX30 has a camera interface, supporting CSI2, BT656 and Parallel
modes. Add a DT description for this interface.
Signed-off-by: Maxime Chevallier
---
Changes since V1:
- Updated the clock and reset names
- Reordered the properties to have clocks and resets bundled together
arch/arm64/boot/dts/rockchip/px30.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi
b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 9f84aaaf3fba..d895541b7216 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1140,6 +1140,18 @@ vopl_mmu: iommu@ff470f00 {
status = "disabled";
};
+ cif: cif@ff49 {
+ compatible = "rockchip,px30-cif";
+ reg = <0x0 0xff49 0x0 0x200>;
+ interrupts = ;
+ clocks = < ACLK_CIF>, < HCLK_CIF>, < PCLK_CIF>,
< SCLK_CIF_OUT>;
+ clock-names = "aclk", "hclk", "pclkin";
+ power-domains = < PX30_PD_VI>;
+ resets = < SRST_CIF_A>, < SRST_CIF_H>, <
SRST_CIF_PCLKIN>;
+ reset-names = "axi", "ahb", "pclkin";
+ status = "disabled";
+ };
+
qos_gmac: qos@ff518000 {
compatible = "syscon";
reg = <0x0 0xff518000 0x0 0x20>;
--
2.25.4
[PATCH v2 2/3] media: rockchip: Introduce driver for Rockhip's camera interface
Introduce a driver for the camera interface on some Rockchip platforms. This controller supports CSI2, Parallel and BT656 interfaces, but for now only the parallel interface could be tested, hence it's the only one that's supported in the first version of this driver. This controller can be fond on PX30, RK1808, RK3128, RK3288 and RK3288, but for now it's only be tested on PX30. Most of this driver was written follwing the BSP driver from rockchip, removing the parts that either didn't fit correctly the guidelines, or that couldn't be tested. This basic version doesn't support cropping nor scaling, and is only designed with one sensor being attached to it a any time. Signed-off-by: Maxime Chevallier --- Changes since V1 : - Convert to the bulk APIs for clocks and resets - remove useless references to priv data - Move around some init functions at probe time - Upate some helpers to more suitable ones Here is the output from v4l2-compliance. There are no fails in the final summary, but there is one in the output that I didn't catch previously. Still, here's the V2 in the meantime, if you have any further reviews ompliance SHA: not available, 64 bits Compliance test for rkcif device /dev/video0: Driver Info: Driver name : rkcif Card type: rkcif Bus info : platform:ff49.cif Driver version : 5.7.0 Capabilities : 0x84201000 Video Capture Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04201000 Video Capture Multiplanar Streaming Extended Pix Format Media Driver Info: Driver name : rkcif Model: rkcif Serial : Bus info : Media version: 5.7.0 Hardware revision: 0x (0) Driver version : 5.7.0 Interface Info: ID : 0x0302 Type : V4L Video Entity Info: ID : 0x0001 (1) Name : video_rkcif Function : V4L2 I/O Pad 0x0104 : 0: Sink Link 0x0207: from remote pad 0x106 of entity 'tw9900 2-0044': Data, Enabled Required ioctls: test MC information (see 'Media Driver Info' above): OK test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second /dev/video0 open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 1 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls (Input 0): test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls (Input 0): test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) fail: v4l2-test-formats.cpp(1772): node->can_scale && node->frmsizes_count[v4l_format_g_pixelformat()] test Scaling: OK Codec ioctls (Input 0): test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls (Input 0): test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK test Requests: OK (Not Supported) Total for rkcif device /
[PATCH v2 1/3] media: dt-bindings: media: Document Rockchip CIF bindings
Add a documentation for the Rockchip Camera Interface controller
binding.
This controller can be found on platforms such as the PX30 or the
RK3288, the PX30 being the only platform supported so far.
Signed-off-by: Maxime Chevallier
---
Changes since V1
- Updated the clock and reset names
- Added missing includes in the example, so that the make dt_binding_check
passes
.../bindings/media/rockchip-cif.yaml | 100 ++
1 file changed, 100 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rockchip-cif.yaml
diff --git a/Documentation/devicetree/bindings/media/rockchip-cif.yaml
b/Documentation/devicetree/bindings/media/rockchip-cif.yaml
new file mode 100644
index ..f11a30ca9d42
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-cif.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/rockchip-cif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip Camera Interface (CIF)
+
+maintainers:
+ - Maxime Chevallier
+
+description: |-
+ Camera Interface for Rockcip platforms
+
+properties:
+ compatible:
+const: rockchip,px30-cif
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: ACLK
+ - description: HCLK
+ - description: PCLK IN
+
+ clock-names:
+items:
+ - const: aclk
+ - const: hclkf
+ - const: pclkin
+
+ resets:
+items:
+ - description: AXI
+ - description: AHB
+ - description: PCLK IN
+
+ reset-names:
+items:
+ - const: axi
+ - const: ahb
+ - const: pclkin
+
+ power-domains:
+maxItems: 1
+description: phandle to the associated power domain
+
+ # See ./video-interfaces.txt for details
+ port:
+type: object
+additionalProperties: false
+
+properties:
+ endpoint:
+type: object
+
+properties:
+ remote-endpoint: true
+
+required:
+ - remote-endpoint
+
+required:
+ - endpoint
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+cif: cif@ff49 {
+ compatible = "rockchip,px30-cif";
+ reg = <0x0 0xff49 0x0 0x200>;
+ interrupts = ;
+ clocks = < ACLK_CIF>, < HCLK_CIF>, < PCLK_CIF>, <
SCLK_CIF_OUT>;
+ clock-names = "aclk_cif", "hclk_cif", "pclk_cif", "cif_out";
+ resets = < SRST_CIF_A>, < SRST_CIF_H>, < SRST_CIF_PCLKIN>;
+ reset-names = "rst_cif_a", "rst_cif_h", "rst_cif_pclkin";
+ power-domains = < PX30_PD_VI>;
+port {
+cif_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+...
--
2.25.4
[PATCH net] net: mvpp2: Don't check for 3 consecutive Idle frames for 10G links
PPv2's XLGMAC can wait for 3 idle frames before triggering a link up
event. This can cause the link to be stuck low when there's traffic on
the interface, so disable this feature.
Fixes: 4bb043262878 ("net: mvpp2: phylink support")
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index c51f1d5b550b..b6591ea0c6d6 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4739,9 +4739,9 @@ static void mvpp2_xlg_config(struct mvpp2_port *port,
unsigned int mode,
else
ctrl0 &= ~MVPP22_XLG_CTRL0_RX_FLOW_CTRL_EN;
- ctrl4 &= ~MVPP22_XLG_CTRL4_MACMODSELECT_GMAC;
- ctrl4 |= MVPP22_XLG_CTRL4_FWD_FC | MVPP22_XLG_CTRL4_FWD_PFC |
-MVPP22_XLG_CTRL4_EN_IDLE_CHECK;
+ ctrl4 &= ~(MVPP22_XLG_CTRL4_MACMODSELECT_GMAC |
+ MVPP22_XLG_CTRL4_EN_IDLE_CHECK);
+ ctrl4 |= MVPP22_XLG_CTRL4_FWD_FC | MVPP22_XLG_CTRL4_FWD_PFC;
if (old_ctrl0 != ctrl0)
writel(ctrl0, port->base + MVPP22_XLG_CTRL0_REG);
--
2.20.1
[PATCH net-next 0/2] net: mvpp2: Add classification based on the ETHER flow
Hello everyone, This series adds support for classification of the ETHER flow in the mvpp2 driver. The first patch allows detecting when a user specifies a flow_type that isn't supported by the driver, while the second adds support for this flow_type by adding the mapping between the ETHER_FLOW enum value and the relevant classifier flow entries. Thanks, Maxime Maxime Chevallier (2): net: mvpp2: cls: Report an error for unsupported flow types net: mvpp2: cls: Add support for ETHER_FLOW drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 6 ++ 1 file changed, 6 insertions(+) -- 2.20.1
[PATCH net-next 2/2] net: mvpp2: cls: Add support for ETHER_FLOW
Users can specify classification actions based on the 'ether' flow type.
In that case, this will apply to all ethernet traffic, superseeding
flows such as 'udp4' or 'tcp6'.
Add support for this flow type in the PPv2 classifier, by mapping the
ETHER_FLOW value to the corresponding entries in the classifier.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
index 6c088c903c15..35478cba2aa5 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
@@ -548,6 +548,8 @@ void mvpp2_cls_c2_read(struct mvpp2 *priv, int index,
static int mvpp2_cls_ethtool_flow_to_type(int flow_type)
{
switch (flow_type & ~(FLOW_EXT | FLOW_MAC_EXT | FLOW_RSS)) {
+ case ETHER_FLOW:
+ return MVPP22_FLOW_ETHERNET;
case TCP_V4_FLOW:
return MVPP22_FLOW_TCP4;
case TCP_V6_FLOW:
--
2.20.1
[PATCH net-next 1/2] net: mvpp2: cls: Report an error for unsupported flow types
Add a missing check to detect flow types that we don't support, so that
user can be informed of this.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
index b195fb5d61f4..6c088c903c15 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
@@ -1373,6 +1373,10 @@ int mvpp2_ethtool_cls_rule_ins(struct mvpp2_port *port,
efs->rule.flow = ethtool_rule->rule;
efs->rule.flow_type =
mvpp2_cls_ethtool_flow_to_type(info->fs.flow_type);
+ if (efs->rule.flow_type < 0) {
+ ret = efs->rule.flow_type;
+ goto clean_rule;
+ }
ret = mvpp2_cls_rfs_parse_rule(>rule);
if (ret)
--
2.20.1
Re: [PATCH] driver core: platform: Allow using a dedicated dma_mask for platform_device
Hi Christoph, On Fri, 28 Jun 2019 08:59:46 -0700 Christoph Hellwig wrote: >I'd much rather bite the bullet and make dev->dma_mask a scalar >instead of a pointer. The pointer causes way to much boiler plate code, >and the semantics are way to subtile. I agree that this the real solution, it just seemed a bit overwhelming to me. I'll be happy to help with this though, now that you took a big first step. > Below is a POV patch that >compiles and boots with my usual x86 test config, and at least compiles >with the arm and pmac32 defconfigs. It probably breaks just about >everything else, but should give us an idea what is involve in the >switch: I'll test that on my boards too. Thanks, Maxime
[PATCH] driver core: platform: Allow using a dedicated dma_mask for platform_device
This patch attempts to solve a long standing situation where
dev->dma_mask is a pointer to dev->dma_coherent_mask, meaning that any
change to the coherent mask will affect the streaming mask.
The API allows to use different values for both masks, but for now
platform_device built from DT will simply make the dma_mask point to the
coherent mask.
This is a problem on a least one driver, the PPv2 network driver, which
needs different streaming and coherent masks to overcome a HW
limitation. In this case, the issue is a performance degradation since
the streaming mask isn't as big as it ought to be, causing a lot of
buffer bounces.
There were previous attempts to fix this issue. One of them by Brian
Brooks, where the dma_mask is reallocated in the driver itself,
which wasn't considered to be the best approach :
https://lore.kernel.org/netdev/20180820024730.9147-1-brian.bro...@linaro.org/
This lead to a discussion pointing to another attempt to solve the issue,
by Christoph Hellwig :
https://lore.kernel.org/lkml/20180829062401.8701-2-...@lst.de/
This more generic approach ended-up causing regressions on some mfd
drivers (the sm501 was one of the reports).
The current patch tries to be a bit less generic, and allows setting-up
the dma_mask for platform devices using a dedicated helper. In this case,
the dma_mask is allocated in struct platform_object, as suggested by
Russell King.
This helper is then used in platform_device creation code from the DT.
Suggested-by: Russell King
Signed-off-by: Maxime Chevallier
---
Hi everyone,
This patch, if suitable, would require a lot of testing to detect
drivers that rely on the streaming mask being the same as the coherent
mask.
Thanks,
Maxime
drivers/base/platform.c | 17 +
drivers/of/platform.c | 7 +--
include/linux/platform_device.h | 1 +
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4d1729853d1a..35e7bdb8576c 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -256,9 +256,26 @@ EXPORT_SYMBOL_GPL(platform_add_devices);
struct platform_object {
struct platform_device pdev;
+ u64 dma_mask;
char name[];
};
+/**
+ * platform_device_setup_dma_mask - Sets the dma_mask pointer
+ * @pdev: platform device to configure the device's mask
+ *
+ * Sets the dma_mask of the underlying device to point to a dedicated region,
+ * that belongs to the platform_device.
+ */
+void platform_device_setup_dma_mask(struct platform_device *pdev)
+{
+ struct platform_object *pa = container_of(pdev, struct platform_object,
+ pdev);
+
+ pa->pdev.dev.dma_mask = >dma_mask;
+}
+EXPORT_SYMBOL_GPL(platform_device_setup_dma_mask);
+
/**
* platform_device_put - destroy a platform device
* @pdev: platform device to free
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 04ad312fd85b..4a6980e3356c 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -186,8 +186,11 @@ static struct platform_device
*of_platform_device_create_pdata(
goto err_clear_flag;
dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
- if (!dev->dev.dma_mask)
- dev->dev.dma_mask = >dev.coherent_dma_mask;
+ if (!dev->dev.dma_mask) {
+ platform_device_setup_dma_mask(dev);
+ *dev->dev.dma_mask = dev->dev.coherent_dma_mask;
+ }
+
dev->dev.bus = _bus_type;
dev->dev.platform_data = platform_data;
of_msi_configure(>dev, dev->dev.of_node);
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index cc464850b71e..a95c2d224de9 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -181,6 +181,7 @@ extern int platform_device_add_properties(struct
platform_device *pdev,
extern int platform_device_add(struct platform_device *pdev);
extern void platform_device_del(struct platform_device *pdev);
extern void platform_device_put(struct platform_device *pdev);
+extern void platform_device_setup_dma_mask(struct platform_device *pdev);
struct platform_driver {
int (*probe)(struct platform_device *);
--
2.20.1
[PATCH net-next v2] net: ethtool: Allow parsing ETHER_FLOW types when using flow_rule
When parsing an ethtool_rx_flow_spec, users can specify an ethernet flow
which could contain matches based on the ethernet header, such as the
MAC address, the VLAN tag or the ethertype.
ETHER_FLOW uses the src and dst ethernet addresses, along with the
ethertype as keys. Matches based on the vlan tag are also possible, but
they are specified using the special FLOW_EXT flag.
Signed-off-by: Maxime Chevallier
---
V2 : Add src and dst mac address parsing, as suggested by Pablo.
net/core/ethtool.c | 24
1 file changed, 24 insertions(+)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 4d1011b2e24f..6288e69e94fc 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -2883,6 +2883,30 @@ ethtool_rx_flow_rule_create(const struct
ethtool_rx_flow_spec_input *input)
match->mask.basic.n_proto = htons(0x);
switch (fs->flow_type & ~(FLOW_EXT | FLOW_MAC_EXT | FLOW_RSS)) {
+ case ETHER_FLOW: {
+ const struct ethhdr *ether_spec, *ether_m_spec;
+
+ ether_spec = >h_u.ether_spec;
+ ether_m_spec = >m_u.ether_spec;
+
+ if (!is_zero_ether_addr(ether_m_spec->h_source)) {
+ ether_addr_copy(match->key.eth_addrs.src,
+ ether_spec->h_source);
+ ether_addr_copy(match->mask.eth_addrs.src,
+ ether_m_spec->h_source);
+ }
+ if (!is_zero_ether_addr(ether_m_spec->h_dest)) {
+ ether_addr_copy(match->key.eth_addrs.dst,
+ ether_spec->h_dest);
+ ether_addr_copy(match->mask.eth_addrs.dst,
+ ether_m_spec->h_dest);
+ }
+ if (ether_m_spec->h_proto) {
+ match->key.basic.n_proto = ether_spec->h_proto;
+ match->mask.basic.n_proto = ether_m_spec->h_proto;
+ }
+ }
+ break;
case TCP_V4_FLOW:
case UDP_V4_FLOW: {
const struct ethtool_tcpip4_spec *v4_spec, *v4_m_spec;
--
2.20.1
Re: [PATCH net-next] net: ethtool: Allow parsing ETHER_FLOW types when using flow_rule
Hi Pablo,
On Wed, 26 Jun 2019 10:58:46 +0200
Pablo Neira Ayuso wrote:
>On Wed, Jun 26, 2019 at 10:44:03AM +0200, Maxime Chevallier wrote:
>> When parsing an ethtool_rx_flow_spec, users can specify an ethernet flow
>> which could contain matches based on the ethernet header, such as the
>> MAC address, the VLAN tag or the ethertype.
>>
>> Only the ethtype field is specific to the ether flow, the MAC and vlan
>> fields are processed using the special FLOW_EXT and FLOW_MAC_EXT flags.
>>
>> Signed-off-by: Maxime Chevallier
>> ---
>> net/core/ethtool.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
>> index 4d1011b2e24f..01ceba556341 100644
>> --- a/net/core/ethtool.c
>> +++ b/net/core/ethtool.c
>> @@ -2883,6 +2883,18 @@ ethtool_rx_flow_rule_create(const struct
>> ethtool_rx_flow_spec_input *input)
>> match->mask.basic.n_proto = htons(0x);
>>
>> switch (fs->flow_type & ~(FLOW_EXT | FLOW_MAC_EXT | FLOW_RSS)) {
>> +case ETHER_FLOW: {
>> +const struct ethhdr *ether_spec, *ether_m_spec;
>> +
>> +ether_spec = >h_u.ether_spec;
>> +ether_m_spec = >m_u.ether_spec;
>> +
>> +if (ether_m_spec->h_proto) {
>> +match->key.basic.n_proto = ether_spec->h_proto;
>> +match->mask.basic.n_proto = ether_m_spec->h_proto;
>> +}
>
>I see some drivers in the tree also interpret the h_source and h_dest
>fields?
Ah yes you're right. I assumed these fields were specific to the
FLOW_MAC_EXT flags, but by looking into the ethtool code, it seems we
do need to handle the h_source and h_dest fields.
I'll respin with these fields added.
Thanks for the review,
Maxime
[PATCH net-next] net: ethtool: Allow parsing ETHER_FLOW types when using flow_rule
When parsing an ethtool_rx_flow_spec, users can specify an ethernet flow
which could contain matches based on the ethernet header, such as the
MAC address, the VLAN tag or the ethertype.
Only the ethtype field is specific to the ether flow, the MAC and vlan
fields are processed using the special FLOW_EXT and FLOW_MAC_EXT flags.
Signed-off-by: Maxime Chevallier
---
net/core/ethtool.c | 12
1 file changed, 12 insertions(+)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 4d1011b2e24f..01ceba556341 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -2883,6 +2883,18 @@ ethtool_rx_flow_rule_create(const struct
ethtool_rx_flow_spec_input *input)
match->mask.basic.n_proto = htons(0x);
switch (fs->flow_type & ~(FLOW_EXT | FLOW_MAC_EXT | FLOW_RSS)) {
+ case ETHER_FLOW: {
+ const struct ethhdr *ether_spec, *ether_m_spec;
+
+ ether_spec = >h_u.ether_spec;
+ ether_m_spec = >m_u.ether_spec;
+
+ if (ether_m_spec->h_proto) {
+ match->key.basic.n_proto = ether_spec->h_proto;
+ match->mask.basic.n_proto = ether_m_spec->h_proto;
+ }
+ }
+ break;
case TCP_V4_FLOW:
case UDP_V4_FLOW: {
const struct ethtool_tcpip4_spec *v4_spec, *v4_m_spec;
--
2.20.1
Re: [PATCH net v2] net: mvpp2: prs: Don't override the sign bit in SRAM parser shift
Hello David,
On Thu, 20 Jun 2019 11:42:45 +0200
Maxime Chevallier wrote:
>The Header Parser allows identifying various fields in the packet
>headers, used for various kind of filtering and classification
>steps.
>
>This is a re-entrant process, where the offset in the packet header
>depends on the previous lookup results. This offset is represented in
>the SRAM results of the TCAM, as a shift to be operated.
>
>This shift can be negative in some cases, such as in IPv6 parsing.
>
>This commit prevents overriding the sign bit when setting the shift
>value, which could cause instabilities when parsing IPv6 flows.
>
>Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network
>unit")
>Suggested-by: Alan Winkowski
>Signed-off-by: Maxime Chevallier
>---
>V2 : Fix a typo in the commit log, reported by Sergei.
I see that this patch was set as "Accepted" on patchwork, but hasn't
made it to -net, I was wondering if this patch slipped through the
cracks :)
https://patchwork.ozlabs.org/patch/1119311/
Thanks,
Maxime
[PATCH net v2] net: mvpp2: prs: Don't override the sign bit in SRAM parser shift
The Header Parser allows identifying various fields in the packet
headers, used for various kind of filtering and classification
steps.
This is a re-entrant process, where the offset in the packet header
depends on the previous lookup results. This offset is represented in
the SRAM results of the TCAM, as a shift to be operated.
This shift can be negative in some cases, such as in IPv6 parsing.
This commit prevents overriding the sign bit when setting the shift
value, which could cause instabilities when parsing IPv6 flows.
Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network
unit")
Suggested-by: Alan Winkowski
Signed-off-by: Maxime Chevallier
---
V2 : Fix a typo in the commit log, reported by Sergei.
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
index ae2240074d8e..5692c6087bbb 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
@@ -312,7 +312,8 @@ static void mvpp2_prs_sram_shift_set(struct mvpp2_prs_entry
*pe, int shift,
}
/* Set value */
- pe->sram[MVPP2_BIT_TO_WORD(MVPP2_PRS_SRAM_SHIFT_OFFS)] = shift &
MVPP2_PRS_SRAM_SHIFT_MASK;
+ pe->sram[MVPP2_BIT_TO_WORD(MVPP2_PRS_SRAM_SHIFT_OFFS)] |=
+ shift & MVPP2_PRS_SRAM_SHIFT_MASK;
/* Reset and set operation */
mvpp2_prs_sram_bits_clear(pe, MVPP2_PRS_SRAM_OP_SEL_SHIFT_OFFS,
--
2.20.1
[PATCH net] net: mvpp2: prs: Don't override the sign bit in SRAM parser shift
The Header Parser allows identifying various fields in the packet
headers, used for for various kind of filtering and classification
steps.
This is a re-entrant process, where the offset in the packet header
depends on the previous lookup results. This offset is represented in
the SRAM results of the TCAM, as a shift to be operated.
This shift can be negative in some cases, such as in IPv6 parsing.
This commit prevents overriding the sign bit when setting the shift
value, which could cause instabilities when parsing IPv6 flows.
Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network
unit")
Suggested-by: Alan Winkowski
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
index ae2240074d8e..5692c6087bbb 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
@@ -312,7 +312,8 @@ static void mvpp2_prs_sram_shift_set(struct mvpp2_prs_entry
*pe, int shift,
}
/* Set value */
- pe->sram[MVPP2_BIT_TO_WORD(MVPP2_PRS_SRAM_SHIFT_OFFS)] = shift &
MVPP2_PRS_SRAM_SHIFT_MASK;
+ pe->sram[MVPP2_BIT_TO_WORD(MVPP2_PRS_SRAM_SHIFT_OFFS)] |=
+ shift & MVPP2_PRS_SRAM_SHIFT_MASK;
/* Reset and set operation */
mvpp2_prs_sram_bits_clear(pe, MVPP2_PRS_SRAM_OP_SEL_SHIFT_OFFS,
--
2.20.1
Re: [PATCH] net: mvpp2: cls: Add pmap to fs dump
Hello Nathan, On Tue, 18 Jun 2019 09:09:10 -0700 Nathan Huckleberry wrote: >There was an unused variable 'mvpp2_dbgfs_prs_pmap_fops' >Added a usage consistent with other fops to dump pmap >to userspace. Thanks for sending a fix. Besides the typo preventing your patch from compiling, you should also prefix the patch by "net: mvpp2: debugfs:" rather than "cls", which is used for classifier patches. Thanks, Maxime
[PATCH net-next 4/4] net: mvpp2: cls: Add steering based on vlan Id and priority.
This commit allows using the vlan Id and priority as parts of the key
for classification offload. These fields are extracted from the
outermost tag, if multiple tags are present.
Vlan Id and priority are considered as 2 different fields by the
classifier, however the fields are both appended in the Header Extracted
Key in the same layout as they are found in the tags. This means that
when steering only based on the prio, a 16-bit slot is still taken in
the HEK.
The classifier doesn't allow extracting the DEI bit from the tag, so we
explicitly prevent user from using this bit in the key.
This commit adds the vlan priotity as a compatible HEK field for
tagged traffic, meaning that we limit the possibility of extracting this
field only to the flows that contain tagged traffic.
Signed-off-by: Maxime Chevallier
---
.../net/ethernet/marvell/mvpp2/mvpp2_cls.c| 97 ++-
.../net/ethernet/marvell/mvpp2/mvpp2_cls.h| 23 +++--
2 files changed, 86 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
index c4c467f5f4f6..b195fb5d61f4 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
@@ -44,17 +44,17 @@ static const struct mvpp2_cls_flow
cls_flows[MVPP2_N_PRS_FLOWS] = {
/* TCP over IPv4 flows, Not fragmented, with vlan tag */
MVPP2_DEF_FLOW(MVPP22_FLOW_TCP4, MVPP2_FL_IP4_TCP_NF_TAG,
- MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_OPT_VLAN,
+ MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_TAGGED,
MVPP2_PRS_RI_L3_IP4 | MVPP2_PRS_RI_L4_TCP,
MVPP2_PRS_IP_MASK),
MVPP2_DEF_FLOW(MVPP22_FLOW_TCP4, MVPP2_FL_IP4_TCP_NF_TAG,
- MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_OPT_VLAN,
+ MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_TAGGED,
MVPP2_PRS_RI_L3_IP4_OPT | MVPP2_PRS_RI_L4_TCP,
MVPP2_PRS_IP_MASK),
MVPP2_DEF_FLOW(MVPP22_FLOW_TCP4, MVPP2_FL_IP4_TCP_NF_TAG,
- MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_OPT_VLAN,
+ MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_TAGGED,
MVPP2_PRS_RI_L3_IP4_OTHER | MVPP2_PRS_RI_L4_TCP,
MVPP2_PRS_IP_MASK),
@@ -79,17 +79,17 @@ static const struct mvpp2_cls_flow
cls_flows[MVPP2_N_PRS_FLOWS] = {
/* TCP over IPv4 flows, fragmented, with vlan tag */
MVPP2_DEF_FLOW(MVPP22_FLOW_TCP4, MVPP2_FL_IP4_TCP_FRAG_TAG,
- MVPP22_CLS_HEK_IP4_2T | MVPP22_CLS_HEK_OPT_VLAN,
+ MVPP22_CLS_HEK_IP4_2T | MVPP22_CLS_HEK_TAGGED,
MVPP2_PRS_RI_L3_IP4 | MVPP2_PRS_RI_L4_TCP,
MVPP2_PRS_IP_MASK),
MVPP2_DEF_FLOW(MVPP22_FLOW_TCP4, MVPP2_FL_IP4_TCP_FRAG_TAG,
- MVPP22_CLS_HEK_IP4_2T | MVPP22_CLS_HEK_OPT_VLAN,
+ MVPP22_CLS_HEK_IP4_2T | MVPP22_CLS_HEK_TAGGED,
MVPP2_PRS_RI_L3_IP4_OPT | MVPP2_PRS_RI_L4_TCP,
MVPP2_PRS_IP_MASK),
MVPP2_DEF_FLOW(MVPP22_FLOW_TCP4, MVPP2_FL_IP4_TCP_FRAG_TAG,
- MVPP22_CLS_HEK_IP4_2T | MVPP22_CLS_HEK_OPT_VLAN,
+ MVPP22_CLS_HEK_IP4_2T | MVPP22_CLS_HEK_TAGGED,
MVPP2_PRS_RI_L3_IP4_OTHER | MVPP2_PRS_RI_L4_TCP,
MVPP2_PRS_IP_MASK),
@@ -114,17 +114,17 @@ static const struct mvpp2_cls_flow
cls_flows[MVPP2_N_PRS_FLOWS] = {
/* UDP over IPv4 flows, Not fragmented, with vlan tag */
MVPP2_DEF_FLOW(MVPP22_FLOW_UDP4, MVPP2_FL_IP4_UDP_NF_TAG,
- MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_OPT_VLAN,
+ MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_TAGGED,
MVPP2_PRS_RI_L3_IP4 | MVPP2_PRS_RI_L4_UDP,
MVPP2_PRS_IP_MASK),
MVPP2_DEF_FLOW(MVPP22_FLOW_UDP4, MVPP2_FL_IP4_UDP_NF_TAG,
- MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_OPT_VLAN,
+ MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_TAGGED,
MVPP2_PRS_RI_L3_IP4_OPT | MVPP2_PRS_RI_L4_UDP,
MVPP2_PRS_IP_MASK),
MVPP2_DEF_FLOW(MVPP22_FLOW_UDP4, MVPP2_FL_IP4_UDP_NF_TAG,
- MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_OPT_VLAN,
+ MVPP22_CLS_HEK_IP4_5T | MVPP22_CLS_HEK_TAGGED,
MVPP2_PRS_RI_L3_IP4_OTHER | MVPP2_PRS_RI_L4_UDP,
MVPP2_PRS_IP_MASK),
@@ -149,17 +149,17 @@ static const struct mvpp2_cls_flow
cls_flows[MVPP2_N_PRS_FLOWS] = {
/* UDP over IPv4 flows, fragmented, with vlan tag */
MVPP2_DEF_FLOW(MVPP22_FLOW_UDP4, MVPP2_FL_IP4_UDP_FRAG_TAG,
- MVPP22_CLS_HEK_IP4_2T | MVPP22_CLS_HEK_OPT_VLAN,
+ MVPP22_CLS_HEK_IP4_2T
[PATCH net-next 0/4] net: mvpp2: cls: Allow steering based on vlan tag
The PPv2 classifier can perform flow steering based on keys extracted from the VLAN tag. This series adds support for using the vlan id and the vlan prio as keys, using the ethtool interface. Patch 1 is a preparatory patch that prevent false-positive matches, using a dedicated lookup id for the RSS C2 lookup. Patch 2 allows to separate the flows based on the header fields they contain. The main goal is to be able to separate tagged traffic from untagged traffic for flow steering, just as we already do for RSS. Patch 3 solves an issue we have when extracting fields that aren't full bytes, such as the vlan tag which is 12 bits wide, or the priority which is 3 bits wide. Finally, patch 4 adds support for steering based on both vlan id and priority, extracted from the outermost tag. Maxime Chevallier (4): net: mvpp2: cls: Use a dedicated lu_type for the RSS lookup net: mvpp2: cls: Only select applicable flows of classification offload net: mvpp2: cls: right-justify the C2 TCAM keys net: mvpp2: cls: Add steering based on vlan Id and priority. .../net/ethernet/marvell/mvpp2/mvpp2_cls.c| 118 +- .../net/ethernet/marvell/mvpp2/mvpp2_cls.h| 28 +++-- 2 files changed, 103 insertions(+), 43 deletions(-) -- 2.20.1
[PATCH net-next 2/4] net: mvpp2: cls: Only select applicable flows of classification offload
The way we currently handle classification offload and RSS is by having dedicated lookup sequences in the flow table, each being selected depending on several fields being present in the packet header. We need to make sure the classification operation we want to perform can be done in each flow we want to insert it into. As an example, classifying on VLAN tag can only be done on flows used for tagged traffic. This commit makes sure we don't insert rules in flows we aren't compatible with. Signed-off-by: Maxime Chevallier --- drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c index 8af13316ecb1..7cd9d6da0319 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c @@ -1201,6 +1201,9 @@ static int mvpp2_port_flt_rfs_rule_insert(struct mvpp2_port *port, if (!flow) return 0; + if ((rule->hek_fields & flow->supported_hash_opts) != rule->hek_fields) + continue; + index = MVPP2_CLS_FLT_C2_RFS(port->id, flow->flow_id, rule->loc); mvpp2_cls_flow_read(priv, index, ); -- 2.20.1
[PATCH net-next 3/4] net: mvpp2: cls: right-justify the C2 TCAM keys
The C2 TCAM used for classification uses a key (Header Extracted Key)
built by concatenating several fields extracted from the packet header.
After a lot of trial-and-error and some guess work, it seems the HEK is
right justified, with the first fields being stored in the MSB, then
concatenated up until the LSB.
Until now, this doesn't cause any issue since all HEK fields we use are
full bytes. However this is an issue for the upcoming VLAN id and pri
extraction, which aren't full bytes.
Rework the way we built that TCAM key, by changing the order in which we
append the fields.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
index 7cd9d6da0319..c4c467f5f4f6 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
@@ -1081,13 +1081,13 @@ static int mvpp2_port_c2_tcam_rule_add(struct
mvpp2_port *port,
rule->c2_index = c2.index;
- c2.tcam[0] = (rule->c2_tcam & 0x) |
+ c2.tcam[3] = (rule->c2_tcam & 0x) |
((rule->c2_tcam_mask & 0x) << 16);
- c2.tcam[1] = ((rule->c2_tcam >> 16) & 0x) |
+ c2.tcam[2] = ((rule->c2_tcam >> 16) & 0x) |
(((rule->c2_tcam_mask >> 16) & 0x) << 16);
- c2.tcam[2] = ((rule->c2_tcam >> 32) & 0x) |
+ c2.tcam[1] = ((rule->c2_tcam >> 32) & 0x) |
(((rule->c2_tcam_mask >> 32) & 0x) << 16);
- c2.tcam[3] = ((rule->c2_tcam >> 48) & 0x) |
+ c2.tcam[0] = ((rule->c2_tcam >> 48) & 0x) |
(((rule->c2_tcam_mask >> 48) & 0x) << 16);
pmap = BIT(port->id);
@@ -1222,7 +1222,7 @@ static int mvpp2_port_flt_rfs_rule_insert(struct
mvpp2_port *port,
static int mvpp2_cls_c2_build_match(struct mvpp2_rfs_rule *rule)
{
struct flow_rule *flow = rule->flow;
- int offs = 64;
+ int offs = 0;
if (flow_rule_match_key(flow, FLOW_DISSECTOR_KEY_PORTS)) {
struct flow_match_ports match;
@@ -1230,18 +1230,18 @@ static int mvpp2_cls_c2_build_match(struct
mvpp2_rfs_rule *rule)
flow_rule_match_ports(flow, );
if (match.mask->src) {
rule->hek_fields |= MVPP22_CLS_HEK_OPT_L4SIP;
- offs -=
mvpp2_cls_hek_field_size(MVPP22_CLS_HEK_OPT_L4SIP);
rule->c2_tcam |= ((u64)ntohs(match.key->src)) << offs;
rule->c2_tcam_mask |= ((u64)ntohs(match.mask->src)) <<
offs;
+ offs +=
mvpp2_cls_hek_field_size(MVPP22_CLS_HEK_OPT_L4SIP);
}
if (match.mask->dst) {
rule->hek_fields |= MVPP22_CLS_HEK_OPT_L4DIP;
- offs -=
mvpp2_cls_hek_field_size(MVPP22_CLS_HEK_OPT_L4DIP);
rule->c2_tcam |= ((u64)ntohs(match.key->dst)) << offs;
rule->c2_tcam_mask |= ((u64)ntohs(match.mask->dst)) <<
offs;
+ offs +=
mvpp2_cls_hek_field_size(MVPP22_CLS_HEK_OPT_L4DIP);
}
}
--
2.20.1
[PATCH net-next 1/4] net: mvpp2: cls: Use a dedicated lu_type for the RSS lookup
When performing a TCAM lookup in the C2 engine, it's possible that
multiple entries match the packet. To make sure the correct entry match
when performing a lookup, the Flow Table can set a lookup type, which
will be used in the TCAM lookup, thus preventing such false-positives.
We need to make sure the RSS match doesn't interfere with other
classification lookups, hence we use a dedicated lookup_type for it.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 4 ++--
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h | 5 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
index e47c00c5f829..8af13316ecb1 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
@@ -596,7 +596,7 @@ static void mvpp2_cls_flow_init(struct mvpp2 *priv,
mvpp2_cls_flow_eng_set(, MVPP22_CLS_ENGINE_C2);
mvpp2_cls_flow_port_id_sel(, true);
- mvpp2_cls_flow_lu_type_set(, MVPP22_FLOW_ETHERNET);
+ mvpp2_cls_flow_lu_type_set(, MVPP22_CLS_LU_TYPE_ALL);
/* Add all ports */
for (i = 0; i < MVPP2_MAX_PORTS; i++)
@@ -861,7 +861,7 @@ static void mvpp2_port_c2_cls_init(struct mvpp2_port *port)
/* Match on Lookup Type */
c2.tcam[4] |=
MVPP22_CLS_C2_TCAM_EN(MVPP22_CLS_C2_LU_TYPE(MVPP2_CLS_LU_TYPE_MASK));
- c2.tcam[4] |= MVPP22_CLS_C2_LU_TYPE(MVPP22_FLOW_ETHERNET);
+ c2.tcam[4] |= MVPP22_CLS_C2_LU_TYPE(MVPP22_CLS_LU_TYPE_ALL);
/* Update RSS status after matching this entry */
c2.act = MVPP22_CLS_C2_ACT_RSS_EN(MVPP22_C2_UPD_LOCK);
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h
index 26cc1176e758..957f80b31743 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h
@@ -180,6 +180,11 @@ enum mvpp2_prs_flow {
/* LU Type defined for all engines, and specified in the flow table */
#define MVPP2_CLS_LU_TYPE_MASK 0x3f
+enum mvpp2_cls_lu_type {
+ /* rule->loc is used as a lu-type for the entries 0 - 62. */
+ MVPP22_CLS_LU_TYPE_ALL = 63,
+};
+
#define MVPP2_N_FLOWS (MVPP2_FL_LAST - MVPP2_FL_START)
struct mvpp2_cls_flow {
--
2.20.1
[PATCH net v2] net: ethtool: Allow matching on vlan DEI bit
Using ethtool, users can specify a classification action matching on the
full vlan tag, which includes the DEI bit (also previously called CFI).
However, when converting the ethool_flow_spec to a flow_rule, we use
dissector keys to represent the matching patterns.
Since the vlan dissector key doesn't include the DEI bit, this
information was silently discarded when translating the ethtool
flow spec in to a flow_rule.
This commit adds the DEI bit into the vlan dissector key, and allows
propagating the information to the driver when parsing the ethtool flow
spec.
Fixes: eca4205f9ec3 ("ethtool: add ethtool_rx_flow_spec to flow_rule structure
translator")
Reported-by: Michał Mirosław
Signed-off-by: Maxime Chevallier
---
V1 -> V2: Use "DEI" instead of the old name "CFI", as suggested by Toshiaki.
Perform endianness swap on the constant, sothat it's done at
build-time, as suggested by Jakub.
include/net/flow_dissector.h | 1 +
net/core/ethtool.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
index 7c5a8d9a8d2a..dfabc0503446 100644
--- a/include/net/flow_dissector.h
+++ b/include/net/flow_dissector.h
@@ -46,6 +46,7 @@ struct flow_dissector_key_tags {
struct flow_dissector_key_vlan {
u16 vlan_id:12,
+ vlan_dei:1,
vlan_priority:3;
__be16 vlan_tpid;
};
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index d08b1e19ce9c..4d1011b2e24f 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -3020,6 +3020,11 @@ ethtool_rx_flow_rule_create(const struct
ethtool_rx_flow_spec_input *input)
match->mask.vlan.vlan_id =
ntohs(ext_m_spec->vlan_tci) & 0x0fff;
+ match->key.vlan.vlan_dei =
+ !!(ext_h_spec->vlan_tci & htons(0x1000));
+ match->mask.vlan.vlan_dei =
+ !!(ext_m_spec->vlan_tci & htons(0x1000));
+
match->key.vlan.vlan_priority =
(ntohs(ext_h_spec->vlan_tci) & 0xe000) >> 13;
match->mask.vlan.vlan_priority =
--
2.20.1
[PATCH net] net: ethtool: Allow matching on vlan CFI bit
Using ethtool, users can specify a classification action matching on the
full vlan tag, which includes the CFI bit.
However, when converting the ethool_flow_spec to a flow_rule, we use
dissector keys to represent the matching patterns.
Since the vlan dissector key doesn't include the CFI bit, this
information was silently discarded when translating the ethtool
flow spec in to a flow_rule.
This commit adds the CFI bit into the vlan dissector key, and allows
propagating the information to the driver when parsing the ethtool flow
spec.
Fixes: eca4205f9ec3 ("ethtool: add ethtool_rx_flow_spec to flow_rule structure
translator")
Reported-by: Michał Mirosław
Signed-off-by: Maxime Chevallier
---
Hi all,
Although this prevents information to be silently discarded when parsing
an ethtool_flow_spec, this information doesn't seem to be used by any
driver that converts an ethtool_flow_spec to a flow_rule, hence I'm not
sure this is suitable for -net.
Thanks,
Maxime
include/net/flow_dissector.h | 1 +
net/core/ethtool.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
index 7c5a8d9a8d2a..9d2e395c6568 100644
--- a/include/net/flow_dissector.h
+++ b/include/net/flow_dissector.h
@@ -46,6 +46,7 @@ struct flow_dissector_key_tags {
struct flow_dissector_key_vlan {
u16 vlan_id:12,
+ vlan_cfi:1,
vlan_priority:3;
__be16 vlan_tpid;
};
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index d08b1e19ce9c..43df34c1ebe1 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -3020,6 +3020,11 @@ ethtool_rx_flow_rule_create(const struct
ethtool_rx_flow_spec_input *input)
match->mask.vlan.vlan_id =
ntohs(ext_m_spec->vlan_tci) & 0x0fff;
+ match->key.vlan.vlan_cfi =
+ !!(ntohs(ext_h_spec->vlan_tci) & 0x1000);
+ match->mask.vlan.vlan_cfi =
+ !!(ntohs(ext_m_spec->vlan_tci) & 0x1000);
+
match->key.vlan.vlan_priority =
(ntohs(ext_h_spec->vlan_tci) & 0xe000) >> 13;
match->mask.vlan.vlan_priority =
--
2.20.1
[PATCH net 2/2] net: mvpp2: prs: Use the correct helpers when removing all VID filters
When removing all VID filters, the mvpp2_prs_vid_entry_remove would be
called with the TCAM id incorrectly used as a VID, causing the wrong
TCAM entries to be invalidated.
Fix this by directly invalidating entries in the VID range.
Fixes: 56beda3db602 ("net: mvpp2: Add hardware offloading for VLAN filtering")
Suggested-by: Yuri Chipchev
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
index e0da4db3bf56..ae2240074d8e 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
@@ -2025,8 +2025,10 @@ void mvpp2_prs_vid_remove_all(struct mvpp2_port *port)
for (tid = MVPP2_PRS_VID_PORT_FIRST(port->id);
tid <= MVPP2_PRS_VID_PORT_LAST(port->id); tid++) {
- if (priv->prs_shadow[tid].valid)
- mvpp2_prs_vid_entry_remove(port, tid);
+ if (priv->prs_shadow[tid].valid) {
+ mvpp2_prs_hw_inv(priv, tid);
+ priv->prs_shadow[tid].valid = false;
+ }
}
}
--
2.20.1
[PATCH net 0/2] net: mvpp2: prs: Fixes for VID filtering
This series fixes some issues with VID filtering offload, mainly due to the wrong ranges being used in the TCAM header parser. The first patch fixes a bug where removing a VLAN from a port's whitelist would also remove it from other port's, if they are on the same PPv2 instance. The second patch makes so that we don't invalidate the wrong TCAM entries when clearing the whole whitelist. Maxime Chevallier (2): net: mvpp2: prs: Fix parser range for VID filtering net: mvpp2: prs: Use the correct helpers when removing all VID filters .../net/ethernet/marvell/mvpp2/mvpp2_prs.c| 23 ++- 1 file changed, 12 insertions(+), 11 deletions(-) -- 2.20.1
[PATCH net 1/2] net: mvpp2: prs: Fix parser range for VID filtering
VID filtering is implemented in the Header Parser, with one range of 11
vids being assigned for each no-loopback port.
Make sure we use the per-port range when looking for existing entries in
the Parser.
Since we used a global range instead of a per-port one, this causes VIDs
to be removed from the whitelist from all ports of the same PPv2
instance.
Fixes: 56beda3db602 ("net: mvpp2: Add hardware offloading for VLAN filtering")
Suggested-by: Yuri Chipchev
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
index 392fd895f278..e0da4db3bf56 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
@@ -1905,8 +1905,7 @@ static int mvpp2_prs_ip6_init(struct mvpp2 *priv)
}
/* Find tcam entry with matched pair */
-static int mvpp2_prs_vid_range_find(struct mvpp2 *priv, int pmap, u16 vid,
- u16 mask)
+static int mvpp2_prs_vid_range_find(struct mvpp2_port *port, u16 vid, u16 mask)
{
unsigned char byte[2], enable[2];
struct mvpp2_prs_entry pe;
@@ -1914,13 +1913,13 @@ static int mvpp2_prs_vid_range_find(struct mvpp2 *priv,
int pmap, u16 vid,
int tid;
/* Go through the all entries with MVPP2_PRS_LU_VID */
- for (tid = MVPP2_PE_VID_FILT_RANGE_START;
-tid <= MVPP2_PE_VID_FILT_RANGE_END; tid++) {
- if (!priv->prs_shadow[tid].valid ||
- priv->prs_shadow[tid].lu != MVPP2_PRS_LU_VID)
+ for (tid = MVPP2_PRS_VID_PORT_FIRST(port->id);
+tid <= MVPP2_PRS_VID_PORT_LAST(port->id); tid++) {
+ if (!port->priv->prs_shadow[tid].valid ||
+ port->priv->prs_shadow[tid].lu != MVPP2_PRS_LU_VID)
continue;
- mvpp2_prs_init_from_hw(priv, , tid);
+ mvpp2_prs_init_from_hw(port->priv, , tid);
mvpp2_prs_tcam_data_byte_get(, 2, [0], [0]);
mvpp2_prs_tcam_data_byte_get(, 3, [1], [1]);
@@ -1950,7 +1949,7 @@ int mvpp2_prs_vid_entry_add(struct mvpp2_port *port, u16
vid)
memset(, 0, sizeof(pe));
/* Scan TCAM and see if entry with this already exist */
- tid = mvpp2_prs_vid_range_find(priv, (1 << port->id), vid, mask);
+ tid = mvpp2_prs_vid_range_find(port, vid, mask);
reg_val = mvpp2_read(priv, MVPP2_MH_REG(port->id));
if (reg_val & MVPP2_DSA_EXTENDED)
@@ -2008,7 +2007,7 @@ void mvpp2_prs_vid_entry_remove(struct mvpp2_port *port,
u16 vid)
int tid;
/* Scan TCAM and see if entry with this already exist */
- tid = mvpp2_prs_vid_range_find(priv, (1 << port->id), vid, 0xfff);
+ tid = mvpp2_prs_vid_range_find(port, vid, 0xfff);
/* No such entry */
if (tid < 0)
--
2.20.1
Re: [PATCH net 1/2] net: mvpp2: prs: Fix parser range for VID filtering
Hello David, On Mon, 10 Jun 2019 09:23:00 -0700 (PDT) David Miller wrote: >Please start providing proper header postings with each and every patch >series, explaining at a high level what the patch series is doing, how >it is doing it, and why it is doing it that way. Sure, I'll resend with a proper cover-letter, sorry about that. Thanks, Maxime
[PATCH net 1/2] net: mvpp2: prs: Fix parser range for VID filtering
VID filtering is implemented in the Header Parser, with one range of 11
vids being assigned for each no-loopback port.
Make sure we use the per-port range when looking for existing entries in
the Parser.
Since we used a global range instead of a per-port one, this causes VIDs
to be removed from the whitelist from all ports of the same PPv2
instance.
Fixes: 56beda3db602 ("net: mvpp2: Add hardware offloading for VLAN filtering")
Suggested-by: Yuri Chipchev
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
index 392fd895f278..e0da4db3bf56 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
@@ -1905,8 +1905,7 @@ static int mvpp2_prs_ip6_init(struct mvpp2 *priv)
}
/* Find tcam entry with matched pair */
-static int mvpp2_prs_vid_range_find(struct mvpp2 *priv, int pmap, u16 vid,
- u16 mask)
+static int mvpp2_prs_vid_range_find(struct mvpp2_port *port, u16 vid, u16 mask)
{
unsigned char byte[2], enable[2];
struct mvpp2_prs_entry pe;
@@ -1914,13 +1913,13 @@ static int mvpp2_prs_vid_range_find(struct mvpp2 *priv,
int pmap, u16 vid,
int tid;
/* Go through the all entries with MVPP2_PRS_LU_VID */
- for (tid = MVPP2_PE_VID_FILT_RANGE_START;
-tid <= MVPP2_PE_VID_FILT_RANGE_END; tid++) {
- if (!priv->prs_shadow[tid].valid ||
- priv->prs_shadow[tid].lu != MVPP2_PRS_LU_VID)
+ for (tid = MVPP2_PRS_VID_PORT_FIRST(port->id);
+tid <= MVPP2_PRS_VID_PORT_LAST(port->id); tid++) {
+ if (!port->priv->prs_shadow[tid].valid ||
+ port->priv->prs_shadow[tid].lu != MVPP2_PRS_LU_VID)
continue;
- mvpp2_prs_init_from_hw(priv, , tid);
+ mvpp2_prs_init_from_hw(port->priv, , tid);
mvpp2_prs_tcam_data_byte_get(, 2, [0], [0]);
mvpp2_prs_tcam_data_byte_get(, 3, [1], [1]);
@@ -1950,7 +1949,7 @@ int mvpp2_prs_vid_entry_add(struct mvpp2_port *port, u16
vid)
memset(, 0, sizeof(pe));
/* Scan TCAM and see if entry with this already exist */
- tid = mvpp2_prs_vid_range_find(priv, (1 << port->id), vid, mask);
+ tid = mvpp2_prs_vid_range_find(port, vid, mask);
reg_val = mvpp2_read(priv, MVPP2_MH_REG(port->id));
if (reg_val & MVPP2_DSA_EXTENDED)
@@ -2008,7 +2007,7 @@ void mvpp2_prs_vid_entry_remove(struct mvpp2_port *port,
u16 vid)
int tid;
/* Scan TCAM and see if entry with this already exist */
- tid = mvpp2_prs_vid_range_find(priv, (1 << port->id), vid, 0xfff);
+ tid = mvpp2_prs_vid_range_find(port, vid, 0xfff);
/* No such entry */
if (tid < 0)
--
2.20.1
[PATCH net 2/2] net: mvpp2: prs: Use the correct helpers when removing all VID filters
When removing all VID filters, the mvpp2_prs_vid_entry_remove would be
called with the TCAM id incorrectly used as a VID, causing the wrong
TCAM entries to be invalidated.
Fix this by directly invalidating entries in the VID range.
Fixes: 56beda3db602 ("net: mvpp2: Add hardware offloading for VLAN filtering")
Suggested-by: Yuri Chipchev
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
index e0da4db3bf56..ae2240074d8e 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
@@ -2025,8 +2025,10 @@ void mvpp2_prs_vid_remove_all(struct mvpp2_port *port)
for (tid = MVPP2_PRS_VID_PORT_FIRST(port->id);
tid <= MVPP2_PRS_VID_PORT_LAST(port->id); tid++) {
- if (priv->prs_shadow[tid].valid)
- mvpp2_prs_vid_entry_remove(port, tid);
+ if (priv->prs_shadow[tid].valid) {
+ mvpp2_prs_hw_inv(priv, tid);
+ priv->prs_shadow[tid].valid = false;
+ }
}
}
--
2.20.1
[PATCH net-next 3/3] net: mvpp2: Add support for more ethtool counters
Besides the MIB counters, some other useful counters can be exposed to
the user. This commit adds support for :
- Per-port counters, that indicate FIFO drops and classifier drops,
- Per-rxq counters,
- Per-txq counters
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h| 18 +++
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 132 +++---
2 files changed, 132 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index d67c970f02e5..4d9564ba68f6 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -329,8 +329,26 @@
#define MVPP22_BM_ADDR_HIGH_VIRT_RLS_MASK 0xff00
#define MVPP22_BM_ADDR_HIGH_VIRT_RLS_SHIFT 8
+/* Packet Processor per-port counters */
+#define MVPP2_OVERRUN_ETH_DROP 0x7000
+#define MVPP2_CLS_ETH_DROP 0x7020
+
/* Hit counters registers */
#define MVPP2_CTRS_IDX 0x7040
+#define MVPP22_CTRS_TX_CTR(port, txq) ((txq) | ((port) << 3) | BIT(7))
+#define MVPP2_TX_DESC_ENQ_CTR 0x7100
+#define MVPP2_TX_DESC_ENQ_TO_DDR_CTR 0x7104
+#define MVPP2_TX_BUFF_ENQ_TO_DDR_CTR 0x7108
+#define MVPP2_TX_DESC_ENQ_HW_FWD_CTR 0x710c
+#define MVPP2_RX_DESC_ENQ_CTR 0x7120
+#define MVPP2_TX_PKTS_DEQ_CTR 0x7130
+#define MVPP2_TX_PKTS_FULL_QUEUE_DROP_CTR 0x7200
+#define MVPP2_TX_PKTS_EARLY_DROP_CTR 0x7204
+#define MVPP2_TX_PKTS_BM_DROP_CTR 0x7208
+#define MVPP2_TX_PKTS_BM_MC_DROP_CTR 0x720c
+#define MVPP2_RX_PKTS_FULL_QUEUE_DROP_CTR 0x7220
+#define MVPP2_RX_PKTS_EARLY_DROP_CTR 0x7224
+#define MVPP2_RX_PKTS_BM_DROP_CTR 0x7228
#define MVPP2_CLS_DEC_TBL_HIT_CTR 0x7700
#define MVPP2_CLS_FLOW_TBL_HIT_CTR 0x7704
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 01380ccb2139..c51f1d5b550b 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1258,6 +1258,17 @@ static u64 mvpp2_read_count(struct mvpp2_port *port,
return val;
}
+/* Some counters are accessed indirectly by first writing an index to
+ * MVPP2_CTRS_IDX. The index can represent various resources depending on the
+ * register we access, it can be a hit counter for some classification tables,
+ * a counter specific to a rxq, a txq or a buffer pool.
+ */
+static u32 mvpp2_read_index(struct mvpp2 *priv, u32 index, u32 reg)
+{
+ mvpp2_write(priv, MVPP2_CTRS_IDX, index);
+ return mvpp2_read(priv, reg);
+}
+
/* Due to the fact that software statistics and hardware statistics are, by
* design, incremented at different moments in the chain of packet processing,
* it is very likely that incoming packets could have been dropped after being
@@ -1297,32 +1308,114 @@ static const struct mvpp2_ethtool_counter
mvpp2_ethtool_mib_regs[] = {
{ MVPP2_MIB_LATE_COLLISION, "late_collision" },
};
+static const struct mvpp2_ethtool_counter mvpp2_ethtool_port_regs[] = {
+ { MVPP2_OVERRUN_ETH_DROP, "rx_fifo_or_parser_overrun_drops" },
+ { MVPP2_CLS_ETH_DROP, "rx_classifier_drops" },
+};
+
+static const struct mvpp2_ethtool_counter mvpp2_ethtool_txq_regs[] = {
+ { MVPP2_TX_DESC_ENQ_CTR, "txq_%d_desc_enqueue" },
+ { MVPP2_TX_DESC_ENQ_TO_DDR_CTR, "txq_%d_desc_enqueue_to_ddr" },
+ { MVPP2_TX_BUFF_ENQ_TO_DDR_CTR, "txq_%d_buff_euqueue_to_ddr" },
+ { MVPP2_TX_DESC_ENQ_HW_FWD_CTR, "txq_%d_desc_hardware_forwarded" },
+ { MVPP2_TX_PKTS_DEQ_CTR, "txq_%d_packets_dequeued" },
+ { MVPP2_TX_PKTS_FULL_QUEUE_DROP_CTR, "txq_%d_queue_full_drops" },
+ { MVPP2_TX_PKTS_EARLY_DROP_CTR, "txq_%d_packets_early_drops" },
+ { MVPP2_TX_PKTS_BM_DROP_CTR, "txq_%d_packets_bm_drops" },
+ { MVPP2_TX_PKTS_BM_MC_DROP_CTR, "txq_%d_packets_rep_bm_drops" },
+};
+
+static const struct mvpp2_ethtool_counter mvpp2_ethtool_rxq_regs[] = {
+ { MVPP2_RX_DESC_ENQ_CTR, "rxq_%d_desc_enqueue" },
+ { MVPP2_RX_PKTS_FULL_QUEUE_DROP_CTR, "rxq_%d_queue_full_drops" },
+ { MVPP2_RX_PKTS_EARLY_DROP_CTR, "rxq_%d_packets_early_drops" },
+ { MVPP2_RX_PKTS_BM_DROP_CTR, "rxq_%d_packets_bm_drops" },
+};
+
+#define MVPP2_N_ETHTOOL_STATS(ntxqs, nrxqs)
(ARRAY_SIZE(mvpp2_ethtool_mib_regs) + \
+
ARRAY_SIZE(mvpp2_ethtool_port_regs) + \
+
(ARRAY_SIZE(mvpp2_ethtool_txq_regs) * (ntxqs)) + \
+
(ARRAY_SIZE(mvpp2_ethtool_rxq_regs) * (nrxqs)))
+
static void mvpp2
[PATCH net-next 1/3] net: mvpp2: Only clear the stat counters at port init
When first configuring a port on PPv2, we want to clear the internal
counters so that we don't get values from previous boot stages.
However, we can't really clear these counters when resetting the MAC,
since there are valid reasons to do so while the port is being used,
such as when reconfiguring the interface mode with the PHY.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 4b4d79611339..ee653125194e 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1359,13 +1359,8 @@ static int mvpp2_ethtool_get_sset_count(struct
net_device *dev, int sset)
static void mvpp2_mac_reset_assert(struct mvpp2_port *port)
{
- unsigned int i;
u32 val;
- /* Read the GOP statistics to reset the hardware counters */
- for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_regs); i++)
- mvpp2_read_count(port, _ethtool_regs[i]);
-
val = readl(port->base + MVPP2_GMAC_CTRL_2_REG) |
MVPP2_GMAC_PORT_RESET_MASK;
writel(val, port->base + MVPP2_GMAC_CTRL_2_REG);
@@ -4265,7 +4260,7 @@ static int mvpp2_port_init(struct mvpp2_port *port)
struct mvpp2 *priv = port->priv;
struct mvpp2_txq_pcpu *txq_pcpu;
unsigned int thread;
- int queue, err;
+ int queue, err, i;
/* Checks for hardware constraints */
if (port->first_rxq + port->nrxqs >
@@ -4372,6 +4367,10 @@ static int mvpp2_port_init(struct mvpp2_port *port)
if (err)
goto err_free_percpu;
+ /* Read the GOP statistics to reset the hardware counters */
+ for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_regs); i++)
+ mvpp2_read_count(port, _ethtool_regs[i]);
+
return 0;
err_free_percpu:
--
2.20.1
[PATCH net-next 2/3] net: mvpp2: Rename mvpp2_ethtool_counters to mvpp2_ethtool_mib_counters
Since we'll be adding support for other kind of internal counters, make
clear that the currently supported counters are the MIB counters.
Signed-off-by: Maxime Chevallier
---
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 21 ++-
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index ee653125194e..01380ccb2139 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1267,7 +1267,7 @@ static u64 mvpp2_read_count(struct mvpp2_port *port,
* Hence, statistics gathered from userspace with ifconfig (software) and
* ethtool (hardware) cannot be compared.
*/
-static const struct mvpp2_ethtool_counter mvpp2_ethtool_regs[] = {
+static const struct mvpp2_ethtool_counter mvpp2_ethtool_mib_regs[] = {
{ MVPP2_MIB_GOOD_OCTETS_RCVD, "good_octets_received", true },
{ MVPP2_MIB_BAD_OCTETS_RCVD, "bad_octets_received" },
{ MVPP2_MIB_CRC_ERRORS_SENT, "crc_errors_sent" },
@@ -1303,9 +1303,10 @@ static void mvpp2_ethtool_get_strings(struct net_device
*netdev, u32 sset,
if (sset == ETH_SS_STATS) {
int i;
- for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_regs); i++)
+ for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_mib_regs); i++)
strscpy(data + i * ETH_GSTRING_LEN,
- mvpp2_ethtool_regs[i].string, ETH_GSTRING_LEN);
+ mvpp2_ethtool_mib_regs[i].string,
+ ETH_GSTRING_LEN);
}
}
@@ -1320,8 +1321,8 @@ static void mvpp2_gather_hw_statistics(struct work_struct
*work)
mutex_lock(>gather_stats_lock);
pstats = port->ethtool_stats;
- for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_regs); i++)
- *pstats++ += mvpp2_read_count(port, _ethtool_regs[i]);
+ for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_mib_regs); i++)
+ *pstats++ += mvpp2_read_count(port, _ethtool_mib_regs[i]);
/* No need to read again the counters right after this function if it
* was called asynchronously by the user (ie. use of ethtool).
@@ -1345,14 +1346,14 @@ static void mvpp2_ethtool_get_stats(struct net_device
*dev,
mutex_lock(>gather_stats_lock);
memcpy(data, port->ethtool_stats,
- sizeof(u64) * ARRAY_SIZE(mvpp2_ethtool_regs));
+ sizeof(u64) * ARRAY_SIZE(mvpp2_ethtool_mib_regs));
mutex_unlock(>gather_stats_lock);
}
static int mvpp2_ethtool_get_sset_count(struct net_device *dev, int sset)
{
if (sset == ETH_SS_STATS)
- return ARRAY_SIZE(mvpp2_ethtool_regs);
+ return ARRAY_SIZE(mvpp2_ethtool_mib_regs);
return -EOPNOTSUPP;
}
@@ -4368,8 +4369,8 @@ static int mvpp2_port_init(struct mvpp2_port *port)
goto err_free_percpu;
/* Read the GOP statistics to reset the hardware counters */
- for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_regs); i++)
- mvpp2_read_count(port, _ethtool_regs[i]);
+ for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_mib_regs); i++)
+ mvpp2_read_count(port, _ethtool_mib_regs[i]);
return 0;
@@ -5052,7 +5053,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
}
port->ethtool_stats = devm_kcalloc(>dev,
- ARRAY_SIZE(mvpp2_ethtool_regs),
+ ARRAY_SIZE(mvpp2_ethtool_mib_regs),
sizeof(u64), GFP_KERNEL);
if (!port->ethtool_stats) {
err = -ENOMEM;
--
2.20.1
[PATCH net-next 0/3] net: mvpp2: Add extra ethtool stats
This series adds support for more ethtool counters in PPv2 : - Per port counters, including one indicating the classifier drops - Per RXQ and per TXQ counters The first 2 patches perform some light rework and renaming, and the 3rd adds the extra counters. Maxime Chevallier (3): net: mvpp2: Only clear the stat counters at port init net: mvpp2: Rename mvpp2_ethtool_counters to mvpp2_ethtool_mib_counters net: mvpp2: Add support for more ethtool counters drivers/net/ethernet/marvell/mvpp2/mvpp2.h| 18 +++ .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 134 +++--- 2 files changed, 133 insertions(+), 19 deletions(-) -- 2.20.1
[PATCH net] net: mvpp2: Use strscpy to handle stat strings
Use a safe strscpy call to copy the ethtool stat strings into the
relevant buffers, instead of a memcpy that will be accessing
out-of-bound data.
Fixes: 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics")
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 7a67e23a2c2b..d8e5241097a9 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -1304,8 +1304,8 @@ static void mvpp2_ethtool_get_strings(struct net_device
*netdev, u32 sset,
int i;
for (i = 0; i < ARRAY_SIZE(mvpp2_ethtool_regs); i++)
- memcpy(data + i * ETH_GSTRING_LEN,
- _ethtool_regs[i].string, ETH_GSTRING_LEN);
+ strscpy(data + i * ETH_GSTRING_LEN,
+ mvpp2_ethtool_regs[i].string, ETH_GSTRING_LEN);
}
}
--
2.20.1
[PATCH net] ethtool: Check for vlan etype or vlan tci when parsing flow_rule
When parsing an ethtool flow spec to build a flow_rule, the code checks
if both the vlan etype and the vlan tci are specified by the user to add
a FLOW_DISSECTOR_KEY_VLAN match.
However, when the user only specified a vlan etype or a vlan tci, this
check silently ignores these parameters.
For example, the following rule :
ethtool -N eth0 flow-type udp4 vlan 0x0010 action -1 loc 0
will result in no error being issued, but the equivalent rule will be
created and passed to the NIC driver :
ethtool -N eth0 flow-type udp4 action -1 loc 0
In the end, neither the NIC driver using the rule nor the end user have
a way to know that these keys were dropped along the way, or that
incorrect parameters were entered.
This kind of check should be left to either the driver, or the ethtool
flow spec layer.
This commit makes so that ethtool parameters are forwarded as-is to the
NIC driver.
Since none of the users of ethtool_rx_flow_rule_create are using the
VLAN dissector, I don't think this qualifies as a regression.
Fixes: eca4205f9ec3 ("ethtool: add ethtool_rx_flow_spec to flow_rule structure
translator")
Signed-off-by: Maxime Chevallier
---
This patch was previously sent as :
"ethtool: Drop check for vlan etype and vlan tci when parsing flow_rule"
Following Pablo's review, we don't drop the check anymore, hence the
more fitting subject.
net/core/ethtool.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 4a593853cbf2..43e9add58340 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -3010,11 +3010,12 @@ ethtool_rx_flow_rule_create(const struct
ethtool_rx_flow_spec_input *input)
const struct ethtool_flow_ext *ext_h_spec = >h_ext;
const struct ethtool_flow_ext *ext_m_spec = >m_ext;
- if (ext_m_spec->vlan_etype &&
- ext_m_spec->vlan_tci) {
+ if (ext_m_spec->vlan_etype) {
match->key.vlan.vlan_tpid = ext_h_spec->vlan_etype;
match->mask.vlan.vlan_tpid = ext_m_spec->vlan_etype;
+ }
+ if (ext_m_spec->vlan_tci) {
match->key.vlan.vlan_id =
ntohs(ext_h_spec->vlan_tci) & 0x0fff;
match->mask.vlan.vlan_id =
@@ -3024,7 +3025,10 @@ ethtool_rx_flow_rule_create(const struct
ethtool_rx_flow_spec_input *input)
(ntohs(ext_h_spec->vlan_tci) & 0xe000) >> 13;
match->mask.vlan.vlan_priority =
(ntohs(ext_m_spec->vlan_tci) & 0xe000) >> 13;
+ }
+ if (ext_m_spec->vlan_etype ||
+ ext_m_spec->vlan_tci) {
match->dissector.used_keys |=
BIT(FLOW_DISSECTOR_KEY_VLAN);
match->dissector.offset[FLOW_DISSECTOR_KEY_VLAN] =
--
2.20.1
[PATCH net v2] ethtool: Drop check for vlan etype and vlan tci when parsing flow_rule
When parsing an ethtool flow spec to build a flow_rule, the code checks
if both the vlan etype and the vlan tci are specified by the user to add
a FLOW_DISSECTOR_KEY_VLAN match.
However, when the user only specified a vlan etype or a vlan tci, this
check silently ignores these parameters.
For example, the following rule :
ethtool -N eth0 flow-type udp4 vlan 0x0010 action -1 loc 0
will result in no error being issued, but the equivalent rule will be
created and passed to the NIC driver :
ethtool -N eth0 flow-type udp4 action -1 loc 0
In the end, neither the NIC driver using the rule nor the end user have
a way to know that these keys were dropped along the way, or that
incorrect parameters were entered.
This kind of check should be left to either the driver, or the ethtool
flow spec layer.
This commit makes so that ethtool parameters are forwarded as-is to the
NIC driver.
Since none of the users of ethtool_rx_flow_rule_create are using the
VLAN dissector, I don't think this qualifies as a regression.
Fixes: eca4205f9ec3 ("ethtool: add ethtool_rx_flow_spec to flow_rule structure
translator")
Signed-off-by: Maxime Chevallier
---
V2: Added Fixes: tag, targetted to -net.
net/core/ethtool.c | 31 ++-
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 4a593853cbf2..2fe86893e9b5 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -3010,26 +3010,23 @@ ethtool_rx_flow_rule_create(const struct
ethtool_rx_flow_spec_input *input)
const struct ethtool_flow_ext *ext_h_spec = >h_ext;
const struct ethtool_flow_ext *ext_m_spec = >m_ext;
- if (ext_m_spec->vlan_etype &&
- ext_m_spec->vlan_tci) {
- match->key.vlan.vlan_tpid = ext_h_spec->vlan_etype;
- match->mask.vlan.vlan_tpid = ext_m_spec->vlan_etype;
+ match->key.vlan.vlan_tpid = ext_h_spec->vlan_etype;
+ match->mask.vlan.vlan_tpid = ext_m_spec->vlan_etype;
- match->key.vlan.vlan_id =
- ntohs(ext_h_spec->vlan_tci) & 0x0fff;
- match->mask.vlan.vlan_id =
- ntohs(ext_m_spec->vlan_tci) & 0x0fff;
+ match->key.vlan.vlan_id =
+ ntohs(ext_h_spec->vlan_tci) & 0x0fff;
+ match->mask.vlan.vlan_id =
+ ntohs(ext_m_spec->vlan_tci) & 0x0fff;
- match->key.vlan.vlan_priority =
- (ntohs(ext_h_spec->vlan_tci) & 0xe000) >> 13;
- match->mask.vlan.vlan_priority =
- (ntohs(ext_m_spec->vlan_tci) & 0xe000) >> 13;
+ match->key.vlan.vlan_priority =
+ (ntohs(ext_h_spec->vlan_tci) & 0xe000) >> 13;
+ match->mask.vlan.vlan_priority =
+ (ntohs(ext_m_spec->vlan_tci) & 0xe000) >> 13;
- match->dissector.used_keys |=
- BIT(FLOW_DISSECTOR_KEY_VLAN);
- match->dissector.offset[FLOW_DISSECTOR_KEY_VLAN] =
- offsetof(struct ethtool_rx_flow_key, vlan);
- }
+ match->dissector.used_keys |=
+ BIT(FLOW_DISSECTOR_KEY_VLAN);
+ match->dissector.offset[FLOW_DISSECTOR_KEY_VLAN] =
+ offsetof(struct ethtool_rx_flow_key, vlan);
}
if (fs->flow_type & FLOW_MAC_EXT) {
const struct ethtool_flow_ext *ext_h_spec = >h_ext;
--
2.20.1
Re: [PATCH net-next] ethtool: Drop check for vlan etype and vlan tci when parsing flow_rule
On Wed, 29 May 2019 16:10:44 +0200 Maxime Chevallier wrote: >When parsing an ethtool flow spec to build a flow_rule, the code checks >if both the vlan etype and the vlan tci are specified by the user to add >a FLOW_DISSECTOR_KEY_VLAN match. > >However, when the user only specified a vlan etype or a vlan tci, this >check silently ignores these parameters. > >For example, the following rule : > >ethtool -N eth0 flow-type udp4 vlan 0x0010 action -1 loc 0 > >will result in no error being issued, but the equivalent rule will be >created and passed to the NIC driver : > >ethtool -N eth0 flow-type udp4 action -1 loc 0 > >In the end, neither the NIC driver using the rule nor the end user have >a way to know that these keys were dropped along the way, or that >incorrect parameters were entered. > >This kind of check should be left to either the driver, or the ethtool >flow spec layer. > >This commit makes so that ethtool parameters are forwarded as-is to the >NIC driver. > >Since none of the users of ethtool_rx_flow_rule_create are using the >VLAN dissector, I don't think this qualifies as a regression. > >Signed-off-by: Maxime Chevallier I should have targeted this to -net, and provided a Fixes tag. Let me resend that to the proper tree. Sorry about the noise, Maxime
[PATCH net-next] ethtool: Drop check for vlan etype and vlan tci when parsing flow_rule
When parsing an ethtool flow spec to build a flow_rule, the code checks
if both the vlan etype and the vlan tci are specified by the user to add
a FLOW_DISSECTOR_KEY_VLAN match.
However, when the user only specified a vlan etype or a vlan tci, this
check silently ignores these parameters.
For example, the following rule :
ethtool -N eth0 flow-type udp4 vlan 0x0010 action -1 loc 0
will result in no error being issued, but the equivalent rule will be
created and passed to the NIC driver :
ethtool -N eth0 flow-type udp4 action -1 loc 0
In the end, neither the NIC driver using the rule nor the end user have
a way to know that these keys were dropped along the way, or that
incorrect parameters were entered.
This kind of check should be left to either the driver, or the ethtool
flow spec layer.
This commit makes so that ethtool parameters are forwarded as-is to the
NIC driver.
Since none of the users of ethtool_rx_flow_rule_create are using the
VLAN dissector, I don't think this qualifies as a regression.
Signed-off-by: Maxime Chevallier
---
net/core/ethtool.c | 31 ++-
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 4a593853cbf2..2fe86893e9b5 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -3010,26 +3010,23 @@ ethtool_rx_flow_rule_create(const struct
ethtool_rx_flow_spec_input *input)
const struct ethtool_flow_ext *ext_h_spec = >h_ext;
const struct ethtool_flow_ext *ext_m_spec = >m_ext;
- if (ext_m_spec->vlan_etype &&
- ext_m_spec->vlan_tci) {
- match->key.vlan.vlan_tpid = ext_h_spec->vlan_etype;
- match->mask.vlan.vlan_tpid = ext_m_spec->vlan_etype;
+ match->key.vlan.vlan_tpid = ext_h_spec->vlan_etype;
+ match->mask.vlan.vlan_tpid = ext_m_spec->vlan_etype;
- match->key.vlan.vlan_id =
- ntohs(ext_h_spec->vlan_tci) & 0x0fff;
- match->mask.vlan.vlan_id =
- ntohs(ext_m_spec->vlan_tci) & 0x0fff;
+ match->key.vlan.vlan_id =
+ ntohs(ext_h_spec->vlan_tci) & 0x0fff;
+ match->mask.vlan.vlan_id =
+ ntohs(ext_m_spec->vlan_tci) & 0x0fff;
- match->key.vlan.vlan_priority =
- (ntohs(ext_h_spec->vlan_tci) & 0xe000) >> 13;
- match->mask.vlan.vlan_priority =
- (ntohs(ext_m_spec->vlan_tci) & 0xe000) >> 13;
+ match->key.vlan.vlan_priority =
+ (ntohs(ext_h_spec->vlan_tci) & 0xe000) >> 13;
+ match->mask.vlan.vlan_priority =
+ (ntohs(ext_m_spec->vlan_tci) & 0xe000) >> 13;
- match->dissector.used_keys |=
- BIT(FLOW_DISSECTOR_KEY_VLAN);
- match->dissector.offset[FLOW_DISSECTOR_KEY_VLAN] =
- offsetof(struct ethtool_rx_flow_key, vlan);
- }
+ match->dissector.used_keys |=
+ BIT(FLOW_DISSECTOR_KEY_VLAN);
+ match->dissector.offset[FLOW_DISSECTOR_KEY_VLAN] =
+ offsetof(struct ethtool_rx_flow_key, vlan);
}
if (fs->flow_type & FLOW_MAC_EXT) {
const struct ethtool_flow_ext *ext_h_spec = >h_ext;
--
2.20.1
[PATCH net-next] net: mvpp2: cls: Check RSS table index validity when creating a context
Make sure we don't use an out-of-bound index for the per-port RSS context array. As of today, the global context creation in mvpp22_rss_context_create will prevent us from reaching this case, but we should still make sure we are using a sane value anyway. Reported-by: kbuild test robot Reported-by: Dan Carpenter Signed-off-by: Maxime Chevallier --- drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c index cd0daad011ce..bd19a910dc90 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c @@ -1466,6 +1466,9 @@ int mvpp22_port_rss_ctx_create(struct mvpp2_port *port, u32 *port_ctx) break; } + if (i == MVPP22_N_RSS_TABLES) + return -EINVAL; + port->rss_ctx[i] = rss_ctx; *port_ctx = i; -- 2.20.1
[PATCH net-next 0/5] net: mvpp2: Classifier updates, RSS
Hello everyone, Here is a set of updates for the PPv2 classifier, the main feature being the support for steering to RSS contexts, to leverage all the available RSS tables in the controller. The first two patches are non-critical fixes for the classifier, the first one prevents us from allocating too much room to store the classification rules, the second one configuring the C2 engine as suggested by the PPv2 functionnal specs. Patches 3 to 5 introduce support for RSS contexts in mvpp2, allowing us to steer traffic to dedicated RSS tables. Thanks, Maxime Maxime Chevallier (5): net: mvpp2: cls: Use the correct number of rules in various places net: mvpp2: cls: Bypass C2 internals FIFOs at init net: mvpp2: cls: Use RSS contexts to handle RSS tables net: mvpp2: cls: Extract the RSS context when parsing the ethtool rule net: mvpp2: cls: Support steering to RSS contexts drivers/net/ethernet/marvell/mvpp2/mvpp2.h| 20 +- .../net/ethernet/marvell/mvpp2/mvpp2_cls.c| 272 -- .../net/ethernet/marvell/mvpp2/mvpp2_cls.h| 15 +- .../net/ethernet/marvell/mvpp2/mvpp2_main.c | 67 - 4 files changed, 326 insertions(+), 48 deletions(-) -- 2.20.1
[PATCH net-next 5/5] net: mvpp2: cls: Support steering to RSS contexts
When steering to an RXQ, we can perform an extra RSS step to assign a
queue from an RSS table.
This is done by setting the RSS_EN attribute in the C2 engine. In that
case, the RXQ that is assigned is the global RSS context id, that is
then translated to an RSS table using the RXQ2RSS table.
An example using ethtool to steer to RXQ 2 and 3 would be :
ethtool -X eth0 weight 0 0 1 1 context new
(This would print the allocated context id, let's say it's 1)
ethtool -N eth0 flow-type udp4 dst-port 1234 context 1 loc 0
The hash parameters are the ones that are globally configured for RSS :
ethtool -N eth0 rx-flow-hash udp4 sdfn
When an RSS context is removed while there are active classification
rules using this context, these rules are removed.
Signed-off-by: Maxime Chevallier
---
.../net/ethernet/marvell/mvpp2/mvpp2_cls.c| 58 +--
1 file changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
index c1a83e9cb80a..cd0daad011ce 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
@@ -1068,7 +1068,7 @@ static int mvpp2_port_c2_tcam_rule_add(struct mvpp2_port
*port,
struct flow_action_entry *act;
struct mvpp2_cls_c2_entry c2;
u8 qh, ql, pmap;
- int index;
+ int index, ctx;
memset(, 0, sizeof(c2));
@@ -1108,14 +1108,36 @@ static int mvpp2_port_c2_tcam_rule_add(struct
mvpp2_port *port,
*/
c2.act = MVPP22_CLS_C2_ACT_COLOR(MVPP22_C2_COL_NO_UPD_LOCK);
+ /* Update RSS status after matching this entry */
+ if (act->queue.ctx)
+ c2.attr[2] |= MVPP22_CLS_C2_ATTR2_RSS_EN;
+
+ /* Always lock the RSS_EN decision. We might have high prio
+* rules steering to an RXQ, and a lower one steering to RSS,
+* we don't want the low prio RSS rule overwriting this flag.
+*/
+ c2.act = MVPP22_CLS_C2_ACT_RSS_EN(MVPP22_C2_UPD_LOCK);
+
/* Mark packet as "forwarded to software", needed for RSS */
c2.act |= MVPP22_CLS_C2_ACT_FWD(MVPP22_C2_FWD_SW_LOCK);
c2.act |= MVPP22_CLS_C2_ACT_QHIGH(MVPP22_C2_UPD_LOCK) |
MVPP22_CLS_C2_ACT_QLOW(MVPP22_C2_UPD_LOCK);
- qh = ((act->queue.index + port->first_rxq) >> 3) &
MVPP22_CLS_C2_ATTR0_QHIGH_MASK;
- ql = (act->queue.index + port->first_rxq) &
MVPP22_CLS_C2_ATTR0_QLOW_MASK;
+ if (act->queue.ctx) {
+ /* Get the global ctx number */
+ ctx = mvpp22_rss_ctx(port, act->queue.ctx);
+ if (ctx < 0)
+ return -EINVAL;
+
+ qh = (ctx >> 3) & MVPP22_CLS_C2_ATTR0_QHIGH_MASK;
+ ql = ctx & MVPP22_CLS_C2_ATTR0_QLOW_MASK;
+ } else {
+ qh = ((act->queue.index + port->first_rxq) >> 3) &
+ MVPP22_CLS_C2_ATTR0_QHIGH_MASK;
+ ql = (act->queue.index + port->first_rxq) &
+ MVPP22_CLS_C2_ATTR0_QLOW_MASK;
+ }
c2.attr[0] = MVPP22_CLS_C2_ATTR0_QHIGH(qh) |
MVPP22_CLS_C2_ATTR0_QLOW(ql);
@@ -1235,6 +1257,13 @@ static int mvpp2_cls_rfs_parse_rule(struct
mvpp2_rfs_rule *rule)
if (act->id != FLOW_ACTION_QUEUE && act->id != FLOW_ACTION_DROP)
return -EOPNOTSUPP;
+ /* When both an RSS context and an queue index are set, the index
+* is considered as an offset to be added to the indirection table
+* entries. We don't support this, so reject this rule.
+*/
+ if (act->queue.ctx && act->queue.index)
+ return -EOPNOTSUPP;
+
/* For now, only use the C2 engine which has a HEK size limited to 64
* bits for TCAM matching.
*/
@@ -1455,11 +1484,32 @@ static struct mvpp2_rss_table
*mvpp22_rss_table_get(struct mvpp2 *priv,
int mvpp22_port_rss_ctx_delete(struct mvpp2_port *port, u32 port_ctx)
{
struct mvpp2 *priv = port->priv;
- int rss_ctx = mvpp22_rss_ctx(port, port_ctx);
+ struct ethtool_rxnfc *rxnfc;
+ int i, rss_ctx, ret;
+
+ rss_ctx = mvpp22_rss_ctx(port, port_ctx);
if (rss_ctx < 0 || rss_ctx >= MVPP22_N_RSS_TABLES)
return -EINVAL;
+ /* Invalidate any active classification rule that use this context */
+ for (i = 0; i < MVPP2_N_RFS_ENTRIES_PER_FLOW; i++) {
+ if (!port->rfs_rules[i])
+ continue;
+
+ rxnfc = >rfs_rules[i]->rxnfc;
+ if (!(rxnfc
[PATCH net-next 1/5] net: mvpp2: cls: Use the correct number of rules in various places
As of today, the classification offload implementation only supports 4
different rules to be offloaded. This number has been hardcoded in the
rule insertion function, and the wrong define is being used elsewhere.
Use the correct #define everywhere to make sure we always check for the
correct number of rules.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 2 +-
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 4 ++--
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 6171270a016c..d5df813e08c4 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -923,7 +923,7 @@ struct mvpp2_port {
u32 indir[MVPP22_RSS_TABLE_ENTRIES];
/* List of steering rules active on that port */
- struct mvpp2_ethtool_fs *rfs_rules[MVPP2_N_RFS_RULES];
+ struct mvpp2_ethtool_fs *rfs_rules[MVPP2_N_RFS_ENTRIES_PER_FLOW];
int n_rfs_rules;
};
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
index d046f7a1dcf5..9ce73297276e 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
@@ -1212,7 +1212,7 @@ int mvpp2_ethtool_cls_rule_get(struct mvpp2_port *port,
{
struct mvpp2_ethtool_fs *efs;
- if (rxnfc->fs.location >= MVPP2_N_RFS_RULES)
+ if (rxnfc->fs.location >= MVPP2_N_RFS_ENTRIES_PER_FLOW)
return -EINVAL;
efs = port->rfs_rules[rxnfc->fs.location];
@@ -1232,7 +1232,7 @@ int mvpp2_ethtool_cls_rule_ins(struct mvpp2_port *port,
struct mvpp2_ethtool_fs *efs, *old_efs;
int ret = 0;
- if (info->fs.location >= 4 ||
+ if (info->fs.location >= MVPP2_N_RFS_ENTRIES_PER_FLOW ||
info->fs.location < 0)
return -EINVAL;
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index d38952eb7aa9..8432315447dd 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3956,7 +3956,7 @@ static int mvpp2_ethtool_get_rxnfc(struct net_device *dev,
ret = mvpp2_ethtool_cls_rule_get(port, info);
break;
case ETHTOOL_GRXCLSRLALL:
- for (i = 0; i < MVPP2_N_RFS_RULES; i++) {
+ for (i = 0; i < MVPP2_N_RFS_ENTRIES_PER_FLOW; i++) {
if (port->rfs_rules[i])
rules[loc++] = i;
}
--
2.20.1
[PATCH net-next 2/5] net: mvpp2: cls: Bypass C2 internals FIFOs at init
The C2 TCAM has internal FIFOs that are only useful for the built-in self-tests. Disable these FIFOS at init, as recommended in the functionnal specs. Suggested-by: Alan Winkowski Signed-off-by: Maxime Chevallier --- drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 2 ++ drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 6 ++ 2 files changed, 8 insertions(+) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h index d5df813e08c4..bb466af9434b 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h @@ -148,6 +148,8 @@ #define MVPP22_CLS_C2_ATTR20x1b6c #define MVPP22_CLS_C2_ATTR2_RSS_EN BIT(30) #define MVPP22_CLS_C2_ATTR30x1b70 +#define MVPP22_CLS_C2_TCAM_CTRL0x1b90 +#define MVPP22_CLS_C2_TCAM_BYPASS_FIFO BIT(0) /* Descriptor Manager Top Registers */ #define MVPP2_RXQ_NUM_REG 0x2040 diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c index 9ce73297276e..d549e9a29d9a 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c @@ -923,6 +923,12 @@ void mvpp2_cls_init(struct mvpp2 *priv) mvpp2_cls_c2_write(priv, ); } + /* Disable the FIFO stages in C2 engine, which are only used in BIST +* mode +*/ + mvpp2_write(priv, MVPP22_CLS_C2_TCAM_CTRL, + MVPP22_CLS_C2_TCAM_BYPASS_FIFO); + mvpp2_cls_port_init_flows(priv); } -- 2.20.1
[PATCH net-next 3/5] net: mvpp2: cls: Use RSS contexts to handle RSS tables
The PPv2 controller has 8 RSS tables that are shared across all ports on
a given PPv2 instance. The previous implementation allocated one table
per port, leaving others unused.
By using RSS contexts, we can make use of multiple RSS tables per
port, one being the default table (always id 0), the other ones being
used as destinations for flow steering, in the same way as rx rings.
This commit introduces RSS contexts management in the PPv2 driver. We
always reserve one table per port, allocated when the port is probed.
The global table list is stored in the struct mvpp2, as it's a global
resource. Each port then maintains a list of indices in that global
table, that way each port can have it's own numbering scheme starting
from 0.
One limitation that seems unavoidable is that the hashing parameters are
shared across all RSS contexts for a given port. Hashing parameters for
ctx 0 will be applied to all contexts.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h| 16 +-
.../net/ethernet/marvell/mvpp2/mvpp2_cls.c| 200 +++---
.../net/ethernet/marvell/mvpp2/mvpp2_cls.h| 15 +-
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 65 +-
4 files changed, 255 insertions(+), 41 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index bb466af9434b..18ae8d06b692 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -626,6 +626,7 @@
#define MVPP2_N_RFS_RULES (MVPP2_N_RFS_ENTRIES_PER_FLOW * 7)
/* RSS constants */
+#define MVPP22_N_RSS_TABLES8
#define MVPP22_RSS_TABLE_ENTRIES 32
/* IPv6 max L3 address size */
@@ -727,6 +728,10 @@ enum mvpp2_prs_l3_cast {
/* Definitions */
struct mvpp2_dbgfs_entries;
+struct mvpp2_rss_table {
+ u32 indir[MVPP22_RSS_TABLE_ENTRIES];
+};
+
/* Shared Packet Processor resources */
struct mvpp2 {
/* Shared registers' base addresses */
@@ -790,6 +795,9 @@ struct mvpp2 {
/* Debugfs entries private data */
struct mvpp2_dbgfs_entries *dbgfs_entries;
+
+ /* RSS Indirection tables */
+ struct mvpp2_rss_table *rss_tables[MVPP22_N_RSS_TABLES];
};
struct mvpp2_pcpu_stats {
@@ -921,12 +929,14 @@ struct mvpp2_port {
u32 tx_time_coal;
- /* RSS indirection table */
- u32 indir[MVPP22_RSS_TABLE_ENTRIES];
-
/* List of steering rules active on that port */
struct mvpp2_ethtool_fs *rfs_rules[MVPP2_N_RFS_ENTRIES_PER_FLOW];
int n_rfs_rules;
+
+ /* Each port has its own view of the rss contexts, so that it can number
+* them from 0
+*/
+ int rss_ctx[MVPP22_N_RSS_TABLES];
};
/* The mvpp2_tx_desc and mvpp2_rx_desc structures describe the
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
index d549e9a29d9a..c16e343ccbbf 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
@@ -969,12 +969,22 @@ u32 mvpp2_cls_c2_hit_count(struct mvpp2 *priv, int
c2_index)
return mvpp2_read(priv, MVPP22_CLS_C2_HIT_CTR);
}
-static void mvpp2_rss_port_c2_enable(struct mvpp2_port *port)
+static void mvpp2_rss_port_c2_enable(struct mvpp2_port *port, u32 ctx)
{
struct mvpp2_cls_c2_entry c2;
+ u8 qh, ql;
mvpp2_cls_c2_read(port->priv, MVPP22_CLS_C2_RSS_ENTRY(port->id), );
+ /* The RxQ number is used to select the RSS table. It that case, we set
+* it to be the ctx number.
+*/
+ qh = (ctx >> 3) & MVPP22_CLS_C2_ATTR0_QHIGH_MASK;
+ ql = ctx & MVPP22_CLS_C2_ATTR0_QLOW_MASK;
+
+ c2.attr[0] = MVPP22_CLS_C2_ATTR0_QHIGH(qh) |
+MVPP22_CLS_C2_ATTR0_QLOW(ql);
+
c2.attr[2] |= MVPP22_CLS_C2_ATTR2_RSS_EN;
mvpp2_cls_c2_write(port->priv, );
@@ -983,22 +993,45 @@ static void mvpp2_rss_port_c2_enable(struct mvpp2_port
*port)
static void mvpp2_rss_port_c2_disable(struct mvpp2_port *port)
{
struct mvpp2_cls_c2_entry c2;
+ u8 qh, ql;
mvpp2_cls_c2_read(port->priv, MVPP22_CLS_C2_RSS_ENTRY(port->id), );
+ /* Reset the default destination RxQ to the port's first rx queue. */
+ qh = (port->first_rxq >> 3) & MVPP22_CLS_C2_ATTR0_QHIGH_MASK;
+ ql = port->first_rxq & MVPP22_CLS_C2_ATTR0_QLOW_MASK;
+
+ c2.attr[0] = MVPP22_CLS_C2_ATTR0_QHIGH(qh) |
+ MVPP22_CLS_C2_ATTR0_QLOW(ql);
+
c2.attr[2] &= ~MVPP22_CLS_C2_ATTR2_RSS_EN;
mvpp2_cls_c2_write(port->priv, );
}
-void mvpp22_port_rss_enable(struct mvpp2_port *port)
+static inline int mvpp22_rss_ctx(struct mvpp2_port *port, int port_rss_ctx)
{
- mvpp2_rss_port_c2_enable(port);
+ return port->rss_ctx[port_rss_ctx];
}
-void mvpp22_port_rss_disable(struct mvpp2_port
[PATCH net-next 4/5] net: mvpp2: cls: Extract the RSS context when parsing the ethtool rule
ethtool_rx_flow_rule_create takes into parameter the ethtool flow spec,
which doesn't contain the rss context id. We therefore need to extract
it ourself before parsing the ethtool rule.
The FLOW_RSS flag is only set in info->fs.flow_type, and not
info->flow_type.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
index c16e343ccbbf..c1a83e9cb80a 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
@@ -1281,6 +1281,12 @@ int mvpp2_ethtool_cls_rule_ins(struct mvpp2_port *port,
input.fs = >fs;
+ /* We need to manually set the rss_ctx, since this info isn't present
+* in info->fs
+*/
+ if (info->fs.flow_type & FLOW_RSS)
+ input.rss_ctx = info->rss_context;
+
ethtool_rule = ethtool_rx_flow_rule_create();
if (IS_ERR(ethtool_rule)) {
ret = PTR_ERR(ethtool_rule);
--
2.20.1
[PATCH net-next] net: ethtool: Document get_rxfh_context and set_rxfh_context ethtool ops
ethtool ops get_rxfh_context and set_rxfh_context are used to create, remove and access parameters associated to RSS contexts, in a similar fashion to get_rxfh and set_rxfh. Add a small descritopn of these callbacks in the struct ethtool_ops doc. Signed-off-by: Maxime Chevallier --- include/linux/ethtool.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h index e6ebc9761822..95991e4300bf 100644 --- a/include/linux/ethtool.h +++ b/include/linux/ethtool.h @@ -260,6 +260,15 @@ bool ethtool_convert_link_mode_to_legacy_u32(u32 *legacy_u32, * will remain unchanged. * Returns a negative error code or zero. An error code must be returned * if at least one unsupported change was requested. + * @get_rxfh_context: Get the contents of the RX flow hash indirection table, + * hash key, and/or hash function assiciated to the given rss context. + * Returns a negative error code or zero. + * @set_rxfh_context: Create, remove and configure RSS contexts. Allows setting + * the contents of the RX flow hash indirection table, hash key, and/or + * hash function associated to the given context. Arguments which are set + * to %NULL or zero will remain unchanged. + * Returns a negative error code or zero. An error code must be returned + * if at least one unsupported change was requested. * @get_channels: Get number of channels. * @set_channels: Set number of channels. Returns a negative error code or * zero. -- 2.20.1
[PATCH net] net: mvpp2: cls: Fix leaked ethtool_rx_flow_rule
The flow_rule is only used when configuring the classification tables,
and should be free'd once we're done using it. The current code only
frees it in the error path.
Fixes: 90b509b39ac9 ("net: mvpp2: cls: Add Classification offload support")
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
index d046f7a1dcf5..a57d17ab91f0 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
@@ -1271,6 +1271,9 @@ int mvpp2_ethtool_cls_rule_ins(struct mvpp2_port *port,
if (ret)
goto clean_eth_rule;
+ ethtool_rx_flow_rule_destroy(ethtool_rule);
+ efs->rule.flow = NULL;
+
memcpy(>rxnfc, info, sizeof(*info));
port->rfs_rules[efs->rule.loc] = efs;
port->n_rfs_rules++;
--
2.20.1
[PATCH net-next 4/4] net: mvpp2: cls: Allow dropping packets with classification offload
This commit introduces support for the "Drop" action in classification
offload. This corresponds to the "-1" action with ethtool -N.
This is achieved using the color marking actions available in the C2
engine, which associate a color to a packet. These colors can be either
Green, Yellow or Red, Red meaning that the packet should be dropped.
Green and Yellow colors are interpreted by the Policer, which isn't
supported yet.
This method of dropping using the Classifier is different than the
already existing early-drop features, such as VLAN filtering and MAC
UC/MC filtering, which are performed during the Parsing step, and
therefore take precedence over classification actions.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h| 1 +
.../net/ethernet/marvell/mvpp2/mvpp2_cls.c| 29 +--
.../net/ethernet/marvell/mvpp2/mvpp2_cls.h| 11 +++
3 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 9dab60ae..6171270a016c 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -136,6 +136,7 @@
#define MVPP22_CLS_C2_ACT_FWD(act) (((act) & 0x7) << 13)
#define MVPP22_CLS_C2_ACT_QHIGH(act) (((act) & 0x3) << 11)
#define MVPP22_CLS_C2_ACT_QLOW(act)(((act) & 0x3) << 9)
+#define MVPP22_CLS_C2_ACT_COLOR(act) ((act) & 0x7)
#define MVPP22_CLS_C2_ATTR00x1b64
#define MVPP22_CLS_C2_ATTR0_QHIGH(qh) (((qh) & 0x1f) << 24)
#define MVPP22_CLS_C2_ATTR0_QHIGH_MASK 0x1f
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
index f4dd59c00d80..4989fb13244f 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.c
@@ -1057,17 +1057,28 @@ static int mvpp2_port_c2_tcam_rule_add(struct
mvpp2_port *port,
c2.tcam[4] |=
MVPP22_CLS_C2_TCAM_EN(MVPP22_CLS_C2_LU_TYPE(MVPP2_CLS_LU_TYPE_MASK));
c2.tcam[4] |= MVPP22_CLS_C2_LU_TYPE(rule->loc);
- /* Mark packet as "forwarded to software", needed for RSS */
- c2.act |= MVPP22_CLS_C2_ACT_FWD(MVPP22_C2_FWD_SW_LOCK);
+ if (act->id == FLOW_ACTION_DROP) {
+ c2.act = MVPP22_CLS_C2_ACT_COLOR(MVPP22_C2_COL_RED_LOCK);
+ } else {
+ /* We want to keep the default color derived from the Header
+* Parser drop entries, for VLAN and MAC filtering. This will
+* assign a default color of Green or Red, and we want matches
+* with a non-drop action to keep that color.
+*/
+ c2.act = MVPP22_CLS_C2_ACT_COLOR(MVPP22_C2_COL_NO_UPD_LOCK);
- c2.act |= MVPP22_CLS_C2_ACT_QHIGH(MVPP22_C2_UPD_LOCK) |
- MVPP22_CLS_C2_ACT_QLOW(MVPP22_C2_UPD_LOCK);
+ /* Mark packet as "forwarded to software", needed for RSS */
+ c2.act |= MVPP22_CLS_C2_ACT_FWD(MVPP22_C2_FWD_SW_LOCK);
- qh = ((act->queue.index + port->first_rxq) >> 3) &
MVPP22_CLS_C2_ATTR0_QHIGH_MASK;
- ql = (act->queue.index + port->first_rxq) &
MVPP22_CLS_C2_ATTR0_QLOW_MASK;
+ c2.act |= MVPP22_CLS_C2_ACT_QHIGH(MVPP22_C2_UPD_LOCK) |
+ MVPP22_CLS_C2_ACT_QLOW(MVPP22_C2_UPD_LOCK);
- c2.attr[0] = MVPP22_CLS_C2_ATTR0_QHIGH(qh) |
- MVPP22_CLS_C2_ATTR0_QLOW(ql);
+ qh = ((act->queue.index + port->first_rxq) >> 3) &
MVPP22_CLS_C2_ATTR0_QHIGH_MASK;
+ ql = (act->queue.index + port->first_rxq) &
MVPP22_CLS_C2_ATTR0_QLOW_MASK;
+
+ c2.attr[0] = MVPP22_CLS_C2_ATTR0_QHIGH(qh) |
+ MVPP22_CLS_C2_ATTR0_QLOW(ql);
+ }
c2.valid = true;
@@ -1183,7 +1194,7 @@ static int mvpp2_cls_rfs_parse_rule(struct mvpp2_rfs_rule
*rule)
struct flow_action_entry *act;
act = >action.entries[0];
- if (act->id != FLOW_ACTION_QUEUE)
+ if (act->id != FLOW_ACTION_QUEUE && act->id != FLOW_ACTION_DROP)
return -EOPNOTSUPP;
/* For now, only use the C2 engine which has a HEK size limited to 64
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h
index 431563a13524..56b617375a65 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_cls.h
@@ -92,6 +92,17 @@ enum mvpp22_cls_c2_fwd_action {
MVPP22_C2_FWD_HW_LOW_LAT_LOCK,
};
+enum mvpp22_cls_c2_color_action {
+ MVPP22_C2_COL_NO_UPD = 0,
+ MVPP22_C2_COL_NO_UPD_LOCK,
+ MVPP22_C2_COL_GREEN,
+ MVPP22_C2_COL_GREEN_LOCK,
+ MVPP22_C2_C
[PATCH net-next v2] net: mvpp2: cls: Add Classification offload support
This commit introduces basic classification offloading support for the
PPv2 controller.
The PPv2 classifier has many classification engines, for now we only use
the C2 TCAM match engine.
This engine allows to perform ternary lookups on 64 bits keys (called
Header Extracted Key), that are built by extracting fields from the packet
header and concatenating them. At most 4 fields can be extracted for a
single lookup.
This basic implementation allows to build the HEK from the following
fields :
- L4 source and destination ports (for UDP and TCP)
More fields are to be added in the future.
Classification flows are added through the ethtool interface, using the
newly introduced flow_rule infrastructure as an internal rule
representation, allowing to more easily implement tc flower rules if
need be.
Flows are separated based on their flow-type (supported flow-types are
tcp4, udp4, tcp6, udp6, ip4, ip6 and ether), each type can contain up to
7 classification rules. Note that the most specific flow-type is always
used, meaning that a rule in the tcp4 flow will superseed a rule in the
ip4 flow matching the same key)
When inserting a rule in a given flow, the location given is relative to
the flow :
ethtool -N eth0 flow-type udp4 dst-port 1234 action 2 loc 0
ethtool -N eth0 flow-type tcp4 dst-port 1234 action 3 loc 0
However when removing a rule, the global location is to be used. This
location can be retrieved by using ethtool -n .
This commit only introduces support for the "steer to rxq" action.
Signed-off-by: Maxime Chevallier
---
V2: - Re-arranged struct mvpp2_rfs_rule to minimize gaps on 64 bits systems,
as suggested by David.
- Fixed a smatch error indicating a possible out-of-bound array access
when accessing the internal list of rules.
- Other smatch warnings saying that some indices can't be negatived were
not fixed on purpose, even though no path leads to these indicies being
negative right now, future work could lead to cases where indices aren't
valid.
drivers/net/ethernet/marvell/mvpp2/mvpp2.h| 50 ++
.../net/ethernet/marvell/mvpp2/mvpp2_cls.c| 458 +-
.../net/ethernet/marvell/mvpp2/mvpp2_cls.h| 56 ++-
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 24 +-
4 files changed, 573 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
index 67cce2736806..dcb93afb6569 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/* Fifo Registers */
#define MVPP2_RX_DATA_FIFO_SIZE_REG(port) (0x00 + 4 * (port))
@@ -126,6 +127,7 @@
#define MVPP22_CLS_C2_TCAM_DATA4 0x1b20
#define MVPP22_CLS_C2_LU_TYPE(lu) ((lu) & 0x3f)
#define MVPP22_CLS_C2_PORT_ID(port)((port) << 8)
+#define MVPP22_CLS_C2_PORT_MASK(0xff << 8)
#define MVPP22_CLS_C2_TCAM_INV 0x1b24
#define MVPP22_CLS_C2_TCAM_INV_BIT BIT(31)
#define MVPP22_CLS_C2_HIT_CTR 0x1b50
@@ -615,6 +617,10 @@
#define MVPP2_BIT_IN_WORD(bit) ((bit) % 32)
#define MVPP2_N_PRS_FLOWS 52
+#define MVPP2_N_RFS_ENTRIES_PER_FLOW 7
+
+/* There are 7 supported high-level flows */
+#define MVPP2_N_RFS_RULES (MVPP2_N_RFS_ENTRIES_PER_FLOW * 7)
/* RSS constants */
#define MVPP22_RSS_TABLE_ENTRIES 32
@@ -812,6 +818,46 @@ struct mvpp2_queue_vector {
struct cpumask *mask;
};
+/* Internal represention of a Flow Steering rule */
+struct mvpp2_rfs_rule {
+ /* Rule location inside the flow*/
+ int loc;
+
+ /* Flow type, such as TCP_V4_FLOW, IP6_FLOW, etc. */
+ int flow_type;
+
+ /* The lookup type used by this flow. This allows the classification
+* engines to differentiate between entries that match the same
+* parameters
+*/
+ int lu_type;
+
+ /* Index of the entry handling this rule in the flow table */
+ int flt_index;
+
+ /* Index of the C2 TCAM entry handling this rule */
+ int c2_index;
+
+ /* Header fields that needs to be extracted to match this flow */
+ u16 hek_fields;
+
+ /* CLS engine : only c2 is supported for now. */
+ u8 engine;
+
+ /* TCAM key and mask for C2-based steering. These fields should be
+* encapsulated in a union should we add more engines.
+*/
+ u64 c2_tcam;
+ u64 c2_tcam_mask;
+
+ struct flow_rule *flow;
+};
+
+struct mvpp2_ethtool_fs {
+ struct mvpp2_rfs_rule rule;
+ struct ethtool_rxnfc rxnfc;
+};
+
struct mvpp2_port {
u8 id;
@@ -883,6 +929,10 @@ struct mvpp2_port {
/* RSS indirection table */
u32 indir[MVPP22_RSS_TABLE_ENTRIES];
+
+ /* List of steering rules active on that port */
+ struct m
[PATCH net] net: dsa: mv88e6xxx: power serdes on/off for 10G interfaces on 6390X
Upon setting the cmode on 6390 and 6390X, the associated serdes
interfaces must be powered off/on.
Both 6390X and 6390 share code to do so, but it currently uses the 6390
specific helper mv88e6390_serdes_power() to disable and enable the
serdes interface.
This call will fail silently on 6390X when trying so set a 10G interface
such as XAUI or RXAUI, since mv88e6390_serdes_power() internally grabs
the lane number based on modes supported by the 6390, and returns 0 when
getting -ENODEV as a lane number.
Using mv88e6390x_serdes_power() should be safe here, since we explicitly
rule-out all ports but the 9 and 10, and because modes supported by 6390
ports 9 and 10 are a subset of those supported on 6390X.
This was tested on 6390X using RXAUI mode.
Fixes: 364e9d7776a3 ("net: dsa: mv88e6xxx: Power on/off SERDES on cmode change")
Signed-off-by: Maxime Chevallier
---
drivers/net/dsa/mv88e6xxx/port.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index ebd26b6a93e6..4b02c96f6786 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -408,7 +408,7 @@ int mv88e6390x_port_set_cmode(struct mv88e6xxx_chip *chip,
int port,
return err;
}
- err = mv88e6390_serdes_power(chip, port, false);
+ err = mv88e6390x_serdes_power(chip, port, false);
if (err)
return err;
@@ -424,7 +424,7 @@ int mv88e6390x_port_set_cmode(struct mv88e6xxx_chip *chip,
int port,
if (err)
return err;
- err = mv88e6390_serdes_power(chip, port, true);
+ err = mv88e6390x_serdes_power(chip, port, true);
if (err)
return err;
--
2.19.2
[PATCH net-next 0/2] net: phy: marvell10g: Clean .get_features by using C45 helpers
Recent work on C45 helpers by Heiner made the genphy_c45_pma_read_abilities function generic enough to use as a default .get_featutes implementation. This series removes the remaining redundant code in mv3310_get_features(), and makes the 2110 PHY use genphy_c45_pma_read_abilities() directly, since it doesn't have the issue with the wrong abilities being reported. Maxime Chevallier (2): net: phy: marvell10g: Let genphy_c45_pma_read_abilities set Aneg bit net: phy: marvell10g: Use the generic C45 helper to read the 2110 features drivers/net/phy/marvell10g.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) -- 2.19.2
[PATCH net-next 1/2] net: phy: marvell10g: Let genphy_c45_pma_read_abilities set Aneg bit
The genphy_c45_pma_read_abilities helper now sets the Autoneg ability
in phydev->supported according to what the AN MMD reports.
We therefore don't need to manually do that in mv3310_get_features().
Signed-off-by: Maxime Chevallier
Suggested-by: Heiner Kallweit
---
drivers/net/phy/marvell10g.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 580e91deadbc..ab71da55c1e0 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -268,16 +268,6 @@ static int mv3310_get_features(struct phy_device *phydev)
{
int ret, val;
- if (phydev->c45_ids.devices_in_package & MDIO_DEVS_AN) {
- val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_STAT1);
- if (val < 0)
- return val;
-
- if (val & MDIO_AN_STAT1_ABLE)
- linkmode_set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
-phydev->supported);
- }
-
ret = genphy_c45_pma_read_abilities(phydev);
if (ret)
return ret;
--
2.19.2
[PATCH net-next 2/2] net: phy: marvell10g: Use the generic C45 helper to read the 2110 features
Contrary to the 3310, the 2110 PHY correctly reports it's 2.5G/5G
abilities. We can therefore use the genphy_c45_pma_read_abilities helper
to build the list of features.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index ab71da55c1e0..79106e70010f 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -472,7 +472,7 @@ static struct phy_driver mv3310_drivers[] = {
.phy_id = MARVELL_PHY_ID_88E2110,
.phy_id_mask= MARVELL_PHY_ID_MASK,
.name = "mv88x2110",
- .features = PHY_10GBIT_FEATURES,
+ .get_features = genphy_c45_pma_read_abilities,
.probe = mv3310_probe,
.soft_reset = gen10g_no_soft_reset,
.config_init= mv3310_config_init,
--
2.19.2
[PATCH net-next v2 7/7] net: phy: marvell10g: add support for the 88x2110 PHY
This patch adds support for the 88x2110 PHY, which is similar to the
already supported 88x3310 PHY without the SFP interface.
It supports 10/100/1000BASET along with 2.5GBASET, 5GBASET and 10GBASET,
with the same interface modes that are used by the 3310.
This PHY don't have the same issue as the 88x3310 regarding 2.5/5G
abilities, and correctly follows the 802.3bz standard to list the
supported abilities.
Signed-off-by: Maxime Chevallier
Suggested-by: Antoine Tenart
---
drivers/net/phy/marvell10g.c | 13 +
include/linux/marvell_phy.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 8f354c3f3876..580e91deadbc 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -478,12 +478,25 @@ static struct phy_driver mv3310_drivers[] = {
.aneg_done = mv3310_aneg_done,
.read_status= mv3310_read_status,
},
+ {
+ .phy_id = MARVELL_PHY_ID_88E2110,
+ .phy_id_mask= MARVELL_PHY_ID_MASK,
+ .name = "mv88x2110",
+ .features = PHY_10GBIT_FEATURES,
+ .probe = mv3310_probe,
+ .soft_reset = gen10g_no_soft_reset,
+ .config_init= mv3310_config_init,
+ .config_aneg= mv3310_config_aneg,
+ .aneg_done = mv3310_aneg_done,
+ .read_status= mv3310_read_status,
+ },
};
module_phy_driver(mv3310_drivers);
static struct mdio_device_id __maybe_unused mv3310_tbl[] = {
{ MARVELL_PHY_ID_88X3310, MARVELL_PHY_ID_MASK },
+ { MARVELL_PHY_ID_88E2110, MARVELL_PHY_ID_MASK },
{ },
};
MODULE_DEVICE_TABLE(mdio, mv3310_tbl);
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index 70c17345e118..73d04743a2bb 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -21,6 +21,7 @@
#define MARVELL_PHY_ID_88E1545 0x01410ea0
#define MARVELL_PHY_ID_88E3016 0x01410e60
#define MARVELL_PHY_ID_88X3310 0x002b09a0
+#define MARVELL_PHY_ID_88E2110 0x002b09b0
/* The MV88e6390 Ethernet switch contains embedded PHYs. These PHYs do
* not have a model ID. So the switch driver traps reads to the ID2
--
2.19.2
