From owner-freebsd-arm@freebsd.org Fri Jun 7 17:23:15 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 F409C15B284E for ; Fri, 7 Jun 2019 17:23:14 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 E576083053; Fri, 7 Jun 2019 17:23:13 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: by mail-pl1-x643.google.com with SMTP id i2so1083576plt.1; Fri, 07 Jun 2019 10:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=IhUgUYMa69H4SvxDraCcUKHRjKotwtrMgvey9psmQYo=; b=cFiSeFc2NmGazAvE0mUJVizR9iMgx2r6OuoZYMx+nPqsb7JzVSzA5oBW15gtfpSfNK QEPL2oQ1swcRFOBp19orgOpOCA/jk0/N15DDMURX8kroRNND2wR915VSDN7cPXROkgpA +WlN09GC9fBOLMlVfNiVDjoLBBFEbxePhtSbpUaWhesXl1AxWB5LOqXRRmUEcHZsMaeF CaIte1GvHG6YpboiYzS0wKv5JvA7Jw7nhypuD3/KG8+RjWDGoyMwDzod7Rv4XUxyPmY8 AbscEeW8gF96RjBke0pVB2Ly1Fk2bA3H79D1sN6GVX638a5M8/Opl5XqOkoMqlCckoFD 4dGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=IhUgUYMa69H4SvxDraCcUKHRjKotwtrMgvey9psmQYo=; b=haTeLL7uFAQWnhztiVH6MTzsJPvEqhZaMKkBrwhB85673+6qfN9kH34Vjyyzt54W/P 4aaerdsLDYkQQQrgbhq//RMBPAI7ifls8+c3I6xtBQbJQs+tC93tWzoCJGgjZcsaZ06d H7uJ2WOq53bAzgmWjOqNfeC3IFEWwoS5ckGhx5l6zVHnlNK7RPyTNpyu6B3dX9Ds0KdL LKACYMl1MC/l+r7Ww+GEgDKAFgSH3DCkb9mppMQIbaTypf4bPcGQPb/+n7iM5UTm9QCD WzNPR9a91Jz8lHX3DIIYGn34AI3UvzamR8QBMROxQ8xT/taoepzoZOE8yNnVZvnC4we3 09uQ== X-Gm-Message-State: APjAAAVcHnNEmNkz9uByTA4EG2CSLE03iDqm54rTppSN48PlqJD9vlXT lDLKCv8SIL/PiduvTYNqsfxmCr9/Z4w= X-Google-Smtp-Source: APXvYqx2V7Hb3Q/apxDZhQemY5LFIivrAiuLhaQgiCppq5mfiGfG3ZO6MieDyaidV8dgyohd2AgW7A== X-Received: by 2002:a17:902:22:: with SMTP id 31mr55248282pla.15.1559928188944; Fri, 07 Jun 2019 10:23:08 -0700 (PDT) Received: from [172.16.144.128] (lcls-pc94808.slac.stanford.edu. [134.79.72.78]) by smtp.gmail.com with ESMTPSA id g8sm2897538pfi.8.2019.06.07.10.23.07 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jun 2019 10:23:07 -0700 (PDT) Subject: Re: How to set PWM tunable name to ehrpwm.1 ? To: Ian Lepore , Sergey Manucharian Cc: nmingott@gmail.com, freebsd-arm@freebsd.org References: <68790975-a5a5-2138-ca89-117878d6cf2d@gmail.com> <20190606220639.GE13546@eldorado> <8126fa4ae0ca650ca12f28dd538e6e8c4e81b432.camel@freebsd.org> <2852b9da-e647-69a7-3218-88cfa500eadc@gmail.com> From: Nicola Mingotti Message-ID: Date: Fri, 7 Jun 2019 10:23:06 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Rspamd-Queue-Id: E576083053 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=cFiSeFc2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of nmingotti@gmail.com designates 2607:f8b0:4864:20::643 as permitted sender) smtp.mailfrom=nmingotti@gmail.com X-Spamd-Result: default: False [-3.97 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.96)[-0.956,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(-1.00)[ip: (0.58), ipnet: 2607:f8b0::/32(-3.22), asn: 15169(-2.30), country: US(-0.06)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[3.4.6.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]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_CC(0.00)[gmail.com] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 17:23:15 -0000 On 6/7/19 7:58 AM, 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.) > > 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 > > Ian, this |freebsd,sysctl = "foobar"| to me sounds as a very good solution. In this way I could name the tunable with the "hardware name" or also with the functional name, as "pwm-motor-front-left". This would improve the readability of underlying software structure. That would be beautiful. n.