* [RFC 00/12] staging: media: max96712: Add support for streams and multiple sensors @ 2025-01-31 16:33 Laurentiu Palcu 2025-01-31 16:34 ` [RFC 10/12] staging: media: max96712: add gpiochip functionality Laurentiu Palcu 2025-02-04 12:39 ` [RFC 00/12] staging: media: max96712: Add support for streams and multiple sensors Niklas Söderlund 0 siblings, 2 replies; 5+ messages in thread From: Laurentiu Palcu @ 2025-01-31 16:33 UTC (permalink / raw) To: Niklas Söderlund, Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sakari Ailus, Laurent Pinchart, Greg Kroah-Hartman, Linus Walleij, Bartosz Golaszewski Cc: Laurentiu Palcu, devicetree, linux-gpio, linux-kernel, linux-media, linux-staging, Niklas Söderlund Hi, This series adds more functionality to the existing max96712 staging driver allowing multiple sensors to be connected through other compatible serializers. I tried to split the changes in smaller logical changes to make them easier to review while not altering the existing VPG functionality but I could squash all of them together if needed. The series only supports tunneling mode and uses the first MIPI-CSI port. Support for more functionality can be added later, if needed. I sent the set as a RFC because it depends on Sakari's pending internal pads patch which is needed if we want to have an elegant solution for allowing the user to switch between streaming from sensors or just video pattern generation. Also, the set depends on my previous series which was not yet merged: https://patchwork.linuxtv.org/project/linux-media/list/?series=14255 Thanks, Laurentiu Laurentiu Palcu (11): dt-bindings: i2c: maxim,max96712: add a couple of new properties staging: media: max96712: convert to using CCI register access helpers staging: media: max96712: change DT parsing routine staging: media: max96712: add link frequency V4L2 control staging: media: max96712: add I2C mux support staging: media: max96712: add support for streams staging: media: max96712: allow enumerating MBUS codes staging: media: max96712: add set_fmt routine staging: media: max96712: add gpiochip functionality staging: media: max96712: add fsync support staging: media: max96712: allow streaming from connected sensors Sakari Ailus (1): media: mc: Add INTERNAL pad flag .../bindings/media/i2c/maxim,max96712.yaml | 45 + .../media/mediactl/media-types.rst | 8 + drivers/media/mc/mc-entity.c | 10 +- drivers/staging/media/max96712/max96712.c | 1406 +++++++++++++++-- include/uapi/linux/media.h | 1 + 5 files changed, 1352 insertions(+), 118 deletions(-) -- 2.44.1 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [RFC 10/12] staging: media: max96712: add gpiochip functionality 2025-01-31 16:33 [RFC 00/12] staging: media: max96712: Add support for streams and multiple sensors Laurentiu Palcu @ 2025-01-31 16:34 ` Laurentiu Palcu 2025-02-06 18:40 ` Linus Walleij 2025-02-04 12:39 ` [RFC 00/12] staging: media: max96712: Add support for streams and multiple sensors Niklas Söderlund 1 sibling, 1 reply; 5+ messages in thread From: Laurentiu Palcu @ 2025-01-31 16:34 UTC (permalink / raw) To: Niklas Söderlund, Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij, Bartosz Golaszewski Cc: Laurentiu Palcu, linux-gpio, linux-kernel, linux-media, linux-staging The deserializer has GPIOs that can be used for various purposes. Add support for gpiochip. Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> --- drivers/staging/media/max96712/max96712.c | 140 ++++++++++++++++++++++ 1 file changed, 140 insertions(+) diff --git a/drivers/staging/media/max96712/max96712.c b/drivers/staging/media/max96712/max96712.c index ed1d46ea98cb9..307b2f1d3a6be 100644 --- a/drivers/staging/media/max96712/max96712.c +++ b/drivers/staging/media/max96712/max96712.c @@ -7,6 +7,7 @@ */ #include <linux/delay.h> +#include <linux/gpio/driver.h> #include <linux/i2c.h> #include <linux/i2c-mux.h> #include <linux/module.h> @@ -108,6 +109,41 @@ #define CSI2_LANE_CNT_MASK GENMASK(7, 6) #define CSI2_LANE_CNT_SHIFT 6 +/* GPIO_A: 0 <= gpio < 11 */ +#define MAX96712_GPIO_A_A(gpio) CCI_REG8(0x0300 + (gpio) * 0x03) +#define GPIO_OUT_DIS BIT(0) +#define GPIO_TX_EN_A BIT(1) +#define GPIO_RX_EN_A BIT(2) +#define GPIO_IN BIT(3) +#define GPIO_OUT BIT(4) +#define TX_COMP_EN_A BIT(5) +#define RES_CFG BIT(7) +#define MAX96712_GPIO_A_B(gpio) CCI_REG8(0x0301 + (gpio) * 0x03) +#define GPIO_TX_ID_A_MASK GENMASK(4, 0) +#define GPIO_TX_ID_A_SHIFT 0 +#define OUT_TYPE BIT(5) +#define PULL_UPDN_SEL_MASK GENMASK(7, 6) +#define PULL_UPDN_SEL_SHIFT 6 +#define MAX96712_GPIO_A_C(gpio) CCI_REG8(0x0302 + (gpio) * 0x03) +#define GPIO_RX_ID_A_MASK GENMASK(4, 0) +#define GPIO_RX_ID_A_SHIFT 0 +#define GPIO_RECVED_A BIT(6) +#define OVR_RES_CFG BIT(7) + +/* GPIO_B, GPIO_C, GPIO_D: 0 <= gpio < 11, link: 1, 2, 3 */ +#define MAX96712_GPIO_B(gpio) CCI_REG8(0x0301 + (link) * 0x36 + \ + (gpio) * 0x03) +#define GPIO_TX_ID_MASK GENMASK(4, 0) +#define GPIO_TX_ID_SHIFT 0 +#define GPIO_TX_EN BIT(5) +#define TX_COMP_EN BIT(6) +#define MAX96712_GPIO_C(gpio) CCI_REG8(0x0302 + (link) * 0x36 + \ + (gpio) * 0x03) +#define GPIO_RX_ID_MASK GENMASK(4, 0) +#define GPIO_RX_ID_SHIFT 0 +#define GPIO_RX_EN BIT(5) +#define GPIO_RECVED BIT(6) + /* VRX_PATGEN */ #define MAX96712_VRX_PATGEN_0 CCI_REG8(0x1050) #define VTG_MODE_MASK GENMASK(1, 0) @@ -160,6 +196,8 @@ #define MHZ(f) ((f) * 1000000U) +#define MAX96712_NUM_GPIO 12 + enum max96712_pattern { MAX96712_PATTERN_CHECKERBOARD = 0, MAX96712_PATTERN_GRADIENT, @@ -179,6 +217,8 @@ struct max96712_priv { struct regmap *regmap; struct gpio_desc *gpiod_pwdn; + struct gpio_chip gpio_chip; + struct i2c_mux_core *mux; int mux_chan; @@ -830,6 +870,7 @@ static int max96712_v4l2_register(struct max96712_priv *priv) return ret; } +/* I2C Mux section */ static int max96712_i2c_mux_select(struct i2c_mux_core *muxc, u32 chan) { struct max96712_priv *priv = i2c_mux_priv(muxc); @@ -885,6 +926,101 @@ static int max96712_i2c_init(struct max96712_priv *priv) return ret; } +/* GPIO chip section */ +static int max96712_gpiochip_get(struct gpio_chip *gpiochip, + unsigned int offset) +{ + struct max96712_priv *priv = gpiochip_get_data(gpiochip); + unsigned int val; + int ret; + + ret = regmap_read(priv->regmap, MAX96712_GPIO_A_A(offset), &val); + if (ret) + return ret; + + if (val & GPIO_OUT_DIS) + return !!(val & GPIO_IN); + else + return !!(val & GPIO_OUT); +} + +static void max96712_gpiochip_set(struct gpio_chip *gpiochip, + unsigned int offset, int value) +{ + struct max96712_priv *priv = gpiochip_get_data(gpiochip); + + regmap_update_bits(priv->regmap, MAX96712_GPIO_A_A(offset), GPIO_OUT, + GPIO_OUT); +} + +static int max96712_gpio_get_direction(struct gpio_chip *gpiochip, + unsigned int offset) +{ + struct max96712_priv *priv = gpiochip_get_data(gpiochip); + unsigned int val; + int ret; + + ret = regmap_read(priv->regmap, MAX96712_GPIO_A_A(offset), &val); + if (ret < 0) + return ret; + + return !!(val & GPIO_OUT_DIS); +} + +static int max96712_gpio_direction_out(struct gpio_chip *gpiochip, + unsigned int offset, int value) +{ + struct max96712_priv *priv = gpiochip_get_data(gpiochip); + + return regmap_update_bits(priv->regmap, MAX96712_GPIO_A_A(offset), + GPIO_OUT_DIS | GPIO_OUT, + value ? GPIO_OUT : 0); +} + +static int max96712_gpio_direction_in(struct gpio_chip *gpiochip, + unsigned int offset) +{ + struct max96712_priv *priv = gpiochip_get_data(gpiochip); + + return regmap_update_bits(priv->regmap, MAX96712_GPIO_A_A(offset), + GPIO_OUT_DIS, GPIO_OUT_DIS); +} + +static int max96712_gpiochip_probe(struct max96712_priv *priv) +{ + struct device *dev = &priv->client->dev; + struct gpio_chip *gc = &priv->gpio_chip; + int i, ret = 0; + + gc->label = dev_name(dev); + gc->parent = dev; + gc->owner = THIS_MODULE; + gc->ngpio = MAX96712_NUM_GPIO; + gc->base = -1; + gc->can_sleep = true; + gc->get_direction = max96712_gpio_get_direction; + gc->direction_input = max96712_gpio_direction_in; + gc->direction_output = max96712_gpio_direction_out; + gc->request = gpiochip_generic_request; + gc->set = max96712_gpiochip_set; + gc->get = max96712_gpiochip_get; + gc->of_gpio_n_cells = 2; + + /* Disable GPIO forwarding */ + for (i = 0; i < gc->ngpio; i++) + regmap_update_bits(priv->regmap, MAX96712_GPIO_A_A(i), + GPIO_RX_EN_A | GPIO_TX_EN_A, 0); + + ret = devm_gpiochip_add_data(dev, gc, priv); + if (ret) { + dev_err(dev, "Unable to create gpio_chip\n"); + return ret; + } + + return 0; +} + +/* DT parsing section */ static int max96712_parse_rx_ports(struct max96712_priv *priv, struct device_node *node, struct of_endpoint *ep) { @@ -1061,6 +1197,10 @@ static int max96712_probe(struct i2c_client *client) max96712_mipi_configure(priv); + ret = max96712_gpiochip_probe(priv); + if (ret) + return ret; + ret = max96712_v4l2_register(priv); if (ret) return ret; -- 2.44.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [RFC 10/12] staging: media: max96712: add gpiochip functionality 2025-01-31 16:34 ` [RFC 10/12] staging: media: max96712: add gpiochip functionality Laurentiu Palcu @ 2025-02-06 18:40 ` Linus Walleij 0 siblings, 0 replies; 5+ messages in thread From: Linus Walleij @ 2025-02-06 18:40 UTC (permalink / raw) To: Laurentiu Palcu Cc: Niklas Söderlund, Mauro Carvalho Chehab, Greg Kroah-Hartman, Bartosz Golaszewski, linux-gpio, linux-kernel, linux-media, linux-staging Hi Laurentiu, thanks for your patch! On Fri, Jan 31, 2025 at 5:35 PM Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> wrote: > The deserializer has GPIOs that can be used for various purposes. Add > support for gpiochip. > > Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Since you are using CONFIG_GPIOLIB unconditionally you need to add select GPIOLIB in the Kconfig for this driver, or the autobuilder will soon start to spam you with compilation errors. > +static int max96712_gpiochip_probe(struct max96712_priv *priv) > +{ > + struct device *dev = &priv->client->dev; > + struct gpio_chip *gc = &priv->gpio_chip; > + int i, ret = 0; > + > + gc->label = dev_name(dev); > + gc->parent = dev; I don't think you need to assign parent. (Default) > + gc->owner = THIS_MODULE; Or this. (Default) > + gc->ngpio = MAX96712_NUM_GPIO; > + gc->base = -1; > + gc->can_sleep = true; > + gc->get_direction = max96712_gpio_get_direction; > + gc->direction_input = max96712_gpio_direction_in; > + gc->direction_output = max96712_gpio_direction_out; > + gc->request = gpiochip_generic_request; > + gc->set = max96712_gpiochip_set; > + gc->get = max96712_gpiochip_get; > + gc->of_gpio_n_cells = 2; Isn't that the default? Do you need to assign this? Other than that this looks good, so with the small fix above: Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC 00/12] staging: media: max96712: Add support for streams and multiple sensors 2025-01-31 16:33 [RFC 00/12] staging: media: max96712: Add support for streams and multiple sensors Laurentiu Palcu 2025-01-31 16:34 ` [RFC 10/12] staging: media: max96712: add gpiochip functionality Laurentiu Palcu @ 2025-02-04 12:39 ` Niklas Söderlund 2025-02-04 13:37 ` Laurentiu Palcu 1 sibling, 1 reply; 5+ messages in thread From: Niklas Söderlund @ 2025-02-04 12:39 UTC (permalink / raw) To: Laurentiu Palcu Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sakari Ailus, Laurent Pinchart, Greg Kroah-Hartman, Linus Walleij, Bartosz Golaszewski, devicetree, linux-gpio, linux-kernel, linux-media, linux-staging Hi Laurentiu, Thanks for your work. I'm happy someone with a both GMSL cameras and a max96712 found time to work on this driver. On 2025-01-31 18:33:54 +0200, Laurentiu Palcu wrote: > Hi, > > This series adds more functionality to the existing max96712 staging > driver allowing multiple sensors to be connected through other > compatible serializers. I tried to split the changes in smaller logical > changes to make them easier to review while not altering the existing > VPG functionality but I could squash all of them together if needed. With this series and it's listed dependencies applied my CI tests using the VPG breaks. The controls to select test-pattern seems to be invalid, $ yavta --set-control '0x009f0903 0' /dev/v4l-subdev6 Device /dev/v4l-subdev6 opened. unable to set control 0x009f0903: Permission denied (13). Unable to get format: Inappropriate ioctl for device (25). (/dev/v4l-subdev6 here is max96712 1-0049) $ yavta -c10 --file=/tmp/vin-capture/isp0-checkerboard-#.bin /dev/video0 Device /dev/video0 opened. Device `R_Car_VIN' on `platform:e6ef0000.video' (driver 'rcar_vin') supports video, capture, without mplanes. Video format: ABGR32 (34325241) 1920x1080 (stride 7680) field none buffer size 8294400 8 buffers requested. length: 8294400 offset: 0 timestamp type/source: mono/EoF Buffer 0/0 mapped at address 0xffffbe5d7000. length: 8294400 offset: 32768 timestamp type/source: mono/EoF Buffer 1/0 mapped at address 0xffffbddee000. length: 8294400 offset: 65536 timestamp type/source: mono/EoF Buffer 2/0 mapped at address 0xffffbd605000. length: 8294400 offset: 98304 timestamp type/source: mono/EoF Buffer 3/0 mapped at address 0xffffbce1c000. length: 8294400 offset: 131072 timestamp type/source: mono/EoF Buffer 4/0 mapped at address 0xffffbc633000. length: 8294400 offset: 163840 timestamp type/source: mono/EoF Buffer 5/0 mapped at address 0xffffbbe4a000. length: 8294400 offset: 196608 timestamp type/source: mono/EoF Buffer 6/0 mapped at address 0xffffbb661000. length: 8294400 offset: 229376 timestamp type/source: mono/EoF Buffer 7/0 mapped at address 0xffffbae78000. Unable to start streaming: Invalid argument (22). I read in patch 12/12 "The user can also switch over to testing the test pattern by configuring the routes accordingly", but not how to do that to achieve the same functionality as the staging driver. Inspecting the media graph gives little help. Would it be possible to extend the cover letter with this information? To be clear, I don't care about the change in behavior as this driver obviously primary aim should be to support GMSL2 cameras, not test-pattern generation. It is important for me that it is possible to enable the test pattern generation $somehow at runtime (i.e. no DTS changes). As this is the only method I have to test a bunch of boards. It would also be nice if the patterns generated (output frames) as closely as possible would resembles what is generated today. That way I don't have to alter my CI pipelines too much :-) > > The series only supports tunneling mode and uses the first MIPI-CSI > port. Support for more functionality can be added later, if needed. > > I sent the set as a RFC because it depends on Sakari's pending internal > pads patch which is needed if we want to have an elegant solution for > allowing the user to switch between streaming from sensors or just > video pattern generation. > > Also, the set depends on my previous series which was not yet merged: > https://patchwork.linuxtv.org/project/linux-media/list/?series=14255 > > Thanks, > Laurentiu > > Laurentiu Palcu (11): > dt-bindings: i2c: maxim,max96712: add a couple of new properties > staging: media: max96712: convert to using CCI register access helpers > staging: media: max96712: change DT parsing routine > staging: media: max96712: add link frequency V4L2 control > staging: media: max96712: add I2C mux support > staging: media: max96712: add support for streams > staging: media: max96712: allow enumerating MBUS codes > staging: media: max96712: add set_fmt routine > staging: media: max96712: add gpiochip functionality > staging: media: max96712: add fsync support > staging: media: max96712: allow streaming from connected sensors > > Sakari Ailus (1): > media: mc: Add INTERNAL pad flag > > .../bindings/media/i2c/maxim,max96712.yaml | 45 + > .../media/mediactl/media-types.rst | 8 + > drivers/media/mc/mc-entity.c | 10 +- > drivers/staging/media/max96712/max96712.c | 1406 +++++++++++++++-- > include/uapi/linux/media.h | 1 + > 5 files changed, 1352 insertions(+), 118 deletions(-) > > -- > 2.44.1 > -- Kind Regards, Niklas Söderlund ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC 00/12] staging: media: max96712: Add support for streams and multiple sensors 2025-02-04 12:39 ` [RFC 00/12] staging: media: max96712: Add support for streams and multiple sensors Niklas Söderlund @ 2025-02-04 13:37 ` Laurentiu Palcu 0 siblings, 0 replies; 5+ messages in thread From: Laurentiu Palcu @ 2025-02-04 13:37 UTC (permalink / raw) To: Niklas Söderlund Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sakari Ailus, Laurent Pinchart, Greg Kroah-Hartman, Linus Walleij, Bartosz Golaszewski, devicetree, linux-gpio, linux-kernel, linux-media, linux-staging Hi Niklas, Thanks for giving this series a test. More comments below. On Tue, Feb 04, 2025 at 01:39:25PM +0100, Niklas Söderlund wrote: > Hi Laurentiu, > > Thanks for your work. I'm happy someone with a both GMSL cameras and a > max96712 found time to work on this driver. I don't have a max96712 unfortunately. Our setup is based on max96724. > > On 2025-01-31 18:33:54 +0200, Laurentiu Palcu wrote: > > Hi, > > > > This series adds more functionality to the existing max96712 staging > > driver allowing multiple sensors to be connected through other > > compatible serializers. I tried to split the changes in smaller logical > > changes to make them easier to review while not altering the existing > > VPG functionality but I could squash all of them together if needed. > > With this series and it's listed dependencies applied my CI tests using > the VPG breaks. The controls to select test-pattern seems to be invalid, > > $ yavta --set-control '0x009f0903 0' /dev/v4l-subdev6 > Device /dev/v4l-subdev6 opened. > unable to set control 0x009f0903: Permission denied (13). > Unable to get format: Inappropriate ioctl for device (25). That's my bad... :/ I have never tried to change test patterns and I didn't spot the bug. The below change should fix that: diff --git a/drivers/staging/media/max96712/max96712.c b/drivers/staging/media/max96712/max96712.c index b4c3d1d3c9539..6d6dea0a335c7 100644 --- a/drivers/staging/media/max96712/max96712.c +++ b/drivers/staging/media/max96712/max96712.c @@ -1315,10 +1315,10 @@ static int max96712_v4l2_register(struct max96712_priv *priv) v4l2_ctrl_handler_init(&priv->ctrl_handler, 2); - v4l2_ctrl_new_int_menu(&priv->ctrl_handler, NULL, V4L2_CID_LINK_FREQ, + link_freq_ctrl = v4l2_ctrl_new_int_menu(&priv->ctrl_handler, NULL, V4L2_CID_LINK_FREQ, 0, 0, &priv->link_freq); - link_freq_ctrl = v4l2_ctrl_new_std_menu_items(&priv->ctrl_handler, &max96712_ctrl_ops, + v4l2_ctrl_new_std_menu_items(&priv->ctrl_handler, &max96712_ctrl_ops, V4L2_CID_TEST_PATTERN, ARRAY_SIZE(max96712_test_pattern) - 1, 0, 0, max96712_test_pattern); > > (/dev/v4l-subdev6 here is max96712 1-0049) > > $ yavta -c10 --file=/tmp/vin-capture/isp0-checkerboard-#.bin /dev/video0 > Device /dev/video0 opened. > Device `R_Car_VIN' on `platform:e6ef0000.video' (driver 'rcar_vin') supports video, capture, without mplanes. > Video format: ABGR32 (34325241) 1920x1080 (stride 7680) field none buffer size 8294400 > 8 buffers requested. > length: 8294400 offset: 0 timestamp type/source: mono/EoF > Buffer 0/0 mapped at address 0xffffbe5d7000. > length: 8294400 offset: 32768 timestamp type/source: mono/EoF > Buffer 1/0 mapped at address 0xffffbddee000. > length: 8294400 offset: 65536 timestamp type/source: mono/EoF > Buffer 2/0 mapped at address 0xffffbd605000. > length: 8294400 offset: 98304 timestamp type/source: mono/EoF > Buffer 3/0 mapped at address 0xffffbce1c000. > length: 8294400 offset: 131072 timestamp type/source: mono/EoF > Buffer 4/0 mapped at address 0xffffbc633000. > length: 8294400 offset: 163840 timestamp type/source: mono/EoF > Buffer 5/0 mapped at address 0xffffbbe4a000. > length: 8294400 offset: 196608 timestamp type/source: mono/EoF > Buffer 6/0 mapped at address 0xffffbb661000. > length: 8294400 offset: 229376 timestamp type/source: mono/EoF > Buffer 7/0 mapped at address 0xffffbae78000. > Unable to start streaming: Invalid argument (22). > > I read in patch 12/12 "The user can also switch over to testing the test > pattern by configuring the routes accordingly", but not how to do that > to achieve the same functionality as the staging driver. Inspecting the > media graph gives little help. Would it be possible to extend the cover > letter with this information? I can do that, sure, but routing setup depends on the board you test on... :/ Basically, the deserializer media node has 6 pads now. Pad 4 is first CSI output port and pad 6 is the internal VPG source pad. By default, the route from internal VPG pad to pad 4 is active. So, you shouldn't need to set any routes on max96712 node for testing VPG. This is how it looks like: - entity 120: max96712 2-0027 (7 pads, 5 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev11 routes: 6/0 -> 4/0 [ACTIVE] pad0: Sink <- "max96717 8-0040":1 [] pad1: Sink <- "max96717 9-0040":1 [] pad2: Sink <- "max96717 10-0040":1 [] pad3: Sink <- "max96717 14-0040":1 [] pad4: Source [stream:0 fmt:RGB888_1X24/1920x1080 field:none colorspace:srgb] -> "csidev-4ad30000.csi":0 [] pad5: Source pad6: Sink, Internal [stream:0 fmt:RGB888_1X24/1920x1080 field:none colorspace:srgb] Below is the test script I use to set the routings and links for all the pipeline in order to test VPG. I'm testing on an i.MX95 board. ./media-ctl -r ./media-ctl -d /dev/media0 -R '"max96712 2-0027" [6/0 -> 4/0 [1]]' ./media-ctl -d /dev/media0 --set-v4l2 '"max96712 2-0027":6/0 [fmt:RGB24/1920x1080 field:none]' ./media-ctl -d /dev/media0 -R '"csidev-4ad30000.csi" [0/0 -> 1/0 [1]]' ./media-ctl -d /dev/media0 --set-v4l2 '"csidev-4ad30000.csi":0/0 [fmt:RGB24/1920x1080 field:none]' ./media-ctl -d /dev/media0 -R '"4ac10000.syscon:formatter@20" [0/0 -> 1/0 [1]]' ./media-ctl -d /dev/media0 --set-v4l2 '"4ac10000.syscon:formatter@20":0/0 [fmt:RGB24/1920x1080 field:none]' ./media-ctl -d /dev/media0 -R '"crossbar" [2/0 -> 7/0 [1]]' ./media-ctl -d /dev/media0 --set-v4l2 '"crossbar":2/0 [fmt:RGB24/1920x1080 field:none]' ./media-ctl -d /dev/media0 --set-v4l2 '"mxc_isi.2":0/0 [fmt:RGB24/1920x1080 field:none]' ./media-ctl -d /dev/media0 -l "'max96712 2-0027':4 -> 'csidev-4ad30000.csi':0 [1]" ./v4l2-ctl --device /dev/video2 --set-fmt-video=width=1920,height=1080,pixelformat=RGB3 --stream-mmap --stream-count=100 However, I suspect that, in your case, the downstream drivers do not support streams and streaming cannot start. But I might be wrong though... > > To be clear, I don't care about the change in behavior as this driver > obviously primary aim should be to support GMSL2 cameras, not > test-pattern generation. It is important for me that it is possible to > enable the test pattern generation $somehow at runtime (i.e. no DTS > changes). As this is the only method I have to test a bunch of boards. That's the idea. I can switch between capturing from sensors and generating the test pattern at runtime. I don't do any changes in the DTB. However, I believe the downstream devices need to support streams as well in order to work. > > It would also be nice if the patterns generated (output frames) as > closely as possible would resembles what is generated today. That way I > don't have to alter my CI pipelines too much :-) I didn't touch the pattern generation part at all. From what I can see, it looks the same. Thanks, Laurentiu > > > > > The series only supports tunneling mode and uses the first MIPI-CSI > > port. Support for more functionality can be added later, if needed. > > > > I sent the set as a RFC because it depends on Sakari's pending internal > > pads patch which is needed if we want to have an elegant solution for > > allowing the user to switch between streaming from sensors or just > > video pattern generation. > > > > Also, the set depends on my previous series which was not yet merged: > > https://patchwork.linuxtv.org/project/linux-media/list/?series=14255 > > > > Thanks, > > Laurentiu > > > > Laurentiu Palcu (11): > > dt-bindings: i2c: maxim,max96712: add a couple of new properties > > staging: media: max96712: convert to using CCI register access helpers > > staging: media: max96712: change DT parsing routine > > staging: media: max96712: add link frequency V4L2 control > > staging: media: max96712: add I2C mux support > > staging: media: max96712: add support for streams > > staging: media: max96712: allow enumerating MBUS codes > > staging: media: max96712: add set_fmt routine > > staging: media: max96712: add gpiochip functionality > > staging: media: max96712: add fsync support > > staging: media: max96712: allow streaming from connected sensors > > > > Sakari Ailus (1): > > media: mc: Add INTERNAL pad flag > > > > .../bindings/media/i2c/maxim,max96712.yaml | 45 + > > .../media/mediactl/media-types.rst | 8 + > > drivers/media/mc/mc-entity.c | 10 +- > > drivers/staging/media/max96712/max96712.c | 1406 +++++++++++++++-- > > include/uapi/linux/media.h | 1 + > > 5 files changed, 1352 insertions(+), 118 deletions(-) > > > > -- > > 2.44.1 > > > > -- > Kind Regards, > Niklas Söderlund ^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-02-06 18:40 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-01-31 16:33 [RFC 00/12] staging: media: max96712: Add support for streams and multiple sensors Laurentiu Palcu 2025-01-31 16:34 ` [RFC 10/12] staging: media: max96712: add gpiochip functionality Laurentiu Palcu 2025-02-06 18:40 ` Linus Walleij 2025-02-04 12:39 ` [RFC 00/12] staging: media: max96712: Add support for streams and multiple sensors Niklas Söderlund 2025-02-04 13:37 ` Laurentiu Palcu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).