Re: Interfacing devices with multiple parents within newbus
On 07/06/12 22:45, Arnaud Lacombe wrote: Hi, On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: Hi, On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombelacom...@gmail.com wrote: That's neither correct nor robust in a couple of way: 1) you have no guarantee a device unit will always give you the same resource. this raises the following question: how can a device, today, figure out which parent in a given devclass would give it access to resources it needs. Say, you have gpiobus0 provided by a superio and gpiobus1 provided by the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 attachment is conditional to some BIOS setting. How can you tell gpioled(4) to attach on the chipset provided GPIO without hardcoding unit number either way ? AFAIK, you can not. Even hints provided layout description is defeated. Each device in a given devclass need to have a set of unique attribute to allow a child to distinguish it from other potential parent in the same devclass... - Arnaud Talking about a child being unable to choose the correct parent seems to indicate that this whole problem is turned upside-down somehow; children don't choose their parents. I am unsure whether I understand the problem completely, but.. actually, I think I was wrong, I thought device were attached to a devclass, but they are truly attached to a given device. My mistake. Just blue-sky dreaming here on the fly... what we really have is a resource-management problem. A device comes along that needs a GPIO resource, how does it find and use that resource? Well, we have a resource manager, could that help somehow? Could a driver that provides access to GPIO somehow register its availability so that another driver can find and access it? The resource may be a callable interface, it doesn't really matter, I'm just wondering if the current rman stuff could be leveraged to help make the connection between unrelated devices. I think that implies that there would have to be something near the root of the hiearchy willing to be the owner/manager of dynamic resources. I agree, that on a very abstract level, this is exactly how this should work. In my opinion, what we need here is: a) A way for a driver to locate the resource it needs. That can be done using FDT facility. If the driver knows, that it needs certain resource (like memory, gpio or whatever else), it could process DTB (using OF_*) looking up the node holding that resource. b) Knowing the node (phandle or name), OS could locate appropriate device_t (or even driver) in the tree-hierarchy created by fdtbus (e.g. by iterating by every device_t in the tree). Each device_t created by fdtbus (or simplebus) does keep the information about the DTS (or DTB) node name via ivars. So iterating through device_t-s, we could compare node names hold in ivars with the name of the node for needed resource, and thus find proper device_t. I think this is not currently possible. Note, that other way around -- getting node's phandle based on device_t *is* implemented via ofwbus(fdtbus_ofw_get_node()). I think if this is really needed, ofwbus(fdtbus) could be easily extended by adding a routine like fdtbus_ofw_get_device_for_node(). -LW AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. The more I think about it, the more FTD is the answer. The open question now being how to map a flexible device structure (FTD) to a less flexible structure (Newbus) :/ - Arnaud ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
R flag in newsyslog works incorrect
Hi All,
Looks as R flag with archiving works incorrect, for example:
root@mhome:/tmp/test# less nsl.cfg
/tmp/test/test.log micro:wheel 640 20 10 * BZR
/tmp/test/test.sh
root@mhome:/tmp/test# less test.sh
echo atata
root@mhome:/tmp/test# newsyslog -vF -f nsl.cfg
Processing nsl.cfg
/tmp/test/test.log 20Z: size (Kb): 1 [10] -- trimming log
Signal all daemon process(es)...
Run command: /tmp/test/test.sh 1
atata
Pause 10 seconds to allow daemon(s) to close log file(s)
Compress all rotated log file(s)...
newsyslog: log /tmp/test/test.log.0 not compressed because daemon(s) not
notified
http://micro.heavennet.ru/patch/newsyslog.patch fix it.
root@mhome:/tmp/test# newsyslog -vF -f nsl.cfg
Processing nsl.cfg
/tmp/test/test.log 20Z: size (Kb): 68 [10] -- trimming log
Signal all daemon process(es)...
Run command: /tmp/test/test.sh 1
atata
Pause 10 seconds to allow daemon(s) to close log file(s)
Compress all rotated log file(s)...
Could you please review and fix it.
Thanks in advance!
--
With Best Regards,
Ilya A. Arkhipov--- newsyslog.c_old 2012-07-07 14:49:41.502135608 +
+++ newsyslog.c 2012-07-07 14:48:09.425136998 +
@@ -1972,7 +1972,7 @@
else
pgm_name++;
- if (zwork-zw_swork != NULL zwork-zw_swork-sw_pidok = 0) {
+ if (zwork-zw_swork != NULL zwork-zw_swork-sw_pidok = 0
!zwork-zw_swork-run_cmd ) {
warnx(
log %s not compressed because daemon(s) not notified,
zwork-zw_fname);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interfacing devices with multiple parents within newbus
Am 06.07.2012 um 17:33 schrieb Arnaud Lacombe: I assume you are talking about devclass_get_device()/device_find_child(). That's neither correct nor robust in a couple of way: 1) you have no guarantee a device unit will always give you the same resource. 2) there is no reference counting on the returned device. 3) there is no track record of the reference being given. About (1), lower unit devices can fails to attach[0], thus newly attached bus will now have a negative offset. About (2) and (3), referenced device (think KLD) might go away and the child will not be told. In this situation, I want the child to be detached prior to its parent. As such, looking up other node by name would fit in what I call bypassing newbus purpose. I might just as well export a damn function pointer and make my life easier. I believe there is one more thing that needs to be addressed, which I ran into while trying to do the arge/mdio attachment: 4) the device attach method may require access to the other device to complete the attachment, but that other might not be attached yet. Circular dependencies nonwithstanding, it would be highly desirable for a device driver developer to be able to simply declare all prerequisites for attachment, and have newbus call attach only after everything is there. Right now, the drivers attach method is called by the parent bus as soon as enumeration is completed. A notification mechanism (similar to the devfs notification but with an exposed KPI) might be an alternative, as mentioned in this thread. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Occassional permission denied in the middle of a large transfer over NFS
On 01/07/2012 12:18, Rick Macklem wrote: Vincent Hoffman wrote: On 01/07/2012 01:53, Rick Macklem wrote: To modify mountd to use the kernel changes is more work than I have time for, in part because mountd.c is a very ugly old piece of C code, imho. I do have a patch that suspends/resumes execution of the nfsd threads (new, experimental for FreeBSD8.n only) when mountd reloads /etc/exports. This approach has certain disadvantages vs Andrey's transactional load/commit model, but it is simple and might be sufficient for your problem. If you want to try this patch, it is at: http://people.freebsd.org/~rmacklem/atomic-export.patch (The patch affects both the kernel and mountd.c.) Happy to try it, to be certain I have understood, this is for the newnfs server (experimental in 8.x default for 8 9+) Yes, that is correct. For the old (default on 8.x) it will have no effect. I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm when i get a minute. Also, to enable it, you must add a -S flag to mountd_flags, after you've replaced the mountd executable. The patch is pretty straightforward, but has not seen much testing. Hopefully, it might be useful for you, rick Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt x nopatch.txt + atomicpatch.txt +--+ | * | | * | | x* | | xx* x | | +x** xx | | xxx x | | xxx +x+ + | | +*xx +x+ x + | | +*xx + + x | | *+*xx+ +++x * x x | | x**++*x+***x+ x*+ x ++*+ + x+ +x + + +| |||___M_M_A__A___|__| | +--+ N Min MaxMedian AvgStddev x 101 1.25 106.8 14.08 21.892178 22.196005 + 101 1.21186.93 18.46 27.995842 30.523218 No difference proven at 95.0% confidence (excuse wrapped ascii art) I think I'll have a look at the nfse patch set and see how that performs. Thanks for all your work on NFS on FreeBSD. Vince Also, you could easily hack mount.c so that it doesn't send a SIGHUP to mountd (which causes the exports to be reloaded) every time a local fs is mounted. True and I may have to do that for the production NAS for the time being. Thanks for looking at this. Vince rick thanks, Vince ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice:
Doug Barton writes:
/me officially gives up with that libreoffice port, open for
new volunteers
If you don't have time to work on the port, then don't, that's
not a problem. But throwing a hissy fit here doesn't help at all.
Cut tha man some slack.
As far as I can tell, he's been point - and often _only_ -
person wrangling the herd of 250 pound cats that is LibreOffice (and
posibly OpenOffice before that).
At this he has done a superior job. However, there has
recently been {subtle, tenacious} breakage that a) is not his fault,
b) he's gotten a lot of complaints about from people who don't
understand what's involved (you're not on that list), even though c)
he's been working hard to find and fix the problem.
If he wants a moment to vent, and maybe ask is this worth it?
... he's earned it.
Robert Huff
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interfacing devices with multiple parents within newbus
On Jul 7, 2012, at 6:25 AM, Stefan Bethke wrote: Am 06.07.2012 um 17:33 schrieb Arnaud Lacombe: I assume you are talking about devclass_get_device()/device_find_child(). That's neither correct nor robust in a couple of way: 1) you have no guarantee a device unit will always give you the same resource. 2) there is no reference counting on the returned device. 3) there is no track record of the reference being given. About (1), lower unit devices can fails to attach[0], thus newly attached bus will now have a negative offset. About (2) and (3), referenced device (think KLD) might go away and the child will not be told. In this situation, I want the child to be detached prior to its parent. As such, looking up other node by name would fit in what I call bypassing newbus purpose. I might just as well export a damn function pointer and make my life easier. I believe there is one more thing that needs to be addressed, which I ran into while trying to do the arge/mdio attachment: 4) the device attach method may require access to the other device to complete the attachment, but that other might not be attached yet. Circular dependencies nonwithstanding, it would be highly desirable for a device driver developer to be able to simply declare all prerequisites for attachment, and have newbus call attach only after everything is there. Right now, the drivers attach method is called by the parent bus as soon as enumeration is completed. The device should go ahead and attach. When multiple devices need to communicate with each other, they need to coordinate things. newbus is a weak coordination mechanism. Stronger coordination mechanisms would be FDT or ACPI which can tie known devices to a device_t rather than to just a name. The device_t will be around even if that device is attached and detached. A notification mechanism (similar to the devfs notification but with an exposed KPI) might be an alternative, as mentioned in this thread. This would also work. However, many of proposed uses for this seem more and more to me to need a non-newbus mechanism to cope with. You'll absolutely require the notification method since devices can detach at any time. Circular dependencies are way too easy to create. In the Atmel work I'm doing and have done, there's devices that provide services to other devices (mostly pin muxing and GPIO). I don't try to get the GPIO device to attach first, but rather have routines that can be called to accomplish these things. During the early boot, I have to use the GPIO device to turn on pins so that I can even talk to things like the MII bus of the internal NIC. While the GPIO devices have device_t's to allocate resources and to create dev_t nodes, I don't marshal everything through newbus. When I want to map a pin as an interrupt source for the PHY chip, that call is made directly. When I need to shut off a device's pin and instead drive it via the GPIO logic, that's just a call. etc. Warner___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interfacing devices with multiple parents within newbus
On Jul 6, 2012, at 1:09 PM, Ian Lepore wrote: Just blue-sky dreaming here on the fly... what we really have is a resource-management problem. A device comes along that needs a GPIO resource, how does it find and use that resource? I rather like that idea. The connection between devices is more like meta-data needed to obtain the resources/services that other devices provide. You really want to talk in those terms, rather than in newbus attachments. The platform told me that pin AT91_PIOA_12 is my interrupt line. I'd like to wire up an ISR to that please. The platform told me that pin AT91_PIOC_33 is the data pin for my two wire bus. An error happened and to reset it I need to tell the pin muxing service to take it off line. then I need to tell the GPIO service I have to force it high, let it flow, and force it low. The platform told me that this NIC is connected to PHY 2 on miibus 3. I'm the NIC driver and want to connect. I'm the USB subsystem. I'd like to know if one or two usb ports are connected to the HUB. The hardware can't tell me, so the platform code has to give me hints. If I allocate the pins for each of those two ports I'll know. In some configurations, I can get both sets. In others, I can only get one set. All of those problems could be solved with newbus kobj connections. Or they could be solved by the platform and/or drivers registering resources and services and the other drivers in the system using it. Multipass would help a lot with that, since you could probe/attach all the service providers first, then everybody else could talk the higher level interfaces. Warner P.S. multipass could solve the dependency problem, but in kinda a poor way... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interfacing devices with multiple parents within newbus
On Fri, 2012-07-06 at 16:45 -0400, Arnaud Lacombe wrote: Hi, On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote: Hi, On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe lacom...@gmail.com wrote: That's neither correct nor robust in a couple of way: 1) you have no guarantee a device unit will always give you the same resource. this raises the following question: how can a device, today, figure out which parent in a given devclass would give it access to resources it needs. Say, you have gpiobus0 provided by a superio and gpiobus1 provided by the chipset and a LED on the chipset's GPIO. Now, say gpiobus0 attachment is conditional to some BIOS setting. How can you tell gpioled(4) to attach on the chipset provided GPIO without hardcoding unit number either way ? AFAIK, you can not. Even hints provided layout description is defeated. Each device in a given devclass need to have a set of unique attribute to allow a child to distinguish it from other potential parent in the same devclass... - Arnaud Talking about a child being unable to choose the correct parent seems to indicate that this whole problem is turned upside-down somehow; children don't choose their parents. actually, I think I was wrong, I thought device were attached to a devclass, but they are truly attached to a given device. My mistake. Just blue-sky dreaming here on the fly... what we really have is a resource-management problem. A device comes along that needs a GPIO resource, how does it find and use that resource? Well, we have a resource manager, could that help somehow? Could a driver that provides access to GPIO somehow register its availability so that another driver can find and access it? The resource may be a callable interface, it doesn't really matter, I'm just wondering if the current rman stuff could be leveraged to help make the connection between unrelated devices. I think that implies that there would have to be something near the root of the hiearchy willing to be the owner/manager of dynamic resources. AFAIR, rman is mostly there to manage memory vs. i/o mapped resources. The more I think about it, the more FTD is the answer. The open question now being how to map a flexible device structure (FTD) to a less flexible structure (Newbus) :/ - Arnaud Memory- and IO-mapped regions and IRQs are the only current uses of rman (that I know of), but it was designed to be fairly agnostic about the resources it manages. It just works with ranges of values (that it really doesn't know how to interpret at all), leaving lots of room to define new types of things it can manage. The downside is that it's designed to be used hierarchically in the context of newbus, specifically to help parents manage the resources that they are able to provide to their children. Trying to use it in a way that allows devices which are hierarchically unrelated to allocate resources from each other may amount to a square-peg/round-hole situation. But the alternative is writing a new facility to allow registration and allocation of resources using some sort symbolic method of representing the resources such that the new manager doesn't have to know much about what it's managing. I think it would be better to find a way to reuse what we've already got if that's possible. I think we have two semi-related aspects to this problem... How do we symbolically represent the resources that drivers can provide to each other? (FDT may be the answer; I don't know much about it.) How do devices use that symbolic representation to locate the provider of the resource, and how is the sharing of those resources managed? -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
HEADSUP: Call for FreeBSD Status Reports - 2Q/2012
Dear all, I would like to remind you that the next round of status reports covering the second quarter of 2012 are due on July 15th, 2012. As this initiative is very popular among our users, I would like to ask you to submit your entry as soon as possible, so that we can compile the report in a timely fashion. Do not hesitate and write us a few lines; a short description about what you are working on, what your plans and goals are, or any other information that you may consider interesting is always welcome. This way we can inform our community about your great work! Check out the reports from the past to get some inspiration of how your submission might look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the previous reports are welcome too. Note that the submissions are accepted from anyone involved within the FreeBSD community, you do not have to be a FreeBSD committer. Anything related to FreeBSD can be covered. Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to mont...@freebsd.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! Thanks. -- Kind regards Daniel Gerzo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Occassional permission denied in the middle of a large transfer over NFS
Vincent Hoffman wrote: On 01/07/2012 12:18, Rick Macklem wrote: Vincent Hoffman wrote: On 01/07/2012 01:53, Rick Macklem wrote: To modify mountd to use the kernel changes is more work than I have time for, in part because mountd.c is a very ugly old piece of C code, imho. I do have a patch that suspends/resumes execution of the nfsd threads (new, experimental for FreeBSD8.n only) when mountd reloads /etc/exports. This approach has certain disadvantages vs Andrey's transactional load/commit model, but it is simple and might be sufficient for your problem. If you want to try this patch, it is at: http://people.freebsd.org/~rmacklem/atomic-export.patch (The patch affects both the kernel and mountd.c.) Happy to try it, to be certain I have understood, this is for the newnfs server (experimental in 8.x default for 8 9+) Yes, that is correct. For the old (default on 8.x) it will have no effect. I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm when i get a minute. Also, to enable it, you must add a -S flag to mountd_flags, after you've replaced the mountd executable. The patch is pretty straightforward, but has not seen much testing. Hopefully, it might be useful for you, rick Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. Just to confirm, you patched both the kernel and mountd and replaced both on the server? Also, I'm not sure how ZFS handles it's exports. I can't remember if you've tried an exported UFS volume. It might be something ZFS specific? rick [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt x nopatch.txt + atomicpatch.txt +--+ | * | | * | | x* | | xx* x | | +x** xx | | xxx x | | xxx +x+ + | | +*xx +x+ x + | | +*xx + + x | | *+*xx+ +++x * x x | | x**++*x+***x+ x*+ x ++*+ + x+ +x + + +| |||___M_M_A__A___|__| | +--+ N Min Max Median Avg Stddev x 101 1.25 106.8 14.08 21.892178 22.196005 + 101 1.21 186.93 18.46 27.995842 30.523218 No difference proven at 95.0% confidence (excuse wrapped ascii art) I think I'll have a look at the nfse patch set and see how that performs. Thanks for all your work on NFS on FreeBSD. Vince Also, you could easily hack mount.c so that it doesn't send a SIGHUP to mountd (which causes the exports to be reloaded) every time a local fs is mounted. True and I may have to do that for the production NAS for the time being. Thanks for looking at this. Vince rick thanks, Vince ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic after starting X with r238120
Following up to myself, with some things I should have mentioned before: On 07/05/12 19:59, Steve Wills wrote: On 07/05/12 03:00, Alan Cox wrote: On Wed, Jul 4, 2012 at 4:57 PM, Steve Wills swi...@freebsd.org wrote: Setting kern.ipc.shm_use_phys back to 0 (the default) fixed it. I had set it to 1 for some reason that I can't recall. That shouldn't cause a crash in pmap_enter(). What is line 3587 of pmap.c in your sources? 3587 if ((newpte PG_RW) == 0) You mentioned DRM. Are you using the new Intel graphics driver? No, I'm using ATI Radeon. For what it's worth, I discovered that twm and xterm don't trigger the issue, but konsole and other kde things do, which is what led me to discover that setting kern.ipc.shm_use_phys back to default fixed it. This wasn't the case before, I think the last time I updated was about a month ago, May 6. Also, I have these other shared memory related settings in sysctl.conf: kern.ipc.shmmax=67108864 kern.ipc.shmall=32768 kern.ipc.shm_allow_removed=1 I'm wondering if this is an indication that I have/had some bad settings and they finally bit me, or if this is an indication of a bug. Thanks, Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interfacing devices with multiple parents within newbus
Hi,
On Sat, Jul 7, 2012 at 2:47 PM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
On Fri, 2012-07-06 at 16:45 -0400, Arnaud Lacombe wrote:
Hi,
On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote:
Hi,
On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe lacom...@gmail.com
wrote:
That's neither correct nor robust in a couple of way:
1) you have no guarantee a device unit will always give you the same
resource.
this raises the following question: how can a device, today, figure
out which parent in a given devclass would give it access to resources
it needs.
Say, you have gpiobus0 provided by a superio and gpiobus1 provided by
the chipset and a LED on the chipset's GPIO. Now, say gpiobus0
attachment is conditional to some BIOS setting. How can you tell
gpioled(4) to attach on the chipset provided GPIO without hardcoding
unit number either way ?
AFAIK, you can not.
Even hints provided layout description is defeated. Each device in a
given devclass need to have a set of unique attribute to allow a child
to distinguish it from other potential parent in the same devclass...
- Arnaud
Talking about a child being unable to choose the correct parent seems to
indicate that this whole problem is turned upside-down somehow; children
don't choose their parents.
actually, I think I was wrong, I thought device were attached to a
devclass, but they are truly attached to a given device. My mistake.
Just blue-sky dreaming here on the fly... what we really have is a
resource-management problem. A device comes along that needs a GPIO
resource, how does it find and use that resource?
Well, we have a resource manager, could that help somehow? Could a
driver that provides access to GPIO somehow register its availability so
that another driver can find and access it? The resource may be a
callable interface, it doesn't really matter, I'm just wondering if the
current rman stuff could be leveraged to help make the connection
between unrelated devices. I think that implies that there would have
to be something near the root of the hiearchy willing to be the
owner/manager of dynamic resources.
AFAIR, rman is mostly there to manage memory vs. i/o mapped resources.
The more I think about it, the more FTD is the answer. The open
question now being how to map a flexible device structure (FTD) to a
less flexible structure (Newbus) :/
- Arnaud
Memory- and IO-mapped regions and IRQs are the only current uses of rman
(that I know of), but it was designed to be fairly agnostic about the
resources it manages. It just works with ranges of values (that it
really doesn't know how to interpret at all), leaving lots of room to
define new types of things it can manage.
The downside is that it's designed to be used hierarchically in the
context of newbus, specifically to help parents manage the resources
that they are able to provide to their children. Trying to use it in a
way that allows devices which are hierarchically unrelated to allocate
resources from each other may amount to a square-peg/round-hole
situation. But the alternative is writing a new facility to allow
registration and allocation of resources using some sort symbolic method
of representing the resources such that the new manager doesn't have to
know much about what it's managing. I think it would be better to find
a way to reuse what we've already got if that's possible.
I think we have two semi-related aspects to this problem...
How do we symbolically represent the resources that drivers can provide
to each other? (FDT may be the answer; I don't know much about it.)
How do devices use that symbolic representation to locate the provider
of the resource, and how is the sharing of those resources managed?
I'd say FDT answer both question, take the DTS for Freescale i.MX53
Smart Mobile Reference Design Board[0],
We first have SoC generic definition in `imx53.dtsi':
soc {
compatible = simple-bus;
aips@5000 { /* AIPS1 */
compatible = fsl,aips-bus, simple-bus;
spba@5000 {
compatible = fsl,spba-bus, simple-bus;
esdhc@50004000 { /* ESDHC1 */
compatible = fsl,imx53-esdhc;
reg = 0x50004000 0x4000;
interrupts = 1;
status = disabled;
};
[...]
gpio2: gpio@53f8c000 { /* GPIO3 */
compatible = fsl,imx53-gpio, fsl,imx31-gpio;
reg = 0x53f8c000 0x4000;
};
gpio3: gpio@53f9 { /* GPIO4 */
compatible = fsl,imx53-gpio, fsl,imx31-gpio;
reg = 0x53f9 0x4000;
};
[...]
}
then board specific definition overriding its parent's in `imx53-smd.dts':
soc {
aips@5000 { /* AIPS1 */
spba@5000 {
esdhc@50004000 { /* ESDHC1 */
cd-gpios = gpio2 13 0; /* GPIO3_13 */
wp-gpios = gpio3 11 0; /* GPIO4_11 */
status = okay;
Re: Interfacing devices with multiple parents within newbus
On Jul 7, 2012, at 9:45 PM, Arnaud Lacombe wrote:
Hi,
On Sat, Jul 7, 2012 at 2:47 PM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
On Fri, 2012-07-06 at 16:45 -0400, Arnaud Lacombe wrote:
Hi,
On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
On Fri, 2012-07-06 at 14:46 -0400, Arnaud Lacombe wrote:
Hi,
On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe lacom...@gmail.com
wrote:
That's neither correct nor robust in a couple of way:
1) you have no guarantee a device unit will always give you the same
resource.
this raises the following question: how can a device, today, figure
out which parent in a given devclass would give it access to resources
it needs.
Say, you have gpiobus0 provided by a superio and gpiobus1 provided by
the chipset and a LED on the chipset's GPIO. Now, say gpiobus0
attachment is conditional to some BIOS setting. How can you tell
gpioled(4) to attach on the chipset provided GPIO without hardcoding
unit number either way ?
AFAIK, you can not.
Even hints provided layout description is defeated. Each device in a
given devclass need to have a set of unique attribute to allow a child
to distinguish it from other potential parent in the same devclass...
- Arnaud
Talking about a child being unable to choose the correct parent seems to
indicate that this whole problem is turned upside-down somehow; children
don't choose their parents.
actually, I think I was wrong, I thought device were attached to a
devclass, but they are truly attached to a given device. My mistake.
Just blue-sky dreaming here on the fly... what we really have is a
resource-management problem. A device comes along that needs a GPIO
resource, how does it find and use that resource?
Well, we have a resource manager, could that help somehow? Could a
driver that provides access to GPIO somehow register its availability so
that another driver can find and access it? The resource may be a
callable interface, it doesn't really matter, I'm just wondering if the
current rman stuff could be leveraged to help make the connection
between unrelated devices. I think that implies that there would have
to be something near the root of the hiearchy willing to be the
owner/manager of dynamic resources.
AFAIR, rman is mostly there to manage memory vs. i/o mapped resources.
The more I think about it, the more FTD is the answer. The open
question now being how to map a flexible device structure (FTD) to a
less flexible structure (Newbus) :/
- Arnaud
Memory- and IO-mapped regions and IRQs are the only current uses of rman
(that I know of), but it was designed to be fairly agnostic about the
resources it manages. It just works with ranges of values (that it
really doesn't know how to interpret at all), leaving lots of room to
define new types of things it can manage.
The downside is that it's designed to be used hierarchically in the
context of newbus, specifically to help parents manage the resources
that they are able to provide to their children. Trying to use it in a
way that allows devices which are hierarchically unrelated to allocate
resources from each other may amount to a square-peg/round-hole
situation. But the alternative is writing a new facility to allow
registration and allocation of resources using some sort symbolic method
of representing the resources such that the new manager doesn't have to
know much about what it's managing. I think it would be better to find
a way to reuse what we've already got if that's possible.
I think we have two semi-related aspects to this problem...
How do we symbolically represent the resources that drivers can provide
to each other? (FDT may be the answer; I don't know much about it.)
How do devices use that symbolic representation to locate the provider
of the resource, and how is the sharing of those resources managed?
I'd say FDT answer both question, take the DTS for Freescale i.MX53
Smart Mobile Reference Design Board[0],
We first have SoC generic definition in `imx53.dtsi':
soc {
compatible = simple-bus;
aips@5000 { /* AIPS1 */
compatible = fsl,aips-bus, simple-bus;
spba@5000 {
compatible = fsl,spba-bus, simple-bus;
esdhc@50004000 { /* ESDHC1 */
compatible = fsl,imx53-esdhc;
reg = 0x50004000 0x4000;
interrupts = 1;
status = disabled;
};
[...]
gpio2: gpio@53f8c000 { /* GPIO3 */
compatible = fsl,imx53-gpio, fsl,imx31-gpio;
reg = 0x53f8c000 0x4000;
};
gpio3: gpio@53f9 { /* GPIO4 */
compatible = fsl,imx53-gpio, fsl,imx31-gpio;
reg = 0x53f9 0x4000;
};
[...]
}
then board specific definition overriding its parent's in `imx53-smd.dts':
soc {
aips@5000 { /* AIPS1 */
spba@5000 {
esdhc@50004000 { /* ESDHC1 */
cd-gpios = gpio2 13 0; /* GPIO3_13 */
wp-gpios = gpio3 11 0; /*
