tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: acpivga(4) v. MI display controls
On Fri, Oct 15, 2010 at 07:53:53PM -0500, David Young wrote:
> > > OK, what this code is doing is essentially attach a device to the acpi
> > tree that really refers to a PCI device. Can we please get this to
> > attach as child of vga0 by checking for a device matching the PCI
> > address of vga0, that also provides _DOD and _DOS. This would prevent
> > accessing vga0 on resume before it has been reset.
>
> Joerg calls attention in that last sentence to the possibility of
> defects in suspend/resume that arise when a device is represented twice
> in the device tree. Sounds familiar. :-)
The above scheme is easily achieved if we start dropping #ifdefs to the
device tree. (Hopefully everyone can agree that this is out of the
question.) As I wrote, if we start to implement hacks specific to one
acpi(4) driver, we end up with a big mess. It is much better to have the
whole acpi(4) uniformly at 'acpinodebus' even with the risks involved, so
that once we have a solution, everything can be transformed in a single
sweep.
You do realize that our suspend/resume paths are full of defects due reasons
I outlined? For instance, because drivers do not inform the firmware upon
suspend(), we have several cases where devices resume in a power off state
(cf. PR #37891). Complaining about a single driver prevents one from seeing
the forest.
> ISTM that more than one developer can, and has, described in a broad
> outline how it should be done. For example, I can outline how
> device_register() can be used to put ACPI information into MI device
> properties for device-attachment hooks to read back out. I'm happy to
> give more detailed suggestions, too.
I think everyone groks this. Opening up an editor and doing the work is
another thing. I emphasize that this is not entirely about autoconfiguration.
> I'm not sure I understand what you mean by the "'natural' device tree".
> I think you may have drawn a line between "virtual" and "real" device
> hierarchies and assigned ACPI to a different category than I would.
> Again, I'm not sure I've taken your meaning right.
By "natural" I refer to the discussion on this list about (semi-random)
thoughts on device tree structure (and the several inconsistencies in it).
See appendix.
> It's just occurred to me that it may help to form a group to discuss
> how BIOS information should be encoded and conveyed from MD code to MI
> drivers in NetBSD. By setting standards, we may help developers on
> every port leverage others' knowledge and work. What do you think?
Sounds good, albeit talk tends to be cheap.
I take the above quote to clear some misunderstandings:
(b) This is not about passing something from MD to MI -- it goes to
the other direction also.
(a) This is not only about passing information, but applies to
controls (callbacks, etc.) also.
(b) This is not only about autoconfiguration, but (a) and (b) are
present dynamically at runtime. When a driver writes to a
register, it may need to inform the firmware. When the firmware
writes to a register, it may need to inform the driver.
- Jukka.
Appendix: the "natural" device tree on a ThinkPad.
\ [06] [ ]
CPU0 [12] [ ]
CPU1 [12] [ ]
_SB [06] [ ]
LNKA [06] [ ]
LNKB [06] [ ]
LNKC [06] [ ]
LNKD [06] [ ]
LNKE [06] [ ]
LNKF [06] [ ]
LNKG [06] [ ]
LNKH [06] [ ]
MEM [06] [ ]
LID [06] [ W] <acpilid0>
SLPB [06] [ W] <acpibut0>
PCI0 [06] [ ] (PCI) @ 0x00:0x00:0x00:0x00 [R] [B] -> 0x00 <pchb0>
LPC [06] [ ] (PCI) @ 0x00:0x00:0x1F:0x00 <ichlpcib0>
SIO [06] [ ]
PIC [06] [ ]
TIMR [06] [ ] <attimer1>
HPET [06] [ ] <hpet0>
DMAC [06] [ ]
SPKR [06] [ ] <pcppi1>
FPU [06] [ ] <npx1>
RTC [06] [ ]
KBD [06] [ ] <pckbc1>
MOU [06] [ ] <pckbc2>
DURT [06] [ W]
DLPT [06] [ ]
DECP [06] [ ]
FIR [06] [ ]
TPM [06] [ ]
EC [06] [ ] <acpiec0>
PUBS [11] [ ]
BAT0 [06] [ ] <acpibat0>
BAT1 [06] [ ]
BAT2 [06] [ ]
AC [06] [ ] <acpiacad0>
HKEY [06] [ ] <thinkpad0>
VID [06] [ ] (PCI) @ 0x00:0x00:0x02:0x00 <vga1>
LCD0 [06] [ ]
CRT0 [06] [ ]
AGP [06] [ ] (PCI) @ 0x00:0x00:0x01:0x00
VID [06] [ ]
LCD0 [06] [ ]
CRT0 [06] [ ]
EXP0 [06] [ W] (PCI) @ 0x00:0x00:0x1C:0x00 [B] -> 0x01 <ppb0>
EXP1 [06] [ W] (PCI) @ 0x00:0x00:0x1C:0x01 [B] -> 0x02 <ppb1>
EXP2 [06] [ W] (PCI) @ 0x00:0x00:0x1C:0x02 [B] -> 0x03 <ppb2>
EXUP [06] [ ] (PCI) @ 0x00:0x03:0x00:0x00
EXP3 [06] [ W] (PCI) @ 0x00:0x00:0x1C:0x03 [B] -> 0x04 <ppb3>
EXPD [06] [ ] (PCI) @ 0x00:0x04:0x00:0x00
PCI1 [06] [ W] (PCI) @ 0x00:0x00:0x1E:0x00 [B] -> 0x05 <ppb4>
CDBS [06] [ ] (PCI) @ 0x00:0x05:0x00:0x00 <cbb0>
IDE0 [06] [ ] (PCI) @ 0x00:0x00:0x1F:0x01 <piixide0>
PRIM [06] [ ]
MSTR [06] [ ]
SATA [06] [ ] (PCI) @ 0x00:0x00:0x1F:0x02 <ahcisata0>
PRT0 [06] [ ]
SMBU [06] [ ] (PCI) @ 0x00:0x00:0x1F:0x03 <ichsmb0>
USB0 [06] [PW] (PCI) @ 0x00:0x00:0x1D:0x00 <uhci0>
USB1 [06] [ W] (PCI) @ 0x00:0x00:0x1D:0x01 <uhci1>
URTH [06] [ ]
UPEX [06] [ ]
USB2 [06] [PW] (PCI) @ 0x00:0x00:0x1D:0x02 <uhci2>
URTH [06] [ ]
UPDK [06] [ ]
USB3 [06] [ ] (PCI) @ 0x00:0x00:0x1D:0x03 <uhci3>
USB7 [06] [PW] (PCI) @ 0x00:0x00:0x1D:0x07 <ehci0>
URTH [06] [ ]
UPDK [06] [ ]
UPEX [06] [ ]
HDEF [06] [ W] (PCI) @ 0x00:0x00:0x1B:0x00 <hdaudio0>
SWAP [06] [ ]
GDCK [06] [ ]
_TZ [13] [ ]
THM0 [13] [ ] <acpitz0>
THM1 [13] [ ] <acpitz1>
Home |
Main Index |
Thread Index |
Old Index