From owner-freebsd-arm@freebsd.org Fri Jun 7 15:17:14 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 0017515AF922 for ; Fri, 7 Jun 2019 15:17:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2809176432 for ; Fri, 7 Jun 2019 15:17:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x729.google.com with SMTP id a27so1467500qkk.5 for ; Fri, 07 Jun 2019 08:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2a0Tyx7cPlSJw50p1bW3ju/+ZP6YEf+Dgr7tN3Ph+OE=; b=1BGoD2uDXx/hXcWBGCnLdMS6dUUDI9u9FfDsgfyNJ+8m2jCG5QPcXPmgZVjGNlQHT+ 0A4IMARg+TXK7mVeAnEXU6Cw4ej1RG/I3mQaz4Ctza7u929N+r/umk8C56B1CsWnUD89 az1mPIqQHbBPrSKYEW60BzbXt+PEBKbJPQ7Txk62voqb8c0z1a01JYhENHQEoHEKyJ3V otVphLxAaabI5aox+Cq/2gwNNVFsYCJTGLv7utUSbqCg3oz9LMZbjzlp3MfWNNESfth6 P18G80TjmSh5Qu/cBaz6v2Zl8lhmAGHAe6wGrmWtAxD3dtUIMpNND8BnogeQ36RBum+8 HJDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2a0Tyx7cPlSJw50p1bW3ju/+ZP6YEf+Dgr7tN3Ph+OE=; b=KC4wLZIG5r+0Xf6/F6QnSnkaUmIwJJX6Uc9DzvBqCjUe9KSm7eqJDy6CT8tzhnyEcn peWav4dCw215XCWf/s/iX92saCsn57CcniWI3Zyhx3Wrgo1nXSImxpjobbXW0kZPlQKp 0me2rAc5iN1VskMybHKCKa39FKcDcO/FgL3g1bNdzBDbt/wAj4FSkZ//7XYnbgCJmBbA WqmVUORFAlqKCzlrcB2b41i8FyannGw21P1HtFlmw7XH/r/kqkXpfw9DKJEk3y/DXRBF 8bE92h87bajS0pB6DJXmb2+2YKl1BoUaMD8zWkWr9ZnOxwhoiEUVZySFzNhUlUICU5JP l+MA== X-Gm-Message-State: APjAAAX2wJJehvtFZIpP1mYPeMJ3rl64qkY8iBJSGKOLiJGfuASGDtb4 EHU5PDR4l6H0ysHuXABBoKg5R87d+IFxj9H86b+OLQ== X-Google-Smtp-Source: APXvYqxuTXPMwz33oKpfulrQcFybYL8xgNNN7P9jlGtUuosRHKli+ywwEHaBrFQKk7oLI6UKOhmAo+ZHV5wJy0LA+3k= X-Received: by 2002:a37:5942:: with SMTP id n63mr31799666qkb.69.1559920632156; Fri, 07 Jun 2019 08:17:12 -0700 (PDT) MIME-Version: 1.0 References: <68790975-a5a5-2138-ca89-117878d6cf2d@gmail.com> <20190606220639.GE13546@eldorado> <8126fa4ae0ca650ca12f28dd538e6e8c4e81b432.camel@freebsd.org> <2852b9da-e647-69a7-3218-88cfa500eadc@gmail.com> <20190607171001.636efb2598ab9c88635973b6@bidouilliste.com> In-Reply-To: <20190607171001.636efb2598ab9c88635973b6@bidouilliste.com> From: Warner Losh Date: Fri, 7 Jun 2019 09:17:01 -0600 Message-ID: Subject: Re: How to set PWM tunable name to ehrpwm.1 ? To: Emmanuel Vadot Cc: Ian Lepore , nmingott@gmail.com, "freebsd-arm@freebsd.org" X-Rspamd-Queue-Id: 2809176432 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=1BGoD2uD X-Spamd-Result: default: False [-4.92 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(-2.99)[ip: (-9.39), ipnet: 2607:f8b0::/32(-3.22), asn: 15169(-2.30), country: US(-0.06)]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[9.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.92)[-0.917,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 15:17:14 -0000 On Fri, Jun 7, 2019 at 9:11 AM Emmanuel Vadot wrote: > On Fri, 07 Jun 2019 08:58:49 -0600 > Ian Lepore wrote: > > > 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.) > > Relying on the name is clearly not a good idea, especially for TI > since they change stuff A LOT. > > > 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 > > What would be better is to add support to the pwm(9) api for this > driver and make the api and pwm(8) using the "pwm-names" property which > is a standard one from the bindings. > For this specific case, I think that's great. I'd go farther than say we should have the FDT/OFW node name, if any, associated with something like dev...node_name. Warner