[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <469597c5-724f-08c9-ccbc-f076673e1744@xilinx.com>
Date: Mon, 17 Sep 2018 12:23:29 +0200
From: Michal Simek <michal.simek@...inx.com>
To: Jonathan Cameron <jonathan.cameron@...wei.com>,
Michal Simek <michal.simek@...inx.com>
CC: Jonathan Cameron <jic23@...nel.org>,
Manish Narani <manish.narani@...inx.com>, <knaack.h@....de>,
<lars@...afoo.de>, <pmeerw@...erw.net>, <robh+dt@...nel.org>,
<mark.rutland@....com>, <sudeep.holla@....com>,
<amit.kucheria@...aro.org>, <leoyang.li@....com>,
<broonie@...nel.org>, <arnaud.pouliquen@...com>,
<eugen.hristev@...rochip.com>, <rdunlap@...radead.org>,
<geert@...ux-m68k.org>, <ak@...klinger.de>,
<freeman.liu@...eadtrum.com>, <lukas@...ner.de>,
<vilhelm.gray@...il.com>, <gregkh@...uxfoundation.org>,
<kstewart@...uxfoundation.org>, <sgoud@...inx.com>,
<anirudh@...inx.com>, <linux-iio@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 2/4] iio: Documentation: Add Xilinx AMS sysfs
documentation
On 17.9.2018 12:06, Jonathan Cameron wrote:
> On Mon, 17 Sep 2018 11:56:08 +0200
> Michal Simek <michal.simek@...inx.com> wrote:
>
>> On 16.9.2018 12:12, Jonathan Cameron wrote:
>>> On Fri, 14 Sep 2018 12:48:28 +0530
>>> Manish Narani <manish.narani@...inx.com> wrote:
>>>
>>>> Add documentation for xilinx-ams driver. This contains information about
>>>> various voltages and temperatures on PS (Processing System), PL
>>>> (Programmable Logic) and AMS Control Block.
>>>>
>>>> Signed-off-by: Manish Narani <manish.narani@...inx.com>
>>> The more I look at this device the more I'm convinced it is very much a dedicated
>>> hardware monitoring function, not a generic ADC sensing unit at all.
>>>
>>> Hmm. It is still fine to have it in IIO but you need to think in detail
>>> about how you are going to interface this to hwmon via the iio-hwmon bridge.
>>>
>>> Some of the interface complexity should only really be apparent when we hit
>>> hwmon perhaps rather than having so many different custom interfaces in IIO.
>>>
>>> Please also loop in the maintainers and lists for hwmon in the next
>>> version so we can get their input.
>>
>> Isn't there iio-hwmon driver for this?
>>
>> Thanks,
>> Michal
>
> Absolutely. The interesting bit is that if we are planning to actually expose
> the many monitoring channels via iio-hwmon IIRC it won't use the extended names
> at all (I may have missremembered this thogh). As such we may want to reduced
> the amount of custom ABI in IIO in favour of a level of opaqueness with the
> 'real' interface provided by the iio-hwmon bridge driver. A quick glance
> suggested we may need to increase the information exposed by the iio-hwmon
> driver to make this work.
ok.
> When we have run into cases like this (a very much hardware monitoring oriented
> device with a few general purpose channels) in the past we have always gotten
> agreement from the hwmon maintainers that they are happy with using an IIO provider
> and the iio-hwmon driver route. It is just nice to keep everyone in agreement
> and have no surprises!
Definitely I agree with this.
Thanks,
Michal
Powered by blists - more mailing lists