Re: Mis-use of BUS_PASS_ORDER_MIDDLE
Can we only load the bus driver that is required by timer or pic? Then you don't need worry about acpi_pci or pcib. John Baldwin于2016年4月20日周三 上午3:26写道: > On Tuesday, April 19, 2016 03:42:40 PM Howard Su wrote: > > On Tue, Apr 19, 2016 at 2:53 AM John Baldwin wrote: > > > > > On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > > > > I noticed several places there are code like this, especially in > some arm > > > > low level drivers. > > > > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, > aw_ccu_devclass, > > > > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); > > > > > > > > I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are > another > > > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter > > > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. > > > > > > No, this is actually correct. The _ORDERED variants actually accept a > > > SI_ORDER_* value to determine how drivers contained in a single .ko > file > > > are registered (in particular if you have several drivers in a .ko file > > > you typically want the "top-most" driver to attach last so that all the > > > other drivers are ready once the actual device is attached). > > > > > Why not use _ORDERED here to achieve same thing? _ORDERED(, > > SI_ORDER_LAST, BUS_PASS_BUS)? > > > > I am thinking to add some macro like BUS_DRIVER_MODULE, > INT_DRIVER_MODULE, > > TIMER_DRIVER_MODULE, so that the driver can declare itself in such way. > If > > we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner. > > > > I am plan to do is: in autoconf phase, first load timer, int and some > bus, > > etc low level drivers first, then set cold=0, then load other driver to > > work around the problem that driver needs special handling on cold which > is > > not necessary. of course, this may depends on your change of ap_startup. > > thoughts? > > I would like to get to that, but the path on x86 is a bit messier. Ideally > the order looks something like this: > > - enumerate the tree (BUS_PASS_BUS) > - reserve fixed-resources (things like acpi_sysres) (BUS_PASS_RESOURCE) > - reserve existing resources that could be moved or disabled if > their is a conflict (think PCI BARs programmed by firmware and/or > doing an initial pass of BARs) > - interrupt controllers (may need resources) (BUS_PASS_INTR) > - timers (probably need resources, need interrupts) (BUS_PASS_TIMER) > > Then all the rest. > > However, it ends up a bit messier on x86 at least. I have a WIP to at > least start doing BUS_PASS_BUS for x86, but I found that I really need > some ACPI bits to probe before the ACPI 'pcib' driver, so I've ended > up with a kind of 'BUS_PASS_PREBUS' for acpi0, and even then it turns out > that in some cases we need more granularity than just 'BUS_PASS_xxx'. > > SI_ORDER_* with ORDERED will not help as all the drivers are registered > at SI_SUB_DRIVERS during boot (which is when the SI_ORDER_* applies), > but the device tree is enumerated and attached at SI_SUB_CONFIGURE. > > And yes, the AP startup stuff is a precursor for this. > > -- > John Baldwin > -- -Howard ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Mis-use of BUS_PASS_ORDER_MIDDLE
On Tuesday, April 19, 2016 03:42:40 PM Howard Su wrote: > On Tue, Apr 19, 2016 at 2:53 AM John Baldwinwrote: > > > On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > > > I noticed several places there are code like this, especially in some arm > > > low level drivers. > > > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass, > > > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); > > > > > > I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are another > > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter > > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. > > > > No, this is actually correct. The _ORDERED variants actually accept a > > SI_ORDER_* value to determine how drivers contained in a single .ko file > > are registered (in particular if you have several drivers in a .ko file > > you typically want the "top-most" driver to attach last so that all the > > other drivers are ready once the actual device is attached). > > > Why not use _ORDERED here to achieve same thing? _ORDERED(, > SI_ORDER_LAST, BUS_PASS_BUS)? > > I am thinking to add some macro like BUS_DRIVER_MODULE, INT_DRIVER_MODULE, > TIMER_DRIVER_MODULE, so that the driver can declare itself in such way. If > we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner. > > I am plan to do is: in autoconf phase, first load timer, int and some bus, > etc low level drivers first, then set cold=0, then load other driver to > work around the problem that driver needs special handling on cold which is > not necessary. of course, this may depends on your change of ap_startup. > thoughts? I would like to get to that, but the path on x86 is a bit messier. Ideally the order looks something like this: - enumerate the tree (BUS_PASS_BUS) - reserve fixed-resources (things like acpi_sysres) (BUS_PASS_RESOURCE) - reserve existing resources that could be moved or disabled if their is a conflict (think PCI BARs programmed by firmware and/or doing an initial pass of BARs) - interrupt controllers (may need resources) (BUS_PASS_INTR) - timers (probably need resources, need interrupts) (BUS_PASS_TIMER) Then all the rest. However, it ends up a bit messier on x86 at least. I have a WIP to at least start doing BUS_PASS_BUS for x86, but I found that I really need some ACPI bits to probe before the ACPI 'pcib' driver, so I've ended up with a kind of 'BUS_PASS_PREBUS' for acpi0, and even then it turns out that in some cases we need more granularity than just 'BUS_PASS_xxx'. SI_ORDER_* with ORDERED will not help as all the drivers are registered at SI_SUB_DRIVERS during boot (which is when the SI_ORDER_* applies), but the device tree is enumerated and attached at SI_SUB_CONFIGURE. And yes, the AP startup stuff is a precursor for this. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Mis-use of BUS_PASS_ORDER_MIDDLE
On Tue, Apr 19, 2016 at 2:53 AM John Baldwinwrote: > On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > > I noticed several places there are code like this, especially in some arm > > low level drivers. > > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass, > > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); > > > > I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are another > > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter > > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. > > No, this is actually correct. The _ORDERED variants actually accept a > SI_ORDER_* value to determine how drivers contained in a single .ko file > are registered (in particular if you have several drivers in a .ko file > you typically want the "top-most" driver to attach last so that all the > other drivers are ready once the actual device is attached). > Why not use _ORDERED here to achieve same thing? _ORDERED(, SI_ORDER_LAST, BUS_PASS_BUS)? I am thinking to add some macro like BUS_DRIVER_MODULE, INT_DRIVER_MODULE, TIMER_DRIVER_MODULE, so that the driver can declare itself in such way. If we can avoid usage of BUS_PASS_ORDER_XXX, the macro is much cleaner. I am plan to do is: in autoconf phase, first load timer, int and some bus, etc low level drivers first, then set cold=0, then load other driver to work around the problem that driver needs special handling on cold which is not necessary. of course, this may depends on your change of ap_startup. thoughts? > -- > John Baldwin > -- -Howard ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Mis-use of BUS_PASS_ORDER_MIDDLE
On Monday, April 18, 2016 11:10:12 PM Howard Su wrote: > I noticed several places there are code like this, especially in some arm > low level drivers. > EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass, > 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); > > I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are another > macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter > "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. No, this is actually correct. The _ORDERED variants actually accept a SI_ORDER_* value to determine how drivers contained in a single .ko file are registered (in particular if you have several drivers in a .ko file you typically want the "top-most" driver to attach last so that all the other drivers are ready once the actual device is attached). -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Mis-use of BUS_PASS_ORDER_MIDDLE
I noticed several places there are code like this, especially in some arm low level drivers. EARLY_DRIVER_MODULE(aw_ccu, simplebus, aw_ccu_driver, aw_ccu_devclass, 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_MIDDLE); I feel the usage of BUS_PASS_ORDER_MIDDLE is misused. There are another macro EARLY_DRIVER_MODULE_ORDERED, which take an additional parameter "order". I believe BUS_PASS_ORDER_xxx is used for that parameter. -- -Howard ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"