From: Vladimir Zapolskiy <vz@mleia.com>
To: Lee Jones <lee.jones@linaro.org>,
Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: kieran.bingham@ideasonboard.com,
Laurent Pinchart <laurent.pinchart@ideasonboard.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: Fri, 12 Oct 2018 17:13:28 +0300 [thread overview]
Message-ID: <d7bfd5d8-2c85-1f82-a673-4e8d159a15d8@mleia.com> (raw)
In-Reply-To: <20181012113415.GZ4939@dell>
Hi Lee,
On 10/12/2018 02:34 PM, Lee Jones wrote:
> On Fri, 12 Oct 2018, Vladimir Zapolskiy wrote:
>> On 10/12/2018 12:20 PM, Kieran Bingham wrote:
>>> Hi Vladimir,
>>> On 12/10/18 09:39, Lee Jones wrote:
>>>> On Fri, 12 Oct 2018, Vladimir Zapolskiy wrote:
>>>>> On 10/12/2018 09:03 AM, Lee Jones wrote:
>>>>>> On Tue, 09 Oct 2018, Vladimir Zapolskiy wrote:
>>>>>>
>>>>>>> From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
>>>>>>>
>>>>>>> The change adds I2C device driver for TI DS90Ux9xx de-/serializers,
>>>>>>> support of subdevice controllers is done in separate drivers, because
>>>>>>> not all IC functionality may be needed in particular situations, and
>>>>>>> this can be fine grained controlled in device tree.
>>>>>>>
>>>>>>> The development of the driver was a collaborative work, the
>>>>>>> contribution done by Balasubramani Vivekanandan includes:
>>>>>>> * original implementation of the driver based on a reference driver,
>>>>>>> * regmap powered interrupt controller support on serializers,
>>>>>>> * support of implicitly or improperly specified in device tree ICs,
>>>>>>> * support of device properties and attributes: backward compatible
>>>>>>> mode, low frequency operation mode, spread spectrum clock generator.
>>>>>>>
>>>>>>> Contribution by Steve Longerbeam:
>>>>>>> * added ds90ux9xx_read_indirect() function,
>>>>>>> * moved number of links property and added ds90ux9xx_num_fpd_links(),
>>>>>>> * moved and updated ds90ux9xx_get_link_status() function to core driver,
>>>>>>> * added fpd_link_show device attribute.
>>>>>>>
>>>>>>> Sandeep Jain added support of pixel clock edge configuration.
>>>>>>>
>>>>>>> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
>>>>>>> ---
>>>>>>> drivers/mfd/Kconfig | 14 +
>>>>>>> drivers/mfd/Makefile | 1 +
>>>>>>> drivers/mfd/ds90ux9xx-core.c | 879 ++++++++++++++++++++++++++++++++++
>>>>>>> include/linux/mfd/ds90ux9xx.h | 42 ++
>>>>>>> 4 files changed, 936 insertions(+)
>>>>>>> create mode 100644 drivers/mfd/ds90ux9xx-core.c
>>>>>>> create mode 100644 include/linux/mfd/ds90ux9xx.h
>>>>>>>
>>>>>>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>>>>>>> index 8c5dfdce4326..a969fa123f64 100644
>>>>>>> --- a/drivers/mfd/Kconfig
>>>>>>> +++ b/drivers/mfd/Kconfig
>>>>>>> @@ -1280,6 +1280,20 @@ config MFD_DM355EVM_MSP
>>>>>>> boards. MSP430 firmware manages resets and power sequencing,
>>>>>>> inputs from buttons and the IR remote, LEDs, an RTC, and more.
>>>>>>>
>>>>>>> +config MFD_DS90UX9XX
>>>>>>> + tristate "TI DS90Ux9xx FPD-Link de-/serializer driver"
>>>>>>> + depends on I2C && OF
>>>>>>> + select MFD_CORE
>>>>>>> + select REGMAP_I2C
>>>>>>> + help
>>>>>>> + Say yes here to enable support for TI DS90UX9XX de-/serializer ICs.
>>>>>>> +
>>>>>>> + This driver provides basic support for setting up the de-/serializer
>>>>>>> + chips. Additional functionalities like connection handling to
>>>>>>> + remote de-/serializers, I2C bridging, pin multiplexing, GPIO
>>>>>>> + controller and so on are provided by separate drivers and should
>>>>>>> + enabled individually.
>>>>>>
>>>>>> This is not an MFD driver.
>>>>>
>>>>> Why do you think so? The representation of the ICs into device tree format
>>>>> of hardware description shows that this is a truly MFD driver with multiple
>>>>> IP subcomponents naturally mapped into MFD cells.
>>>>
>>>> This driver does too much real work ('stuff') to be an MFD driver.
>>>> MFD drivers should not need to care of; links, gates, modes, pixels,
>>>> frequencies maps or properties. Nor should they contain elaborate
>>>> sysfs structures to control the aforementioned 'stuff'.
>>>>
>>>> Granted, there may be some code in there which could be appropriate
>>>> for an MFD driver. However most of it needs moving out into a
>>>> function driver (or two).
>>>>
>>>>> Basically it is possible to replace explicit of_platform_populate() by
>>>>> adding a "simple-mfd" compatible, if it is desired.
>>>>>
>>>>>> After a 30 second Google of what this device actually does, perhaps
>>>>>> drivers/media might be a better fit?
>>>>>
>>>>> I assume it would be quite unusual to add a driver with NO media functions
>>>>> and controls into drivers/media.
>>>>
>>>> drivers/media may very well not be the correct place for this. In my
>>>> 30 second Google, I saw that this device has a lot to do with cameras,
>>>> hence my media association.
>>>>
>>>> If *all* else fails, there is always drivers/misc, but this should be
>>>> avoided if at all possible.
>>>
>>> The device as a whole is FPD Link for camera devices I believe, but it
>>
>> I still don't understand (I could be biased though) why there is such
>> a strong emphasis on cameras and media stuff in the discussion.
>>
>> No, "the device as a whole is FPD Link for camera devices" is a wrong
>> statement. On hand I have a number of boards with serializers/deserializers
>> from the TI DS90Ux9xx IC series and sensors are NOT connected to them.
>>
>>> certainly has different functions which are broken out in this
>>> implementation.
>>
>> No, there is absolutely nothing broken out from the presented MFD drivers,
>> the drivers are completely integral and basically I don't expect any.
>>
>> If you are concerned about media functionality, the correspondent MFD
>> *cell* drivers will be added into drivers/media, drivers/gpu/drm or
>> whatever is to be a proper place.
>>
>>> I think it might be quite awkward having the i2c components in
>>> drivers/i2c and the media components in drivers/media/i2c, so what about
>>> creating drivers/media/i2c/fpd-link (or such) as a container?
>>
>> I open drivers/media/i2c/Kconfig and all entries with no exception are
>> under from 'if VIDEO_V4L2'. The MFD drivers do NOT require on depend on
>> VIDEO_V4L2 or any other multimedia frameworks, nor the MFD drivers export
>> any multimedia controls.
>>
>>> Our GMSL implementation is also a complex camera(s) device - but does
>>> not yet use the MFD framework, perhaps that's something to add to my
>>> todo list.
>>>
>>
>> Okay, but the TI DS90Ux9xx is NOT a camera device, and it is NOT a multimedia
>> device, but it is a pure MFD device so the argument is not applicable.
>
> You keep saying that "this is an MFD device" without any obvious
> comprehension of what an MFD is. Just saying that it is one
> over-and-over does not make it so.
> An MFD should be little more than parent to other functional devices.
> Their role is to register children which in turn conduct operations
> on the hardware in a useful way. Some MFDs also house common functions
> to save repetition of code in each of the child devices. They do not
> tend to offer any useful functionality (stuff) in their own right.
This describes the presented MFD driver quite closely, if I remove
a few OF controls from ds90ux9xx-core.c:
* ti,video-map-select-*,
* ti,pixel-clock-edge,
* ti,spread-spectrum-clock-generation
Then the MFD device driver will not have any useful functionality
apart of what you've listed above, please feel free to recheck.
Should I just go ahead and do the change with the assumption that
the modified MFD driver suits MFD framework?
> As I already mentioned, you need to figure out what this device is
> and move all of the functionality into the appropriate subsystem.
By definition as I comprehend it only MFD cell device drivers should
be relocated into the correspondent subsystems, but ds90ux9xx-core
remains in drivers/mfd, no?
Probably ds90ux9xx-i2c-bridge cell driver could enter drivers/misc.
> Since an MFD isn't a real thing/device (it's a Linuxy-shim which
> only serves to register sub-devices and (sometimes) provide a space
> for common functionality to be located), drivers/mfd is not the
> subsystem which you seek.
Oh, that's exactly the case with DS90Ux9xx driver 'ds90ux9xx-core.c',
it's just a common place to store the shared boilerplate code
snippets for all cell device drivers and various flavours of ICs
from the series.
>>> We currently keep all of the complexity within the max9286.c driver, but
>>> I could foresee that being split further if more devices add to the
>>> complexity of managing the bus. At which point we might want an
>>> equivalent drivers/media/i2c/gmsl/ perhaps?
>
--
Best wishes,
Vladimir
next prev parent reply other threads:[~2018-10-12 14:13 UTC|newest]
Thread overview: 62+ 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-12 11:44 ` Laurent Pinchart
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-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-17 15:02 ` Rob Herring
2018-10-12 12:01 ` Laurent Pinchart
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 8:39 ` Lee Jones
2018-10-12 9:20 ` Kieran Bingham
2018-10-12 10:58 ` Vladimir Zapolskiy
2018-10-12 11:34 ` Lee Jones
2018-10-12 14:13 ` Vladimir Zapolskiy [this message]
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
2018-10-16 13:12 ` Laurent Pinchart
2018-10-16 18:32 ` Vladimir Zapolskiy
2018-10-13 12:33 ` 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 9:03 ` Lee Jones
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-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=d7bfd5d8-2c85-1f82-a673-4e8d159a15d8@mleia.com \
--to=vz@mleia.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=vladimir_zapolskiy@mentor.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).