pchb@acpi
KIYOHARA Takashi
I want pchb@acpi support.
All recent PC has information on PCI in ACPI.
We can attach pchb in acpi like a lot of other acpi devices.
pchb@acpi has been fairly supported in FreeBSD since before.
ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/pc...@acpi-support.diff
dmesg+ia64:
ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/typescript-20100801
Thanks,
--
kiyohara
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Quentin Garnier
> Hi! all,
>
>
> I want pchb@acpi support.
>
> All recent PC has information on PCI in ACPI.
> We can attach pchb in acpi like a lot of other acpi devices.
> pchb@acpi has been fairly supported in FreeBSD since before.
>
> ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/pc...@acpi-support.diff
Do you have anything further in mind? This patch is only dmesg
cosmetics.
--
Quentin Garnier - cu...@cubidou.net - cu...@NetBSD.org
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
KIYOHARA Takashi
From: Quentin Garnier <cu...@cubidou.net>
Date: Sun, 1 Aug 2010 15:21:18 +0000
> On Sun, Aug 01, 2010 at 11:17:54PM +0900, KIYOHARA Takashi wrote:
> > All recent PC has information on PCI in ACPI.
> > We can attach pchb in acpi like a lot of other acpi devices.
> > pchb@acpi has been fairly supported in FreeBSD since before.
> >
> > ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/pc...@acpi-support.diff
>
> Do you have anything further in mind? This patch is only dmesg
> cosmetics.
No, I don't.
My ia64 machine not need it.
However it pass segment information to pci(4) in the future possibly.
David Young
> Hi! Quentin,
>
>
> From: Quentin Garnier <cu...@cubidou.net>
> Date: Sun, 1 Aug 2010 15:21:18 +0000
>
>
> > > We can attach pchb in acpi like a lot of other acpi devices.
> > > pchb@acpi has been fairly supported in FreeBSD since before.
> > >
> > > ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/pc...@acpi-support.diff
> >
> > cosmetics.
>
> My ia64 machine not need it.
> However it pass segment information to pci(4) in the future possibly.
What kind of segment information?
Attached is a preview of information that I supply to instances of
pci(4), ppb(4), and cbb(4) through their device properties. The
information will help them manage PCI address spaces and to program
their address windows correctly, so that I can retire rbus and
PCI_ADDR_FIXUP, whose heuristics are incomplete.
Currently, I derive the information by scanning PCI Configuration Space.
The system BIOS---be it OpenFirmware, ACPI, or something else---may
supply similar information.
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 278-3933
Eduardo Horvath
> What kind of segment information?
>
> Attached is a preview of information that I supply to instances of
> pci(4), ppb(4), and cbb(4) through their device properties. The
> information will help them manage PCI address spaces and to program
> their address windows correctly, so that I can retire rbus and
> PCI_ADDR_FIXUP, whose heuristics are incomplete.
>
> Currently, I derive the information by scanning PCI Configuration Space.
> The system BIOS---be it OpenFirmware, ACPI, or something else---may
> supply similar information.
Take a look at this:
http://playground.sun.com/1275/bindings/pci/pci2_1.pdf
I think it would make everyone's life easier if you could encode the
properties as close to the 1275 bindings as possible. That would the
amount of massaging needed to the properties OpenFirmware already
provides.
Eduardo
David Young
> Attached is a preview of information that I supply to instances of
> pci(4), ppb(4), and cbb(4) through their device properties. The
> information will help them manage PCI address spaces and to program
> their address windows correctly, so that I can retire rbus and
> PCI_ADDR_FIXUP, whose heuristics are incomplete.
>
> Currently, I derive the information by scanning PCI Configuration Space.
> The system BIOS---be it OpenFirmware, ACPI, or something else---may
> supply similar information.
Here is a new snapshot of the PCI information that I'm reading out of
PCI Configuration Space. This time the format is slightly different,
and the property list includes the I/O-space reservations and the legacy
VGA regions.
I've had a look at the document on the IEEE 1275 (sp?) bindings that
Eduardo Horvath mentioned, and there appears to be a very good fit
between the OpenFirmware format and my property-list format.
I'm looking for volunteers to parse ACPI and OpenFirmware information
into this format.
Let me describe the format:
PCI functions including bridges have in their device_properties() a
"pci-resources" key.
Properties for device `pci0':
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>device-driver</key>
<string>pci</string>
<key>device-unit</key>
<integer>0x0</integer>
<key>pci-resources</key>
Under that key is a dictionary with "io" and "memory" keys,
corresponding to PCI I/O and memory-mapped I/O space:
<dict>
<key>io</key>
...
<key>memory</key>
...
Under each of those keys is a dictionary containing one key,
"bios-reservations", and under that key an array of dictionaries:
...
<key>io</key>
<dict>
<key>bios-reservations</key>
<array>
<dict>
...
</dict>
...
Each dictionary in the array describes one I/O or memory range
reserved by this PCI function or, in the case of a bridge, reserved
by this function or one of its subordinate functions. The dictionary
identifies the function corresponding with the range with
"bus"/"device"/"function" keys,
<dict>
<key>bus</key>
<integer>0x0</integer>
<key>device</key>
<integer>0x1</integer>
<key>function</key>
<integer>0x0</integer>
...
it tells the starting address and width of the range,
<key>address</key>
<integer>0xa000</integer>
<key>size</key>
<integer>0x1000</integer>
it tells the type of reservation---i.e., whether the range was reserved
by a bus-bridge window ("window"), a Base Address Register ("bar"), or
the PCI Command & Status Register's VGA-enable bit ("vga-enable"),
<key>type</key>
<string>window</string>
and it tells the PCI Configuration Space registers that encode the
reservation using an array at "regs"---VGA enables, 64-bit BARs and
bus-bridge windows to encode a reservation using two registers; all
other reservations use one register,
<key>regs</key>
<array>
<dict>
<key>mask</key>
<integer>0xffffffff</integer>
<key>offset</key>
<integer>0x1c</integer>
<key>val</key>
<integer>0xa0a0</integer>
</dict>
</array>
</dict>
If the kernel reclaims and re-assigns the I/O or memory space used
by a PCI subtree, it can put all of the BIOS assignments back by
using the "regs" array. Every register is encoded with a Configuration
Space offset, a value, and a mask---the register is restored by
pci_conf_write(..., ofs, pci_conf_read(..., ofs) & ~mask | val & mask),
<dict>
<key>mask</key>
<integer>0xffffffff</integer>
<key>offset</key>
<integer>0x1c</integer>
<key>val</key>
<integer>0xa0a0</integer>
</dict>
</array>
</dict>
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24
Martin Husemann
> Here is a new snapshot of the PCI information that I'm reading out of
> PCI Configuration Space. This time the format is slightly different,
> and the property list includes the I/O-space reservations and the legacy
> VGA regions.
This sounds like strictly structured one-time used data. Using property lists
here seems like an unecessary waste (data and code size) to me.
Martin
David Young
> On Thu, Jul 28, 2011 at 03:13:28PM -0500, David Young wrote:
> > PCI Configuration Space. This time the format is slightly different,
> > and the property list includes the I/O-space reservations and the legacy
> > VGA regions.
>
> here seems like an unecessary waste (data and code size) to me.
*shrug* I thought that the direction that we were going for conveying
information from MD sources to MI code was property lists---e.g., Plug
'n' Play or ACPI info -> PCI/ISA autoconfiguration: property lists.
I am not 100% comfortable with using property lists for this purpose.
As you may know, I have written a property-list helper library (look for
ppath in the mailing lists) simply to make property lists more bearable!
I actually collect the information for the PCI-ranges property list
using a struct that I find much easier to use in C code than a property
list:
typedef enum pci_alloc_regtype {
PCI_ALLOC_REGTYPE_NONE = 0
, PCI_ALLOC_REGTYPE_BAR = 1
, PCI_ALLOC_REGTYPE_WIN = 2
, PCI_ALLOC_REGTYPE_CBWIN = 3
, PCI_ALLOC_REGTYPE_VGA_EN = 4
} pci_alloc_regtype_t;
typedef enum pci_alloc_space {
PCI_ALLOC_SPACE_IO = 0
, PCI_ALLOC_SPACE_MEM = 1
} pci_alloc_space_t;
typedef enum pci_alloc_flags {
PCI_ALLOC_F_PREFETCHABLE = 0x1
} pci_alloc_flags_t;
typedef struct pci_alloc {
TAILQ_ENTRY(pci_alloc) pal_link;
pcitag_t pal_tag;
uint64_t pal_addr;
uint64_t pal_size;
pci_alloc_regtype_t pal_type;
struct pci_alloc_reg {
int r_ofs;
pcireg_t r_val;
pcireg_t r_mask;
} pal_reg[3];
pci_alloc_space_t pal_space;
pci_alloc_flags_t pal_flags;
} pci_alloc_t;
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24
Matthias Drochner
mar...@duskware.de said:
> This sounds like strictly structured one-time used data. Using
> property lists here seems like an unecessary waste (data and code
> size) to me.
Agreed. Property lists should be used where data exchange with
userland is of primary concern, or where data are so variadic
that the proplist overhead appears as the lesser evil.
Besides that, the common pci code should not be bloated with
code for dynamic address space management. We've got attachments
which is a powerful tool to keep driver code modular without #ifdefs.
Since ACPI uses pci buses as entities in its namespace, "pci@acpi"
would be the natural implementation.
best regards
Matthias
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Matthias Drochner
dyo...@pobox.com said:
> typedef enum pci_alloc_regtype {
> PCI_ALLOC_REGTYPE_NONE = 0
> , PCI_ALLOC_REGTYPE_BAR = 1
I'm not sure this is general enough. I've worked with some industrial
x86 systems arecently which had two ISA buses -- one internal
(physically an LPC bus) and one with real ISA slots. Each one behind
a PCI-ISA bridge. Seems that a generic framework should have an
idea about subtractive decoding.
best regards
Matthias
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
--
Manuel Bouyer
> On Fri, Jul 29, 2011 at 09:24:49AM +0200, Martin Husemann wrote:
> > > PCI Configuration Space. This time the format is slightly different,
> > > and the property list includes the I/O-space reservations and the legacy
> > > VGA regions.
> >
> > here seems like an unecessary waste (data and code size) to me.
>
> information from MD sources to MI code was property lists---e.g., Plug
> 'n' Play or ACPI info -> PCI/ISA autoconfiguration: property lists.
device_properties() uses property lists, so I think poplists is right for
your usage too. It looks like it's a property of a bus node and I can't see
why it should be different from a device node. It should probably be
in the device property of the bus node's device_t.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
Matthias Drochner
bou...@antioche.eu.org said:
> device_properties() uses property lists, so I think poplists is right
> for your usage too. It looks like it's a property of a bus node and I
> can't see why it should be different from a device node. It should
> probably be in the device property of the bus node's device_t.
I can't follow this logics. Since almost everything in a device's
softc is a property of the device, we could stop using C structures
completely then...
best regards
Matthias
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
--
Manuel Bouyer
>
> bou...@antioche.eu.org said:
> > device_properties() uses property lists, so I think poplists is right
> > for your usage too. It looks like it's a property of a bus node and I
> > can't see why it should be different from a device node. It should
> > probably be in the device property of the bus node's device_t.
>
> softc is a property of the device, we could stop using C structures
> completely then...
the softc is private to the device (it eventually copies informations
passed from the parent, and the attach informations could be properties
as well). up to now, device_properties() has been used to pass informations
which doesn't comes directly from the parent (as opposed to the attach
structure), and possibly from different place, and may possibly not be
there. If I understood it properly, we still want to have pchb to attach
at pci, but using informations from BIOS or ACPI if available.
It looks like this fits device_properties(), much more than and extention
of the pci attach args.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
--
Matthias Drochner
bou...@antioche.eu.org said:
> up to now, device_properties() has been used to pass informations
> which doesn't comes directly from the parent (as opposed to the attach
> structure)
If we allow to attach pci at acpi, the information would come
directly from the parent. It is not only address space usage
but also interrupt routing and power management.
> It looks like this fits device_properties(), much more than and extention
> of the pci attach args.
It would not be "the" pci attach args. That's the power of multiple
frontends that we can have special attach args, the softc extended
as needed and the extra code in its own source file which gets
only compiled if the kernel is configured that way.
With properties, you would have all that nasty parsing code in the
common sources. And no compile time type checks.
best regards
Matthias
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
--
Manuel Bouyer
>
> bou...@antioche.eu.org said:
> > up to now, device_properties() has been used to pass informations
> > which doesn't comes directly from the parent (as opposed to the attach
>
> If we allow to attach pci at acpi, the information would come
> directly from the parent. It is not only address space usage
> but also interrupt routing and power management.
>
> > of the pci attach args.
>
> frontends that we can have special attach args, the softc extended
> as needed and the extra code in its own source file which gets
> only compiled if the kernel is configured that way.
> With properties, you would have all that nasty parsing code in the
> common sources. And no compile time type checks.
this is true, if we attach it at acpi instead of pci.
To me it's not clear if it's the way to go (and I guess we'd need
a pci@pcibios as well ...). It has been argued before that attachement
at apci should go away, and use apci to drive the isa autoconf instead ...
Matthias Drochner
bou...@antioche.eu.org said:
> To me it's not clear if it's the way to go (and I guess we'd need a
> pci@pcibios as well ...
I think the pcibios gives so little value that it doesn't deserve
an extra attachment. ACPI is another league - it is essential
for interrupt routing and power management. Without it, you don't
get correct interrupt routing on MP systems (unless you resort
to MPIs...), and no system-wide power management on x86.
> It has been argued before that attachement
> at apci should go away
I think it is OK to attach the PCI buses which are defined by ACPI
at acpi. The attachment frontend can install hooks to get interrupt
routing right. This would also help wakeup support for eg USB
and ethernet devices.
> and use apci to drive the isa autoconf instead ...
My opinion on this is that we should get chips which are part
of the platform (timer/RTC/PICs/npx) out of the "isa" section,
so that one can use a modern PC without any isa bus configured.
ACPI's help might or might be useful for that -- at least it would
not be needed for a real ISA bus.
best regards
Matthias
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
--
Jukka Ruohonen
>
> I think it is OK to attach the PCI buses which are defined by ACPI
> at acpi. The attachment frontend can install hooks to get interrupt
> routing right. This would also help wakeup support for eg USB
> and ethernet devices.
Indeed. We need this for all PCI buses and devices. That is why hacks like
device_is_a() etc. won't do. And as you noted, there is awful lot of ugly
duplication because ACPI is already heavily required for x86 interrupt
routing. That said, I don't think this kind of attachment is required for
the IRQ setup per se (at least not in my branch).
- Jukka.