Re: bus device driver
John Baldwin schrieb: On Monday 13 July 2009 10:05:15 am Norbert Koch wrote: Hello. I just started to write a device driver for a multi-function pci card. This card replaces a number of independant isa hardware devices. This pci card contains memory, i/o and interrupt sources. I want my device driver to serve as a bus driver between the pci driver and the specific device drivers. Do I need more than the following (see below)? Do I have to do any bookkeeping for allocated resources? How do the child devices receive resources? Do they suballocate regions from BARs in the PCI device or is your device a subtractive bridge that will forward requests for ISA ranges and your devices all use ISA ranges? I am not quite sure that I understand what you mean. What is the difference? My old device drivers were isa based. We had all our resources in the 15-16M isa hole. So I want to change them to just allocate resources from the pci bus through the bus device driver. I thought it would be sufficient to just forward *_alloc_resource calls directly to the pci driver. Clearly, my drivers will have to know that they are just forwarded through to pci and have to know what sub-resources to allocate. -- Dipl.-Ing. Norbert Koch Entwicklung Prozessregler * *demig Prozessautomatisierung GmbH * * * * Anschrift: Haardtstrasse 40 * * D-57076 Siegen * * Registergericht: Siegen HRB 2819 * * Geschaeftsfuehrer: Joachim Herbst, * *Winfried Held * * Telefon: +49 271 772020 * * Telefax: +49 271 74704 * * E-Mail:i...@demig.de * * http://www.demig.de * * ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bus device driver
On Tuesday 14 July 2009 3:08:40 am Norbert Koch wrote: John Baldwin schrieb: On Monday 13 July 2009 10:05:15 am Norbert Koch wrote: Hello. I just started to write a device driver for a multi-function pci card. This card replaces a number of independant isa hardware devices. This pci card contains memory, i/o and interrupt sources. I want my device driver to serve as a bus driver between the pci driver and the specific device drivers. Do I need more than the following (see below)? Do I have to do any bookkeeping for allocated resources? How do the child devices receive resources? Do they suballocate regions from BARs in the PCI device or is your device a subtractive bridge that will forward requests for ISA ranges and your devices all use ISA ranges? I am not quite sure that I understand what you mean. What is the difference? My old device drivers were isa based. We had all our resources in the 15-16M isa hole. So I want to change them to just allocate resources from the pci bus through the bus device driver. I thought it would be sufficient to just forward *_alloc_resource calls directly to the pci driver. Clearly, my drivers will have to know that they are just forwarded through to pci and have to know what sub-resources to allocate. From a hardware perspective, how do your devices know which addresses to decode? Do they consume subranges of BARs or are they assigned fixed addresses somehow? Do they have programmable decoders of some sort themselves? If you wish to have the PCI bus assign you resources then that implies that your PCI device has a BAR and that you want to request resources for that BAR and then hand out subranges of that to your children. If that is the case, then you will need to allocate the resources for the BAR for the PCI device from the PCI bus. Then your bus driver for the PCI device will need to suballoc from that BAR to your children devices. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bus device driver
From a hardware perspective, how do your devices know which addresses to decode? Do they consume subranges of BARs or are they assigned fixed addresses somehow? Do they have programmable decoders of some sort themselves? If you wish to have the PCI bus assign you resources then that implies that your PCI device has a BAR and that you want to request resources for that BAR and then hand out subranges of that to your children. If that is the case, then you will need to allocate the resources for the BAR for the PCI device from the PCI bus. Then your bus driver for the PCI device will need to suballoc from that BAR to your children devices. My device decodes one ram address range (16MB) and gives me one interrupt line. As my sub-devices operate on partial address areas my idea was to let them all call bus_alloc_resource() with the same rid parameter (= BAR selector) and different offsets. So the bookkeeping should be done by the pci driver, right? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: mmap/munmap with zero length
John Baldwin wrote: On Monday 13 July 2009 3:33:51 pm Tijl Coosemans wrote: On Monday 13 July 2009 20:28:08 John Baldwin wrote: On Sunday 05 July 2009 3:32:25 am Alexander Best wrote: so mmap differs from the POSIX recommendation right. the malloc.conf option seems more like a workaround/hack. imo it's confusing to have mmap und munmap deal differently with len=0. being able to succesfully alocate memory which cannot be removed doesn't seem logical to me. This should fix it: --- //depot/user/jhb/acpipci/vm/vm_mmap.c +++ /home/jhb/work/p4/acpipci/vm/vm_mmap.c @@ -229,7 +229,7 @@ fp = NULL; /* make sure mapping fits into numeric range etc */ - if ((ssize_t) uap-len 0 || + if ((ssize_t) uap-len = 0 || ((flags MAP_ANON) uap-fd != -1)) return (EINVAL); Why not uap-len == 0? Sizes of 2GiB and more (32bit) shouldn't cause an error. I don't actually disagree and know of locally modified versions of FreeBSD that remove this check for precisely that reason. I have no objections to uap-len == 0 (without the cast). Alan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bus device driver
On Tuesday 14 July 2009 11:30:50 am Norbert Koch wrote: From a hardware perspective, how do your devices know which addresses to decode? Do they consume subranges of BARs or are they assigned fixed addresses somehow? Do they have programmable decoders of some sort themselves? If you wish to have the PCI bus assign you resources then that implies that your PCI device has a BAR and that you want to request resources for that BAR and then hand out subranges of that to your children. If that is the case, then you will need to allocate the resources for the BAR for the PCI device from the PCI bus. Then your bus driver for the PCI device will need to suballoc from that BAR to your children devices. My device decodes one ram address range (16MB) and gives me one interrupt line. As my sub-devices operate on partial address areas my idea was to let them all call bus_alloc_resource() with the same rid parameter (= BAR selector) and different offsets. So the bookkeeping should be done by the pci driver, right? No. First of all, the PCI bus driver will only allocate resources for direct children. It simply passes requests up the tree for grandchildren (this is how ISA devices behind a PCI-ISA bridge request resources). In this case, you will want to allocate resources for your BAR and your interrupt using bus_alloc_resource() during your attach routine. You can then either share the resources directly with your children by returning your resource values in your own bus_alloc_resource() method (see ppc(4) for an example of this) or subdivide your resource to make new resources (the easiest way to do this is probably to create a rman from your resource and then use rman_reserve_resource() to sub-allocate chunks of that to your children). For the interrupt resource you can just return your own resource pointer directly in your bus_alloc_resource() routine. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: can we afford an extra column in iostat?
On Tue, 14 Jul 2009 07:23:12 +0300, Giorgos Keramidas keram...@freebsd.org wrote: While converting my laptop's main disk to zfs, I noticed iostat output like this (bits copied from here and there): | keram...@kobe:/home/keramida$ iostat -w3 ad0 da0 | tty ad0 da0 cpu | tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id |5 2119 36.29 56 2.00 54.95 7 0.35 3 0 8 0 89 |0 9478 10.90 290 3.09 57.22 12 0.67 42 0 43 0 15 |012595 1.72 213 0.36 21.36 80 1.66 48 0 48 0 4 |050042 4.56 715 3.19 11.44 164 1.83 29 0 50 1 20 | 11529568 7.34 443 3.17 16.97 165 2.74 31 0 53 0 16 [.] | $ ./iostat -w2 | tty ad0 md0 da0 cpu | tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id |7 2570 32.92 62 1.98 6.46 0 0.00 43.44 10 0.41 4 0 9 0 87 |0 36506 0.99 507 0.49 0.00 0 0.00 20.13 155 3.04 34 0 56 1 9 |0 16695 0.83 226 0.18 0.00 0 0.00 26.16 97 2.48 35 0 56 0 9 |0 24158 10.63 428 4.45 0.00 0 0.00 14.44 137 1.93 32 0 51 0 17 | ^C The patch that changes this is quite small: This should be fixed. Ironically, the only people that usually have problems with fixes like this are people that have seen the fields merge and have adjusted some script to understand column widths! -- Brian Somers br...@awfulhak.org Don't _EVER_ lose your sense of humour !br...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: can we afford an extra column in iostat?
On Tue, 14 Jul 2009 14:55:15 -0700, Brian Somers br...@freebsd.org wrote: On Tue, 14 Jul 2009 07:23:12 +0300, Giorgos Keramidas keram...@freebsd.org wrote: While converting my laptop's main disk to zfs, I noticed iostat output like this (bits copied from here and there): | keram...@kobe:/home/keramida$ iostat -w3 ad0 da0 | tty ad0 da0 cpu | tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id |5 2119 36.29 56 2.00 54.95 7 0.35 3 0 8 0 89 |0 9478 10.90 290 3.09 57.22 12 0.67 42 0 43 0 15 |012595 1.72 213 0.36 21.36 80 1.66 48 0 48 0 4 |050042 4.56 715 3.19 11.44 164 1.83 29 0 50 1 20 | 11529568 7.34 443 3.17 16.97 165 2.74 31 0 53 0 16 [.] | $ ./iostat -w2 | tty ad0 md0 da0 cpu | tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id |7 2570 32.92 62 1.98 6.46 0 0.00 43.44 10 0.41 4 0 9 0 87 |0 36506 0.99 507 0.49 0.00 0 0.00 20.13 155 3.04 34 0 56 1 9 |0 16695 0.83 226 0.18 0.00 0 0.00 26.16 97 2.48 35 0 56 0 9 |0 24158 10.63 428 4.45 0.00 0 0.00 14.44 137 1.93 32 0 51 0 17 | ^C The patch that changes this is quite small: This should be fixed. Ironically, the only people that usually have problems with fixes like this are people that have seen the fields merge and have adjusted some script to understand column widths! Yes, that's a bit unfortunate. I'm ok with keeping this in 8.X only for this reason alone, but I would prefer if it was eventually MFCd. I'll ask re@ if they are ok with committing this now in head. Thanks :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
