[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <70cdfe16-7d70-b124-b9d0-7bf51989d947@axentia.se>
Date: Wed, 19 Apr 2017 18:42:10 +0200
From: Peter Rosin <peda@...ntia.se>
To: Philipp Zabel <p.zabel@...gutronix.de>,
Steve Longerbeam <slongerbeam@...il.com>
CC: Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Sakari Ailus <sakari.ailus@....fi>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<kernel@...gutronix.de>
Subject: Re: [RFC 2/2] mux: mmio-based syscon mux controller
On 2017-04-19 18:32, Philipp Zabel wrote:
> On Wed, 2017-04-19 at 09:23 -0700, Steve Longerbeam wrote:
>>
>> On 04/19/2017 08:27 AM, Philipp Zabel wrote:
>>> On Wed, 2017-04-19 at 13:58 +0200, Peter Rosin wrote:
>>>> On 2017-04-19 13:50, Philipp Zabel wrote:
>>>>> On Thu, 2017-04-13 at 18:09 -0700, Steve Longerbeam wrote:
>>>>>>
>>>>>> On 04/13/2017 08:48 AM, Philipp Zabel wrote:
>>>>>>> This adds a driver for mmio-based syscon multiplexers controlled by a
>>>>>>> single bitfield in a syscon register range.
>>>>>>>
>>>>>>> Signed-off-by: Philipp Zabel <p.zabel@...gutronix.de>
>>>>>>> ---
>>>>>>> drivers/mux/Kconfig | 13 +++++
>>>>>>> drivers/mux/Makefile | 1 +
>>>>>>> drivers/mux/mux-syscon.c | 130 +++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>> 3 files changed, 144 insertions(+)
>>>>>>> create mode 100644 drivers/mux/mux-syscon.c
>>>>>>>
>>>>>>> diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
>>>>>>> index 86668b4d2fc52..a5e6a3b01ac24 100644
>>>>>>> --- a/drivers/mux/Kconfig
>>>>>>> +++ b/drivers/mux/Kconfig
>>>>>>> @@ -43,4 +43,17 @@ config MUX_GPIO
>>>>>>> To compile the driver as a module, choose M here: the module will
>>>>>>> be called mux-gpio.
>>>>>>>
>>>>>>> +config MUX_SYSCON
>>>>>>
>>>>>> my preference would be CONFIG_MUX_MMIO.
>>>>>>
>>>>>>> + tristate "MMIO bitfield-controlled Multiplexer"
>>>>>>
>>>>>> "MMIO register bitfield-controlled Multiplexer"
>>>>>>
>>>>>> The rest looks good to me.
>>>>>
>>>>> I'll change those. mux-syscon.c should probably be renamed to
>>>>> mux-mmio.c, too.
>>>>
>>>> I think I disagree. But I'm not familiar with syscon so I don't know.
>>>> IIUC, syscon uses regmap to do mmio and this driver requires syscon
>>>> to get at the regmap, and in the end this driver doesn't know anything
>>>> about mmio. All it knows is syscon/regmap.
>>>
>>> That is a good point. Right now there is nothing MMIO about the driver
>>> except for the hardware that I want it to handle.
>>>
>>>> If some warped syscon
>>>> thing shows up that wraps something other than mmio in its regmap,
>>>> this driver wouldn't care about it. And syscon is something that
>>>> is also known in the DT world. Given that, I think everything in this
>>>> driver should be named syscon and not mmio.
>>>>
>>
>> My argument against using the name "syscon" in the device tree is that
>> it is referring to a subsystem in the Linux kernel. Besides the fact
>> that "syscon" does not clearly describe, at least to me, what sort of
>> device this mux is.
>
> If I'm not mistaken, this point was not about the DT compatible
> property, just about the driver name.
>
> I'm also in favor of keeping the "syscon" name out of the device tree as
> far as it is still possible, for the same reasons. The i.MX6 muxes are
> MMIO register bitfield muxes, but not "syscon muxes".
The corresponding mux in the i2c-mux "sub-sub-system" is named i2c-mux-reg.
It is about "raw" mmio, i.e. w/o syscon and regmap. Just for the record...
Cheers,
peda
Powered by blists - more mailing lists