Re: [RFC 2/2] mux: mmio-based syscon mux controller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxxxxxx>
>>>>>>> ---
>>>>>>>   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

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux