From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: kieran.bingham@ideasonboard.com, Lee Jones <lee.jones@linaro.org>, Vladimir Zapolskiy <vz@mleia.com>, Linus Walleij <linus.walleij@linaro.org>, Rob Herring <robh+dt@kernel.org>, Marek Vasut <marek.vasut@gmail.com>, Wolfram Sang <wsa@the-dreams.de>, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/7] mfd: ds90ux9xx: add TI DS90Ux9xx de-/serializer MFD driver Date: Sat, 13 Oct 2018 18:10:25 +0300 [thread overview] Message-ID: <369ef3ac-6f68-c450-713f-762b1c5cd5c9@mentor.com> (raw) In-Reply-To: <3599186.afdMBtdL0k@avalon> Hi Laurent, On 10/12/2018 04:01 PM, Laurent Pinchart wrote: > Hello Vladimir, > > On Friday, 12 October 2018 14:47:52 EEST Kieran Bingham wrote: >> On 12/10/18 11:58, Vladimir Zapolskiy wrote: [snip] >> Essentially they are multi purpose buses - which do not yet have a home. >> We have used media as a home because of our use case. >> >> The use case whether they transfer frames from a camera or to a display >> are of course closely related, but ultimately covered by two separate >> subsystems at the pixel level (DRM vs V4L, or other for other data) >> >> Perhaps as they are buses - on a level with USB or I2C (except they can >> of course carry I2C or Serial as well as 'bi-directional video' etc ), >> they are looking for their own subsystem. >> >> Except I don't think we don't want to add a new subsystem for just one >> (or two) devices... > > I'm not sure a new subsystem is needed. As you've noted there's an overlap > between drivers/media/ and drivers/gpu/drm/ in terms of supported hardware. > We even have a devices supported by two drivers, one in drivers/media/ and > one in drivers/gpu/drm/ (I'm thinking about the adv7511 in particular). > This is a well known issue, and so far nothing has been done in mainline > to try and solve it. I agree that there's an overlap between drivers/media/ and drivers/gpu/drm/, formally a hypothetical (sic!) DS90Ux9xx video bridge cell driver should be added into both subsystems also, and the actual driver of two should be selected in runtime. I call such a driver 'hypothetical', because in fact I don't have it, and I'm not so sure that its existence is justified, but that's only because DS90Ux9xx video bridge functionality is _transparent_, it does not have any controls literally, but it is a pure luck eventually. So, as I've stated in my cover letter, I can misuse yours 'lvds-encoder' driver only for the purpose of establishing a mediated link between an LVDS controller and a panel over a serializer-deserializer pair. > Trying to find another home in drivers/mfd/ to escape from the problem isn't a > good solution in my opinion. The best option from a Linux point of view would > be to unify V4L2 and DRM/KMS when it comes to bridge support, but that's a > long way down the road (I won't complain if you want to give it a go though > :-)). I return you a wider smile :) > As your use cases are display, focused, I would propose to start with > drivers/gpu/drm/bridge/, and leave the problem of camera support for first > person who will have such a use case. Frankly speaking I would like to start from copy-pasting your 'lvds-encoder' driver into an 'absolutely-transparent-video-bridge' driver with no LVDS or 'encoder' specifics, adding just a new compatible may suffice, if the driver is renamed/redefined. PS, I remember I owe you a reference OF snippet of data path to a panel. -- Best wishes, Vladimir
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: <kieran.bingham@ideasonboard.com>, Lee Jones <lee.jones@linaro.org>, Vladimir Zapolskiy <vz@mleia.com>, Linus Walleij <linus.walleij@linaro.org>, Rob Herring <robh+dt@kernel.org>, Marek Vasut <marek.vasut@gmail.com>, Wolfram Sang <wsa@the-dreams.de>, <devicetree@vger.kernel.org>, <linux-gpio@vger.kernel.org>, <linux-media@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 4/7] mfd: ds90ux9xx: add TI DS90Ux9xx de-/serializer MFD driver Date: Sat, 13 Oct 2018 18:10:25 +0300 [thread overview] Message-ID: <369ef3ac-6f68-c450-713f-762b1c5cd5c9@mentor.com> (raw) In-Reply-To: <3599186.afdMBtdL0k@avalon> Hi Laurent, On 10/12/2018 04:01 PM, Laurent Pinchart wrote: > Hello Vladimir, > > On Friday, 12 October 2018 14:47:52 EEST Kieran Bingham wrote: >> On 12/10/18 11:58, Vladimir Zapolskiy wrote: [snip] >> Essentially they are multi purpose buses - which do not yet have a home. >> We have used media as a home because of our use case. >> >> The use case whether they transfer frames from a camera or to a display >> are of course closely related, but ultimately covered by two separate >> subsystems at the pixel level (DRM vs V4L, or other for other data) >> >> Perhaps as they are buses - on a level with USB or I2C (except they can >> of course carry I2C or Serial as well as 'bi-directional video' etc ), >> they are looking for their own subsystem. >> >> Except I don't think we don't want to add a new subsystem for just one >> (or two) devices... > > I'm not sure a new subsystem is needed. As you've noted there's an overlap > between drivers/media/ and drivers/gpu/drm/ in terms of supported hardware. > We even have a devices supported by two drivers, one in drivers/media/ and > one in drivers/gpu/drm/ (I'm thinking about the adv7511 in particular). > This is a well known issue, and so far nothing has been done in mainline > to try and solve it. I agree that there's an overlap between drivers/media/ and drivers/gpu/drm/, formally a hypothetical (sic!) DS90Ux9xx video bridge cell driver should be added into both subsystems also, and the actual driver of two should be selected in runtime. I call such a driver 'hypothetical', because in fact I don't have it, and I'm not so sure that its existence is justified, but that's only because DS90Ux9xx video bridge functionality is _transparent_, it does not have any controls literally, but it is a pure luck eventually. So, as I've stated in my cover letter, I can misuse yours 'lvds-encoder' driver only for the purpose of establishing a mediated link between an LVDS controller and a panel over a serializer-deserializer pair. > Trying to find another home in drivers/mfd/ to escape from the problem isn't a > good solution in my opinion. The best option from a Linux point of view would > be to unify V4L2 and DRM/KMS when it comes to bridge support, but that's a > long way down the road (I won't complain if you want to give it a go though > :-)). I return you a wider smile :) > As your use cases are display, focused, I would propose to start with > drivers/gpu/drm/bridge/, and leave the problem of camera support for first > person who will have such a use case. Frankly speaking I would like to start from copy-pasting your 'lvds-encoder' driver into an 'absolutely-transparent-video-bridge' driver with no LVDS or 'encoder' specifics, adding just a new compatible may suffice, if the driver is renamed/redefined. PS, I remember I owe you a reference OF snippet of data path to a panel. -- Best wishes, Vladimir
next prev parent reply other threads:[~2018-10-13 15:10 UTC|newest] Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-08 21:11 [PATCH 0/7] mfd/pinctrl: add initial support of TI DS90Ux9xx ICs Vladimir Zapolskiy 2018-10-08 21:11 ` [PATCH 1/7] dt-bindings: mfd: ds90ux9xx: add description " Vladimir Zapolskiy 2018-10-09 0:13 ` Marek Vasut 2018-10-09 11:11 ` Vladimir Zapolskiy 2018-10-09 20:55 ` Vladimir Zapolskiy 2018-10-09 21:03 ` Marek Vasut 2018-10-10 8:41 ` Linus Walleij 2018-10-10 8:41 ` Linus Walleij 2018-10-10 8:41 ` Linus Walleij 2018-10-12 11:44 ` Laurent Pinchart 2018-10-13 14:28 ` Vladimir Zapolskiy 2018-10-13 14:28 ` Vladimir Zapolskiy 2018-10-16 12:30 ` Laurent Pinchart 2018-10-30 16:43 ` Luca Ceresoli 2018-10-30 23:40 ` Vladimir Zapolskiy 2018-10-08 21:12 ` [PATCH 2/7] dt-bindings: mfd: ds90ux9xx: add description of TI DS90Ux9xx I2C bridge Vladimir Zapolskiy 2018-10-12 11:54 ` Laurent Pinchart 2018-10-12 11:54 ` Laurent Pinchart 2018-10-30 16:43 ` Luca Ceresoli 2018-10-31 20:12 ` Vladimir Zapolskiy 2018-11-03 21:00 ` Luca Ceresoli 2018-11-03 22:07 ` Vladimir Zapolskiy 2018-10-08 21:12 ` [PATCH 3/7] dt-bindings: pinctrl: ds90ux9xx: add description of TI DS90Ux9xx pinmux Vladimir Zapolskiy 2018-10-10 8:45 ` Linus Walleij 2018-10-10 8:45 ` Linus Walleij 2018-10-17 15:02 ` Rob Herring 2018-10-17 15:02 ` Rob Herring 2018-10-12 12:01 ` Laurent Pinchart 2018-10-13 13:47 ` Vladimir Zapolskiy 2018-10-13 13:47 ` Vladimir Zapolskiy 2018-10-16 12:48 ` Laurent Pinchart 2018-10-30 16:44 ` Luca Ceresoli 2018-10-31 20:31 ` Vladimir Zapolskiy 2018-10-08 21:12 ` [PATCH 4/7] mfd: ds90ux9xx: add TI DS90Ux9xx de-/serializer MFD driver Vladimir Zapolskiy 2018-10-09 4:08 ` kbuild test robot 2018-10-09 11:14 ` Vladimir Zapolskiy 2018-10-12 6:03 ` Lee Jones 2018-10-12 7:41 ` Vladimir Zapolskiy 2018-10-12 7:41 ` Vladimir Zapolskiy 2018-10-12 8:39 ` Lee Jones 2018-10-12 9:20 ` Kieran Bingham 2018-10-12 10:58 ` Vladimir Zapolskiy 2018-10-12 10:58 ` Vladimir Zapolskiy 2018-10-12 11:34 ` Lee Jones 2018-10-12 14:13 ` Vladimir Zapolskiy 2018-10-12 14:25 ` Lee Jones 2018-10-12 11:47 ` Kieran Bingham 2018-10-12 13:01 ` Laurent Pinchart 2018-10-12 13:59 ` Vladimir Zapolskiy 2018-10-16 13:08 ` Laurent Pinchart 2018-10-23 8:16 ` Vladimir Zapolskiy 2018-10-30 16:44 ` Luca Ceresoli 2018-10-13 15:10 ` Vladimir Zapolskiy [this message] 2018-10-13 15:10 ` Vladimir Zapolskiy 2018-10-16 13:12 ` Laurent Pinchart 2018-10-16 18:32 ` Vladimir Zapolskiy 2018-10-13 12:33 ` Vladimir Zapolskiy 2018-10-13 12:33 ` Vladimir Zapolskiy 2018-10-12 11:24 ` Vladimir Zapolskiy 2018-10-12 11:24 ` Vladimir Zapolskiy 2018-10-12 11:43 ` Lee Jones 2018-10-12 14:23 ` Vladimir Zapolskiy 2018-10-12 13:07 ` Laurent Pinchart 2018-10-08 21:12 ` [PATCH 5/7] mfd: ds90ux9xx: add I2C bridge/alias and link connection driver Vladimir Zapolskiy 2018-10-12 6:04 ` Lee Jones 2018-10-12 7:32 ` Vladimir Zapolskiy 2018-10-12 7:32 ` Vladimir Zapolskiy 2018-10-12 9:03 ` Lee Jones 2018-10-12 13:12 ` Laurent Pinchart 2018-10-12 13:12 ` Laurent Pinchart 2018-10-12 14:36 ` Vladimir Zapolskiy 2018-10-16 14:06 ` Laurent Pinchart 2018-10-08 21:12 ` [PATCH 6/7] pinctrl: ds90ux9xx: add TI DS90Ux9xx pinmux and GPIO controller driver Vladimir Zapolskiy 2018-10-10 9:04 ` Linus Walleij 2018-10-10 9:04 ` Linus Walleij 2018-10-08 21:12 ` [PATCH 7/7] MAINTAINERS: add entry for TI DS90Ux9xx FPD-Link III drivers Vladimir Zapolskiy 2018-10-12 11:34 ` [PATCH 0/7] mfd/pinctrl: add initial support of TI DS90Ux9xx ICs Laurent Pinchart
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=369ef3ac-6f68-c450-713f-762b1c5cd5c9@mentor.com \ --to=vladimir_zapolskiy@mentor.com \ --cc=devicetree@vger.kernel.org \ --cc=kieran.bingham@ideasonboard.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=lee.jones@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=marek.vasut@gmail.com \ --cc=robh+dt@kernel.org \ --cc=vz@mleia.com \ --cc=wsa@the-dreams.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.