From owner-freebsd-arm@freebsd.org Fri Jun 7 15:03:19 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 695E115AF52A for ; Fri, 7 Jun 2019 15:03:19 +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 C555375E3A for ; Fri, 7 Jun 2019 15:03:18 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1559919796; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=a7zmsqCK212jKzKGgFu3hIZ5tOKnm1GxpuJVpXl8nc++KMU2GSKg0wvPFdY0bvznyW9p+L4oiASJr xH02nwL1NAs/Cwv9aWfpsIwQx7CyTqQUUI1nUjCWUupDpUcUEorhpPuLX7wBi0GmytuRArIcrp/2+O RfhaP5sKkGhfBVcXyZWPOHIwjMflg8e22h0s+7b0OhM+GvjEtD1ytLm9iai3qkBff9gEljuDan3nv5 YmDJVpLJ68QsLrcVNAeJTwI9EI7CY5LV0mXwt3YzQGB1BatTjhLpM5Cvk/Yao8lWZ1oZwn8nZPN7Q2 qVI/VUa3hcZgJsBAA8z3Li+YsXhSeqg== 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=QThXsXKlFX8hRj962zCUdzPC9rTAlhwrm3D23kHLWNk=; b=JFqDJVn27/NTNMtQpCK4iIEcPOnph+WN60NPUR0h4HNRwFyJC0s/ewDA8+uMuUKXc8vXjccNrGXP8 LYpZlB8AjKP4cKihY7Ttfp4bTXX5+x3tazuRCiNumwCN6nAesxy3HQcetrxDwrBDxRR0UKx4/nO6IR 0hqssAygFfFv5naWnMgsjgyU+Cy+EL09dD33keYY3VNiqg89/3I+Lpu+OMIbUskDzYr2GPHhpHX/cd r9w3Hr5ddRvZxt7Kk4EP8WbYPwEg25YDwHH9Cfl5JwyJeM9gG4dl6edD4LJ5rQw/Ya0bNsGhdDx/ws 8DflUhYfSCYh8hUzPjeX2sn6pp/5ubw== 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=QThXsXKlFX8hRj962zCUdzPC9rTAlhwrm3D23kHLWNk=; b=bP0n4f/u9+wGL0lU2SzwErCNYffOsF96cGQhn3+hKP95ebPH5EaqSoyAngyclzHrxeNN5deLfnLY8 TN28J01R3lzQdLzYAl/EWKA1p5ZrXz+5jIzrLm5cTNVkgcTPZK9g1jmvi6y04B+r/1J3pNGZ7iIbHE fQrcaJ+W+LSgiu5NTqPzkCkN6z4JHMusSgGGpJr3YZnCZcXS1PQpBiegQequ7GjNOwH145KmptHdfy 4KnaZx13X0SNNPwtHwWxiFM2PH7EgSYC/ItLe3ooWKVTG3x9aRQcOKAxD8q0uP5LVc5hNV+GXtg7+i cFLNBZDajanpz+SX/Ed4vbPFuV0xICg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 5e1960bf-8935-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 5e1960bf-8935-11e9-91aa-b56e4e6b5865; Fri, 07 Jun 2019 15:03:13 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x57F3B3s072922; Fri, 7 Jun 2019 09:03:11 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <42216eebac3c497b09f83f29faf68b0c74f903ce.camel@freebsd.org> Subject: Re: How to set PWM tunable name to ehrpwm.1 ? From: Ian Lepore To: ticso@cicely.de, Nicola Mingotti Cc: freebsd-arm@freebsd.org Date: Fri, 07 Jun 2019 09:03:11 -0600 In-Reply-To: <20190607112409.GO40697@cicely7.cicely.de> References: <68790975-a5a5-2138-ca89-117878d6cf2d@gmail.com> <20190606220639.GE13546@eldorado> <8126fa4ae0ca650ca12f28dd538e6e8c4e81b432.camel@freebsd.org> <2852b9da-e647-69a7-3218-88cfa500eadc@gmail.com> <20190607112409.GO40697@cicely7.cicely.de> 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: C555375E3A 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]; ASN(0.00)[asn:16509, ipnet:52.28.0.0/16, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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:03:19 -0000 On Fri, 2019-06-07 at 13:24 +0200, Bernd Walter wrote: > On Fri, Jun 07, 2019 at 02:08:32AM -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 > > I don't know if it would work for you, but I'm a happy user of devd > for > such things. > This is devinfo -rv on a Pine64: > ... > uart0 pnpinfo name=serial@1c28000 compat=snps,dw-apb-uart > ... > I assume it is similar to what you should see on the beaglebone. > It should be easy to identify a specific device via the name= entry. > Messages to devd gets queued up and it shouldn't matter if the device > is > already attached when devd starts. > > This is what I use for USB uarts: > attach 0 { > device-name "uftdi[0-9]+"; > match "sernum" "FTYY82HD"; > match "interface" "0"; > action "rm /dev/manson_psu5; ln -s > /dev/cua$ttyname /dev/manson_psu5"; > }; > > Since uart(4) doen't offer a nice $ttyname, you have to convert the > device-name into the matching cuau* entry. > Not quite the same thing. You're using a devd rule to manipulate things in devfs. We're talking about sysctl nodes which are named after the newbus device. It would be the equivelent of making the ftdi driver install sysctl nodes that were named something other than dev.uftdi.*. -- Ian