mt7621 GPIO mapping mystery

Sat Jan 21 08:27:01 PST 2023

Hi.

W dniu 21.01.2023 o 16:33, Lukas Zeller pisze:
> Hi Sergio, thanks for the reply!
> 
> On 21 Jan 2023, at 14:00, Sergio Paracuellos <sergio.paracuellos at gmail.com> wrote:
> 
>> On Sat, Jan 21, 2023 at 1:19 PM Lukas Zeller <luz at plan44.ch> wrote:
>>> [...]So while I understand that using only the DT mechanisms for configuring GPIO modes, named gpios and libgpiod instead of /sys/class/gpio etc. is the way to go, I must also state that without loadable DT overlays, this essentially makes openwrt unsuitable for experimental/educational devices.
>>
>> Configure the GPIO modes is not something that is expected to be done
>> by a user since all of that belongs to the pinctrl driver space and
>> AFAIK linux kernel people are not thinking in doing pinctrl driver
>> user-space tools.
> 
> Apparently, yes.
> 
> I also fully understand this from a system designer's point of view.
> 
> What pin is connected to what external hardware, is something that is, in a given system, on a given PCB, pretty immutable and thus DT is the correct and only place to also define it in a way that is immutable between flashing firmwares.
> 
>> The libgpiod is useful to detect and set to on and
>> off different pins (among other pure GPIO operations) but from the
>> already function GPIO set up in them.
> 
> This draws a pretty arbitrary boundary for what a educational/experimental use consists of. Toggling predefined GPIOs on and off, yes, using the same pin for PWM (say, GPIO18 on MT76x8), no? rotary-encoder? W1? GPIO-based SPI, I2C?
> 
>> I am not doing the rules,
> 
> :-)
> 
>> I am just saying the things that are now in the kernel and user space as I
>> think they are. As I have already said, I am not an expert in this
>> topic at all but maybe if we want to do such complex things like
>> configuring the mode of a pin from user space some kind of user space
>> drivers need to be provided in some way... So, if openWRT is using
>> linux kernel, at the end they have to also live with kernel people's
>> decisions in some way...
> 
> In some way.
> 
> But OpenWrt does patch the kernel to adjust things that Linux mainline does not provide.
> 
> So it *is* an OpenWrt question whether to support HW tinkering and to what degree.
> 
> Having that loadable DT overlay patch (which works on 5.10, I'm using it) as a menuconfig option disabled by default would have two benefits:
> 
> - going with the linux kernel way, to have these HW config things in the DT, and only there.
> 
> - one single, completely HW independent switch, off by default, to allow HW experiments or not (compiling in the dynamically loadable DT overlays code).
> 
> Builds for targets that *want* to be open for educational/experimental HW tinkering, with the set of risks that comes with that, can set this switch. All normal router targets will not set set it, and thus are not affected.
> 
> I think this would be better and easier to maintain, than reverting back to driver-level hacks like we had in 19.x with *_gpio_custom and friends.
> 
> So basically, I'm suggesting to revisit the decision to reject the patch from Daniel Golle [1].

Instead of doing it the hard way of patching, why not using out-of-tree kernel
module[2] for loading dtb overlay with configfs? It already exists for some
time. Unfortunately I didn't test it, as the board I wanted to use it has gone
in flames. For ready to use recipe see the attachment. Feel free to submit it
to packages feed and take over maintainership after giving it a test.

> [1] http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037139.html

2. https://github.com/ikwzm/dtbocfg

-- 
TMN
-------------- next part --------------
# SPDX-License-Identifier: GPL-2.0-only
#
# Copyright (c) 2022 Tomasz Maciej Nowak <tmn505 at gmail.com>

include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/kernel.mk

PKG_NAME := dtbocfg
PKG_VERSION := 0.0.9
PKG_RELEASE := 1

PKG_LICENSE := BSD-2-Clause
PKG_LICENSE_FILES := LICENSE

PKG_SOURCE_PROTO := git
PKG_SOURCE_URL := https://github.com/ikwzm/dtbocfg.git
PKG_SOURCE_VERSION := 2d5593ba4fea35b75fce716a5d9538f984493cbd
PKG_MIRROR_HASH := 7cbb8aa089dc3d261ea5461297a970aa3d4cb667b9459850969eec233f409898

PKG_MAINTAINER := Tomasz Maciej Nowak <tmn505 at gmail.com>
PKG_BUILD_PARALLEL := 1
PKG_FLAGS := nonshared

include $(INCLUDE_DIR)/package.mk

define KernelPackage/fs-dtbocfg
  SUBMENU := Filesystems
  TITLE := Device Tree Blob Overlay Configuration File System
  DEPENDS := +kmod-fs-configfs @!TARGET_bcm27xx
  FILES := $(PKG_BUILD_DIR)/dtbocfg.ko
  AUTOLOAD := $(call AutoLoad,31,dtbocfg,)
endef

define KernelPackage/fs-dtbocfg/description
 Device Tree Overlay is a mechanism that enables dynamic loading/unloading
 of a new device tree blob on top of the kernel device tree.
endef

define Build/Compile
	$(KERNEL_MAKE) M="$(PKG_BUILD_DIR)" modules
endef

$(eval $(call KernelPackage,fs-dtbocfg))