From owner-freebsd-arm@freebsd.org Fri Jun 7 14:58:59 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60AE315AF19C for ; Fri, 7 Jun 2019 14:58:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1.eu.mailhop.org (outbound1.eu.mailhop.org [52.28.251.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8601D75999 for ; Fri, 7 Jun 2019 14:58:58 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1559919535; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=RI3rqtDnS5UIO2RsacffYp3JiM4TcRMTw0uYgdf4Q5PGr5U9jKwiSrdiVloVuhWPV81UleqmloKfL 5SmdIVrBEHAbhKI+cf7CnfbBJD4yZATK8LjK7bFre+tWCEBb9NvWb1nZVXFA4vTdjyRQt7IGBo6Ziu F3RK2+Y3pDhY/WOImvQGpUP46JgCWcw+MbCCwZ9YScUlhZTi0a21oIsMjLpzCFCQ26j7Sc07ApEedG WPAtkBsskjrmQTw7Ceu113odDOYxfHY4sR3+4V4lCeVZTUpJKz7567OO+TCEHtnTpJgkjABNz4EAFW bav76wJwo8ns6wSHBspOc8MzKtfYZDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=TiCtm3a7Ks8jR/y79BZaWJG3Ce0VONxE4JblJd9/+qY=; b=NmfN8W4Fn9cVThl8NtpFweECjIpH/5wTTs0W1lJyoeCtTFdFsVS3O9dkYRYBmbWyR6tlvazya4dlT P1ZoTsYcbFQcOOlYvcxUGNhvb8iCRUn1G7b3CbeOdFunXv0d8fe02GOf3Oup57ofJ1i0yX/NBSXFi/ eg4Q/npqiFPUA4lOifHwiYuBTwuOahEgVRgi3vHFhLnV26u7IB+BSGHCPz+2li+oV/cpX7lPIY6Mxm wbCF8rMOk4v2WHiGeoV6w7i1XG3JmeVIYpAXdpZhzv6mwmaIrn4GsfY++cm8988jlC97BxJYGQIRx4 w0S/H/FL/XB2NRdD4Lh9lIwn4pZEbsg== ARC-Authentication-Results: i=1; outbound3.eu.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=TiCtm3a7Ks8jR/y79BZaWJG3Ce0VONxE4JblJd9/+qY=; b=ZKXbhoKau6Udi6YIXhNNDURfCY0136YkaEUpNo9xk+jkyVyDVW7U3F1xI06/M1FBxenwYE399e/Bt CwS9kFB9MrTsKca4M2mnPuzRZArZTqKxkZVsFLxVI1SkVRdlIkZfetb+Kpbl45Itq3YJhCBDrbs51/ MSboFpzZg9IdkYY2+71rBWX4iZjiXqsI/Vnp4zA5nrhpfaLuRpNdVrpouK0gyH8kcpXXJjCAc0ytdC DxV2LCbpEEfT5yAlfRznCZ64YA8PbLKTZqJBXJ4CbmtvWrQR3iywPxAx2O6bFIm0poyERFx3CPg6xj GMzCutWbKNLHW6+YFWxo1pnnzy2+cVg== X-MHO-RoutePath: aGlwcGll X-MHO-User: c25e393b-8934-11e9-91aa-b56e4e6b5865 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.eu.mailhop.org (Halon) with ESMTPSA id c25e393b-8934-11e9-91aa-b56e4e6b5865; Fri, 07 Jun 2019 14:58:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x57EwnCK072893; Fri, 7 Jun 2019 08:58:49 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: How to set PWM tunable name to ehrpwm.1 ? From: Ian Lepore To: Nicola Mingotti , Sergey Manucharian Cc: nmingott@gmail.com, freebsd-arm@freebsd.org Date: Fri, 07 Jun 2019 08:58:49 -0600 In-Reply-To: <2852b9da-e647-69a7-3218-88cfa500eadc@gmail.com> References: <68790975-a5a5-2138-ca89-117878d6cf2d@gmail.com> <20190606220639.GE13546@eldorado> <8126fa4ae0ca650ca12f28dd538e6e8c4e81b432.camel@freebsd.org> <2852b9da-e647-69a7-3218-88cfa500eadc@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8601D75999 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.984,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 14:58:59 -0000 On Fri, 2019-06-07 at 02:08 -0700, Nicola Mingotti wrote: > > On 6/6/19 3:40 PM, Ian Lepore wrote: > > On Thu, 2019-06-06 at 16:06 -0600, Sergey Manucharian wrote: > > > Excerpts from Nicola Mingotti's message from Thu 06-Jun-19 12:33: > > > > In my BeagleBone Black, FreeBSD-12 RELEASE, i created two > > > > overlays, > > > > pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22 > > > > and > > > > respectively p9.14, p9.16. DTSO files are below. > > > > > > > > If I load both the DTBO at boot I see > > > > correctly|ehrpwm.0|and|ehrpwm.1|, > > > > associated to the correct pins. But, if i remove the > > > > overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|, which > > > > is > > > > not > > > > what i want, i would like to see the name|ehrpwm.1|. > > > > > > > > This is important because i must be 100% sure a certain pin > > > > corresponds > > > > the a certain tunable.This must be true even if i remove non > > > > relevant > > > > overlays in the future. I guess there must be some parameter in > > > > the > > > > DTSO > > > > which i don't know, i hope you can give me some directions > > > > about > > > > that. > > > > > > It is not related to your DTBO's. That's how everything works (at > > > least > > > by default). You will see the same naming issue with serial > > > ports, > > > for > > > example. And not just in BBB. > > > > > > E.g. when I have enabled uart0 and uart2 they are named ttyu0 and > > > ttyu1, > > > if I have only uart2, it becomes ttyu0. > > > > > > It's easier if there is a device node in /dev, so you can create > > > a > > > symlink > > > with a fixed name (I have a script called by devd for my multiple > > > serial > > > ports). However, that's not the case with PWM... > > > > > > Maybe there is an option to use persistent names for devices that > > > somebody > > > can point to. > > > > > > > Nope, there's no magic thing you're missing that fixes > > this. Devices > > get named-and-numbered based on the order of instantiation. > > > > Since what really matters here is the sysctl names, we could change > > the > > driver to install the sysctl nodes using the fdt device node names > > instead of the freebsd newbus device names. Hmm, actually, since > > people may be relying on the current names, I guess what we'd have > > to > > do is install another set of sysctl names based on fdt name > > (basically > > a set of alias names). > > > > -- Ian > > > > I see, I agree changing the default naming scheme may damage who is > relaying on it. It is not a good idea. Maybe it could be implemented > in > release 13. > > To Sergey. I used devd in the past, it works well. But i would > prefer > not to use it in this case, even if I had a /dev/xyz file available. > The > reason is that the /dev/xyz file would appear before the the devd > daemon > starts up (i guess), so the case would not stricly be covered by > what > the devd man page says devd should do. > $> man devd > => " ... Whenever a device is added to or removed from the device > tree ... " > > To Ian. The idea of the alias seems good. I don't know at all what > you > can manage to do at the kernel level with the tunables. I imagine > something like |dev.alias.am335x_ehrpwm.1| which actually refers to > > EHRPWM1| not the second |ehrpwm| that got plugged into the system > > via > > overlay. > > Thank you for your answers > > The dev.* hierarchy is managed by newbus; what I was picturing was something like hw.ehrpwm1.freq and so on, settable as either tunable or sysctl. But it turns out ehrpwm1 is just a label in the dts, not accessible at runtime. The actual node name is just 'pwm' and really, nothing prevents upstream from changing that name on a whim next time we import new dts files. (And linux sure seems to have a lot of arbitrary whims when it comes to changing dts.) Since an overlay is required to use this stuff anyway, I'm now thinking a custom property in the overlay that names the sysctl nodes might be a good option. So you'd add a property like: &ehrpwm0 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&ehrpwm0_AB_pins>; freebsd,sysctl = "backlight"; }; And that would make it install names like hw.backlight.freq and hw.backlight.period and so on. If you don't add that property, it just installs the names it uses now (dev.ehrpwm.*) for compatibility. -- Ian