| Message ID | 20191116165034.39001-1-jacopo+renesas@jmondi.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | GMSL Refresh (would be v6) | expand |
Hi Jacopo, Thanks for this refresh. The key part here is the refresh of the V4L2-Mux series, which is what had previously blocked the GMSL series. Will you post/publish the vl42-mux series on the linux-media mailinglist? I know there are other interested parties who are looking at such topics - so highlighting the latest version might be beneficial to promoting discussions. On 16/11/2019 16:50, Jacopo Mondi wrote: > Hello this is refersh of our GMSL work. > > Current situation is the following: > - Kieran sent a full v4 with multiplexed stream support and has a v5 branch in > his repository with v4 review comment fixes on top > > I rebased the multiplexed stream's series on latest media-master > https://jmondi.org/cgit/linux/log/?h=v4l2-mux/media-master/v6 > > On top of that I took Kieran's v5 and re-applied on top: > https://jmondi.org/cgit/linux/log/?h=jmondi/gmsl/kieran/v6 > > - Niklas sent a v1 (which sould have been a v5) which removes multiplexed > streams and only support one camera and was meant for inclusion but is still > floating around in linux-media, mostly because some of the comments on > Kieran's v4 still applied there, if I'm not mistaken. > > I took Niklas' single stream max9286 and replaced the original > bindings with a json-schema version > https://jmondi.org/cgit/linux/log/?h=jmondi/gmsl/niklas/v6 > > I bumped all versions to v6 to avoid further confusion. > > Not having a working GMSL setup I would ask to Kieran or Niklas to test this > version so that we can try re-send the single stream max9286 version with new > yaml bindings for inclusion. Thanks, I can confirm that the rebase to current master was successful (based on your branch with the version of patches based on my gmsl/v5) As we now have two forks of the GMSL I'm going to rebase these such that the separation between current topics is clear: - MAX9286 with support for a single camera (and only a single MAX9286) - This we could/should hope to get upstream - MAX9286 VC support - (requires the V4L2-Mux support of course) - MAX9286 dual device workaround (not suitable for upstream currently) - Required to function on the Salvator-XS GMSL board. Once I've done (and tested this) I'll make a new posting (should we call this v6? or v6.1?) In the meantime, I will not be making changes to the RDACM20, so if you wish to get started investigating the separation topic here - then I don't think you are blocked on me. -- Regards Kieran > (I kept linux-media e devicetree out as I would like to test the patches before > expanding the receivers list) > > Thanks > j > > Jacopo Mondi (2): > arm64: dts: renesas: Add Maxim GMSL expansion board > arm64: dts: renesas: r8a7796=salvator-x: Include GMSL > > Laurent Pinchart (1): > dt-bindings: media: i2c: Add bindings for Maxim Integrated MAX9286 > > Niklas Söderlund (1): > max9286: Add MAX9286 driver > > .../bindings/media/i2c/maxim,max9286.yaml | 286 +++++ > MAINTAINERS | 10 + > .../boot/dts/renesas/r8a7795-salvator-x.dts | 1 + > .../boot/dts/renesas/salvator-x-max9286.dtsi | 394 ++++++ > drivers/media/i2c/Kconfig | 11 + > drivers/media/i2c/Makefile | 1 + > drivers/media/i2c/max9286.c | 1081 +++++++++++++++++ > 7 files changed, 1784 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml > create mode 100644 arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi > create mode 100644 drivers/media/i2c/max9286.c > > -- > 2.23.0 >
Hi Kieran, On Wed, Nov 20, 2019 at 04:33:15PM +0000, Kieran Bingham wrote: > Hi Jacopo, > > Thanks for this refresh. The key part here is the refresh of the > V4L2-Mux series, which is what had previously blocked the GMSL series. > > Will you post/publish the vl42-mux series on the linux-media mailinglist? I considered that, but we already know that series is not meant to go far, so I could just as reference... > > I know there are other interested parties who are looking at such topics > - so highlighting the latest version might be beneficial to promoting > discussions. > Might be, yes... > > On 16/11/2019 16:50, Jacopo Mondi wrote: > > Hello this is refersh of our GMSL work. > > > > Current situation is the following: > > - Kieran sent a full v4 with multiplexed stream support and has a v5 branch in > > his repository with v4 review comment fixes on top > > > > I rebased the multiplexed stream's series on latest media-master > > https://jmondi.org/cgit/linux/log/?h=v4l2-mux/media-master/v6 > > > > On top of that I took Kieran's v5 and re-applied on top: > > https://jmondi.org/cgit/linux/log/?h=jmondi/gmsl/kieran/v6 > > > > - Niklas sent a v1 (which sould have been a v5) which removes multiplexed > > streams and only support one camera and was meant for inclusion but is still > > floating around in linux-media, mostly because some of the comments on > > Kieran's v4 still applied there, if I'm not mistaken. > > > > I took Niklas' single stream max9286 and replaced the original > > bindings with a json-schema version > > https://jmondi.org/cgit/linux/log/?h=jmondi/gmsl/niklas/v6 > > > > I bumped all versions to v6 to avoid further confusion. > > > > Not having a working GMSL setup I would ask to Kieran or Niklas to test this > > version so that we can try re-send the single stream max9286 version with new > > yaml bindings for inclusion. > > Thanks, I can confirm that the rebase to current master was successful > (based on your branch with the version of patches based on my gmsl/v5) > Great! Thanks for testing! > > As we now have two forks of the GMSL I'm going to rebase these such that > the separation between current topics is clear: > > - MAX9286 with support for a single camera (and only a single MAX9286) > - This we could/should hope to get upstream > - MAX9286 VC support > - (requires the V4L2-Mux support of course) > - MAX9286 dual device workaround (not suitable for upstream currently) > - Required to function on the Salvator-XS GMSL board. > > Once I've done (and tested this) I'll make a new posting (should we call > this v6? or v6.1?) I think you can keep v6, as this one is RFT.. > > > In the meantime, I will not be making changes to the RDACM20, so if you > wish to get started investigating the separation topic here - then I > don't think you are blocked on me. > I think this will need a bit more thoughts... Separating max9271 and ov10653 might be trivial, as the only action the current rdacm20 driver does on the sensor is an initial configuration with a set of register-value entries. It's a bit more work to properly define the data connection in DT and setting up a sub-notifier in the serializer driver, but that's totally feasible... Although, as Laurent pointed out we have a uController in the camera module, regulators (iirc) etc, and so it makes sense to keep a single rdacm20 driver, breaking out the serializer driver code into a re-usable library instead of making a proper driver out of it. What's your opinion on this ? Thanks j > -- > Regards > > Kieran > > > > > > (I kept linux-media e devicetree out as I would like to test the patches before > > expanding the receivers list) > > > > Thanks > > j > > > > Jacopo Mondi (2): > > arm64: dts: renesas: Add Maxim GMSL expansion board > > arm64: dts: renesas: r8a7796=salvator-x: Include GMSL > > > > Laurent Pinchart (1): > > dt-bindings: media: i2c: Add bindings for Maxim Integrated MAX9286 > > > > Niklas Söderlund (1): > > max9286: Add MAX9286 driver > > > > .../bindings/media/i2c/maxim,max9286.yaml | 286 +++++ > > MAINTAINERS | 10 + > > .../boot/dts/renesas/r8a7795-salvator-x.dts | 1 + > > .../boot/dts/renesas/salvator-x-max9286.dtsi | 394 ++++++ > > drivers/media/i2c/Kconfig | 11 + > > drivers/media/i2c/Makefile | 1 + > > drivers/media/i2c/max9286.c | 1081 +++++++++++++++++ > > 7 files changed, 1784 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml > > create mode 100644 arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi > > create mode 100644 drivers/media/i2c/max9286.c > > > > -- > > 2.23.0 > > >