LinuxLists.cc - PCI Hotplug Drivers for 2.5

[permalink] [raw]

Subject: Re: PCI Hotplug Drivers for 2.5

On Wed, Oct 23, 2002 at 09:33:09PM -0700, Lee, Jung-Ik wrote:
> Greg,
>
> Please find the attached ACPI based PCI Hotplug driver.

But the code you sent has all of the ACPI stuff not enabled, right?

As an example from your patch:

+enum php_ctlr_type phphpc_get_ctlr_type()
+{
+ return PCI;
+}

It never returns any other type, so the ACPI or ISA sections of the
driver will never get called. Or am I missing something?

> intcphp:
> Php driver source for Compaq or compatible Intel Hotplug
> controllers on IA32 or DIG64-ACPI compliant IA64 platforms.

So this overloads the current Compaq driver? It looks like this "new"
driver will also handle all of the same controllers the current Compaq
driver does, right? If not, it sure looks like you are accepting all of
the same PCI ID values :)

> intcphp driver is overhauled per your requirements:
> + Abstraction module is removed.
> It's now two modules driver like others.

Thank you for making this change, I appreciate it.

> + typedefs are removed except callback function.

Thanks.

> + LINUX_VERSION checks are removed.

And replaced with the odd BEFORE_2_5 check :)
Please just rip these out and send a version that is only for the 2.5
kernel.

Some of your #ifdef CONFIG_IA64 should be moved to header files only
(and probably documented why you really need to sleep extra amounts for
ia64 machines only.

What's the #ifdef WORK_QUEUE for?

> intcphp is much based on cpqphp driver but has been modified to be
> controller independent on DIG64/ACPI compliant IPF servers as well as
> non-ACPI based IA32 servers. Thus code looks similar but integration is not
> that easy and will take time and consents of affected drivers owners.

The code looks _very_ similar. In fact, at first glance it looks like
almost a straight copy of the existing Compaq code. Why not just submit
a patch against that driver that adds the extra functionality that you
need for your hardware? That would be much smaller, and decrease the
amount of duplicated code in the kernel tree.

Also, why doesn't the ACPI PCI hotplug driver work for your machines?
I've seen it work on a very wide range of processors (i386 and ia64),
and manufacturers, and any specific issues with your hardware would
probably be better addressed with patches to the existing ACPI driver.

> We understand there needs more integration and cleanup to make
> common codes to pci_hotplug core as you indicated. This task, however,
> requires time and changes in every php driver with owners' consensus on
> common php controller/slot objects, while satisfying requirements in the
> near future. We look forward to discussing this with you and other
> contributors.

Great, I do too. Please, make a proposal about what to merge into the
core. I do NOT want to see another driver have to duplicate the PCI
resource management code again without a very good reason for doing it.

> Until then, please allow us to co-exist this driver.

There's no rush, let's work together to get this done properly.

thanks,

greg k-h

2002-10-24 05:52:31

by KOCHI, Takayoshi

[permalink] [raw]

Subject: Re: PCI Hotplug Drivers for 2.5

Hi,

On Wed, 23 Oct 2002 22:10:08 -0700
Greg KH <[email protected]> wrote:

> Also, why doesn't the ACPI PCI hotplug driver work for your machines?
> I've seen it work on a very wide range of processors (i386 and ia64),
> and manufacturers, and any specific issues with your hardware would
> probably be better addressed with patches to the existing ACPI driver.

The ACPI spec provides very limited control of actual hardware
(With ACPI, we don't have common method for controlling such as Bus
speed, LED etc.).
So if a hardware comes with well-documented hotplug controller, we
can achieve finer control over the hardware.

The SHPC specification defines it still depends on ACPI for managing
resources, etc. So resource management portion can be and *should be*
shared with all PCI hotplug drivers that use ACPI for resource
management.

I think the most important thing is everyone agree on the direction
in which we should go before we code anything, in order not to waste
our time.

Thanks,
--
KOCHI, Takayoshi <[email protected]/[email protected]>

2002-10-24 06:07:57

[permalink] [raw]

Subject: Re: PCI Hotplug Drivers for 2.5

On Wed, Oct 23, 2002 at 10:59:34PM -0700, KOCHI, Takayoshi wrote:
> Hi,
>
> On Wed, 23 Oct 2002 22:10:08 -0700
> Greg KH <[email protected]> wrote:
>
> > Also, why doesn't the ACPI PCI hotplug driver work for your machines?
> > I've seen it work on a very wide range of processors (i386 and ia64),
> > and manufacturers, and any specific issues with your hardware would
> > probably be better addressed with patches to the existing ACPI driver.
>
> The ACPI spec provides very limited control of actual hardware
> (With ACPI, we don't have common method for controlling such as Bus
> speed, LED etc.).
> So if a hardware comes with well-documented hotplug controller, we
> can achieve finer control over the hardware.

Ah, I didn't realize this. So for some machines (like IBM's x440), we
should stick with using the hotplug controller driver, instead of using
the ACPI driver. Sounds reasonable to me.

> The SHPC specification defines it still depends on ACPI for managing
> resources, etc. So resource management portion can be and *should be*
> shared with all PCI hotplug drivers that use ACPI for resource
> management.
>
> I think the most important thing is everyone agree on the direction
> in which we should go before we code anything, in order not to waste
> our time.

I think we now all agree that resource management should move into a
place where it can be shared by all pci hotplug drivers, right?

If so, anyone want to propose some common code? I think the stuff in
the ACPI driver that was pulled from the Compaq driver is a great start.
I can try to pull this into the core myself, but if the Intel developers
have the time, and energy, I would greatly appreciate their help (or
anyone else who wants to join in.)

thanks,

greg k-h

2002-10-24 11:43:45

by Matthew Wilcox

[permalink] [raw]

Subject: Re: [Linux-ia64] Re: PCI Hotplug Drivers for 2.5

On Wed, Oct 23, 2002 at 11:12:36PM -0700, Greg KH wrote:
> I think we now all agree that resource management should move into a
> place where it can be shared by all pci hotplug drivers, right?
>
> If so, anyone want to propose some common code? I think the stuff in
> the ACPI driver that was pulled from the Compaq driver is a great start.
> I can try to pull this into the core myself, but if the Intel developers
> have the time, and energy, I would greatly appreciate their help (or
> anyone else who wants to join in.)

We already _have_ a lot of common code in drivers/pci, but it's not
compiled in for x86 or ia64. some other architectures don't assign PCI
resources in the `BIOS' so we get to do it. setup-bus.c, setup-res.c
and setup-irq.c all seem to duplicate some part of the code currently
found in each and every hotplug driver.

--
Revolutions do not require corporate support.

2002-10-24 14:46:12

by Jeff Garzik

[permalink] [raw]

Subject: Re: PCI Hotplug Drivers for 2.5

Greg KH wrote:
>>The SHPC specification defines it still depends on ACPI for managing
>>resources, etc. So resource management portion can be and *should be*
>>shared with all PCI hotplug drivers that use ACPI for resource
>>management.
>>
>>I think the most important thing is everyone agree on the direction
>>in which we should go before we code anything, in order not to waste
>>our time.
>
>
> I think we now all agree that resource management should move into a
> place where it can be shared by all pci hotplug drivers, right?
>
> If so, anyone want to propose some common code?

drivers/pci/setup* is not enough?

I am surprised that anything needed to be added here...

2002-10-24 16:18:36

[permalink] [raw]

Subject: RE: PCI Hotplug Drivers for 2.5

Hi Greg,

My answers are next to your comments.

thanks,
J.I.

> -----Original Message-----
> From: Greg KH [mailto:[email protected]]
> Sent: Wednesday, October 23, 2002 10:10 PM
> To: Lee, Jung-Ik
> Cc: 'KOCHI, Takayoshi'; Luck, Tony;
> [email protected]; linux ia64 kernel list;
> linux-kernel
> Subject: Re: PCI Hotplug Drivers for 2.5
>
>
> On Wed, Oct 23, 2002 at 09:33:09PM -0700, Lee, Jung-Ik wrote:
> > Greg,
> >
> > Please find the attached ACPI based PCI Hotplug driver.
>
> But the code you sent has all of the ACPI stuff not enabled, right?

ACPI is a must for PHP enumeration/configuration and resource management for
DIG64/ACPI compliant platforms. ACPI method is optional for controller/slot
operations(event management). intcphp driver conforms to ACPI resource
management. I didn't enable ACPI based event management for PHP since it is
optional and provides less feature than controller based solution - LED,
MRL, Bus/Adapter speeds/capabilities, etc.

>
> As an example from your patch:
>
> +enum php_ctlr_type phphpc_get_ctlr_type()
> +{
> + return PCI;
> +}
>
> It never returns any other type, so the ACPI or ISA sections of the
> driver will never get called. Or am I missing something?
>
This is because this release only addresses PCI version only. I can take
this out too, with ease :)

> > intcphp:
> > Php driver source for Compaq or compatible Intel Hotplug
> > controllers on IA32 or DIG64-ACPI compliant IA64 platforms.
>
> So this overloads the current Compaq driver? It looks like this "new"
> driver will also handle all of the same controllers the current Compaq
> driver does, right? If not, it sure looks like you are
> accepting all of
> the same PCI ID values :)
>
Probably, as PCI ID indicates :)

> > intcphp driver is overhauled per your requirements:
> > + Abstraction module is removed.
> > It's now two modules driver like others.
>
> Thank you for making this change, I appreciate it.
>
> > + typedefs are removed except callback function.
>
> Thanks.
>
> > + LINUX_VERSION checks are removed.
>
> And replaced with the odd BEFORE_2_5 check :)
> Please just rip these out and send a version that is only for the 2.5
> kernel.
>
Ah, you noticed it.. OK (pain in my heart :))

> Some of your #ifdef CONFIG_IA64 should be moved to header files only
> (and probably documented why you really need to sleep extra
> amounts for
> ia64 machines only.
>
> What's the #ifdef WORK_QUEUE for?

Not used. Will take out.

>
> > intcphp is much based on cpqphp driver but has been
> modified to be
> > controller independent on DIG64/ACPI compliant IPF servers
> as well as
> > non-ACPI based IA32 servers. Thus code looks similar but
> integration is not
> > that easy and will take time and consents of affected
> drivers owners.
>
> The code looks _very_ similar. In fact, at first glance it looks like
> almost a straight copy of the existing Compaq code. Why not
> just submit
> a patch against that driver that adds the extra functionality that you
> need for your hardware? That would be much smaller, and decrease the
> amount of duplicated code in the kernel tree.
>
> Also, why doesn't the ACPI PCI hotplug driver work for your machines?
> I've seen it work on a very wide range of processors (i386 and ia64),
> and manufacturers, and any specific issues with your hardware would
> probably be better addressed with patches to the existing ACPI driver.
>
With some reasons such as what Tak described.

> > We understand there needs more integration and cleanup to make
> > common codes to pci_hotplug core as you indicated. This
> task, however,
> > requires time and changes in every php driver with owners'
> consensus on
> > common php controller/slot objects, while satisfying
> requirements in the
> > near future. We look forward to discussing this with you and other
> > contributors.
>
> Great, I do too. Please, make a proposal about what to merge into the
> core. I do NOT want to see another driver have to duplicate the PCI
> resource management code again without a very good reason for
> doing it.
>
> > Until then, please allow us to co-exist this driver.
>
> There's no rush, let's work together to get this done properly.
>
We need this driver as it's the only solution for DIG64 compliant IPF
platforms.
Can we work in parallel ? - Make this driver available and we all work
together for enhanced pci_hotplug core. Also I'll talk with cpqphp owner
over the integration of the two.

> thanks,
>
> greg k-h
>

2002-10-24 16:33:15

[permalink] [raw]

Subject: RE: PCI Hotplug Drivers for 2.5

>
> I think we now all agree that resource management should move into a
> place where it can be shared by all pci hotplug drivers, right?
>
> If so, anyone want to propose some common code? I think the stuff in
> the ACPI driver that was pulled from the Compaq driver is a
> great start.
> I can try to pull this into the core myself, but if the Intel
> developers
> have the time, and energy, I would greatly appreciate their help (or
> anyone else who wants to join in.)
>

Resource Management code in phprm.h works fine for both ACPI based platforms
and non-ACPI platforms (smbios, BIOS $HRT, pcibios_pci_irq_routing...) doing
php enumeration, configuration, resource allocation, etc. Only phprm_acpi.c
is included in this release for size matters.
intcphp driver is free from controller type, IA32/IPF, ACPI/non-ACPI and
depending on kernel configuration, it can bind to either ACPI PHPRM or
non-ACPI PHPRM.

PCI resource handling code - that does add/delete/sort/combine, etc on
pci_resource - has nothing to do with ACPI or non-ACPI so it should be
common across cpqphp, ibmphp, acpiphp and intcphp. They are duplicated and
varied due to mother structures differences.

> thanks,
>
> greg k-h
>

2002-10-24 16:43:05

[permalink] [raw]

Subject: Re: PCI Hotplug Drivers for 2.5

On Thu, Oct 24, 2002 at 09:24:30AM -0700, Lee, Jung-Ik wrote:
>
> ACPI is a must for PHP enumeration/configuration and resource management for
> DIG64/ACPI compliant platforms. ACPI method is optional for controller/slot
> operations(event management). intcphp driver conforms to ACPI resource
> management. I didn't enable ACPI based event management for PHP since it is
> optional and provides less feature than controller based solution - LED,
> MRL, Bus/Adapter speeds/capabilities, etc.

But as the code you sent me isn't enabled for ACPI, I don't see how it
ties into the existing Compaq based PCI driver. How does this work?
Are you trying to have 1 driver handle both the PCI and ACPI
functionality?

> > As an example from your patch:
> >
> > +enum php_ctlr_type phphpc_get_ctlr_type()
> > +{
> > + return PCI;
> > +}
> >
> > It never returns any other type, so the ACPI or ISA sections of the
> > driver will never get called. Or am I missing something?
> >
> This is because this release only addresses PCI version only. I can take
> this out too, with ease :)

As this means there is a lot of "dead code" in the driver, you should
take all of it out.

> > > intcphp:
> > > Php driver source for Compaq or compatible Intel Hotplug
> > > controllers on IA32 or DIG64-ACPI compliant IA64 platforms.
> >
> > So this overloads the current Compaq driver? It looks like this "new"
> > driver will also handle all of the same controllers the current Compaq
> > driver does, right? If not, it sure looks like you are
> > accepting all of
> > the same PCI ID values :)
> >
> Probably, as PCI ID indicates :)

Ok, no, I will not accept this driver then, as you are duplicating the
entire Compaq driver. Just provide a patch for the existing driver with
your new functionality.

> > > + LINUX_VERSION checks are removed.
> >
> > And replaced with the odd BEFORE_2_5 check :)
> > Please just rip these out and send a version that is only for the 2.5
> > kernel.
> >
> Ah, you noticed it.. OK (pain in my heart :))

Hm, directly trying to sneak something by me, by just renaming a
#define. Not nice. :(

> We need this driver as it's the only solution for DIG64 compliant IPF
> platforms.
> Can we work in parallel ? - Make this driver available and we all work
> together for enhanced pci_hotplug core.

No, does your driver _have_ to be in the 2.5 kernel tree right now for
some reason? Can't anyone who _has_ to have PCI Hotplug support for
these types of machines (and I don't think there are any types of these
machines currently shipping, right? And they wouldn't be running a 2.5
kernel on them, right?) just grab your driver if they really need it?

> Also I'll talk with cpqphp owner over the integration of the two.

You're talking to him :)

thanks,

greg k-h

2002-10-24 16:49:37

[permalink] [raw]

Subject: Re: PCI Hotplug Drivers for 2.5

On Thu, Oct 24, 2002 at 10:52:09AM -0400, Jeff Garzik wrote:
> Greg KH wrote:
> >I think we now all agree that resource management should move into a
> >place where it can be shared by all pci hotplug drivers, right?
> >
> >If so, anyone want to propose some common code?
>
>
> drivers/pci/setup* is not enough?
>
> I am surprised that anything needed to be added here...

There was some reason that code would not work out when I looked at it
over a year ago. But I don't remember why, so I'll go look at it again,
thanks for pointing it out.

greg k-h

2002-10-24 17:34:04

[permalink] [raw]

Subject: RE: PCI Hotplug Drivers for 2.5

> On Thu, Oct 24, 2002 at 09:24:30AM -0700, Lee, Jung-Ik wrote:
> >
> > ACPI is a must for PHP enumeration/configuration and
> resource management for
> > DIG64/ACPI compliant platforms. ACPI method is optional for
> controller/slot
> > operations(event management). intcphp driver conforms to
> ACPI resource
> > management. I didn't enable ACPI based event management for
> PHP since it is
> > optional and provides less feature than controller based
> solution - LED,
> > MRL, Bus/Adapter speeds/capabilities, etc.
>
> But as the code you sent me isn't enabled for ACPI, I don't see how it
> ties into the existing Compaq based PCI driver. How does this work?
> Are you trying to have 1 driver handle both the PCI and ACPI
> functionality?

Let me try again :)

**resource management**
Non-ACPI platforms uses $HRT/EBDA, pcibios_*(), SMBIOS, etc. for slot
enumeration/configuration.
DIG64/ACPI, and SHPC requires ACPI for this. IPF platforms only have ACPI
_CRS, _PRT, _HPP, _BBN, _STA, _ADR, _SUN, etc on the namespace for PHP, and
we have to use them. (as a side note, this functionality is common for other
hotplug-* as mentioned in first mail. No API will be common for
hotplug-everything, but functionality is common and has not to be
duplicated)

**event management in terms of controller/slot operations **
ACPI provides only _EJ0, _PS?, _STA, etc for slot operations but these are
not mandatory. That means, we can use either ACPI method or controller
driver.
intcphp driver has not enabled ACPI method based solution but uses
controller driver.
intcphp driver is also capable of performing ACPI method based solution
since it works on ACPI namespace. This is why acpiphp and intcphp could be
sharing resource management and event management.

>
> > > As an example from your patch:
> > >
> > > +enum php_ctlr_type phphpc_get_ctlr_type()
> > > +{
> > > + return PCI;
> > > +}
> > >
> > > It never returns any other type, so the ACPI or ISA
> sections of the
> > > driver will never get called. Or am I missing something?
> > >
> > This is because this release only addresses PCI version
> only. I can take
> > this out too, with ease :)
>
> As this means there is a lot of "dead code" in the driver, you should
> take all of it out.

Well, I removed many dead codes from the base driver. This is not dead code
but needed to support other types.
However, if it's not acceptable, I'll remove them.

> Hm, directly trying to sneak something by me, by just renaming a
> #define. Not nice. :(

No intention like that at all. Please regard this as bright side of
engineers simple version control w/ commonly used #ifdefs :)
Anyway, they'll be removed per your requirement.

>
> > We need this driver as it's the only solution for DIG64
> compliant IPF
> > platforms.
> > Can we work in parallel ? - Make this driver available and
> we all work
> > together for enhanced pci_hotplug core.
>
> No, does your driver _have_ to be in the 2.5 kernel tree right now for
> some reason? Can't anyone who _has_ to have PCI Hotplug support for
> these types of machines (and I don't think there are any
> types of these
> machines currently shipping, right? And they wouldn't be
> running a 2.5
> kernel on them, right?) just grab your driver if they really need it?
It's not my area to answer. It's product marketting. I do not want to skrew
marketting :)
We want the driver available before they compalint it :|
BTW, do we know how far is 2.6, even roughly ?

>
> > Also I'll talk with cpqphp owner over the integration of the two.
>
> You're talking to him :)

Ah. I now know why you are the one who talks about this :)
OK, then, I'll send you a patch against your cpqphp driver asap.

Thanks,
J.I.

2002-10-24 17:32:48

by KOCHI, Takayoshi

[permalink] [raw]

Subject: Re: PCI Hotplug Drivers for 2.5

> We need this driver as it's the only solution for DIG64 compliant IPF
> platforms.

No, not for all DIG64 compliant IPF platforms. NEC TX7 is also
a DIG64 compliant IPF platform but doesn't need your driver.

DIG64(2.1) only states that:

Firmware Support for PCI Hot-Plug
: Recommended if PCI Hot-Plug is
implemented
ACPI Support for PCI Hot-Plug : Recommended for platforms that
implement PCI Hot-Plug without SHPC
Using PCI Hot-Plug Specifications
: Recommended if PCI Hot-Plug is
implemented

The spec also states that any PCI Hot-Plug controller must
follow one of PCI Hot-Plug spec 1.1, SHPC 1.0 or CompactPCI Hot Swap
spec. It also strongly recommends SHPC 1.0, which is not covered
by J.I.'s driver yet.

But anyway Itanium2 platform using intel's hot-plug controller
will be shipping soon and J.I.'s driver has much better functionality
than acpiphp. This would be a decent reason for having the
driver in the mainline.

And this also motivates us to clean up the duplicated code if
it were in mainline:)

Thanks,
--
KOCHI, Takayoshi <[email protected]/[email protected]>

2002-10-24 17:37:59

[permalink] [raw]

Subject: Re: [Pcihpd-discuss] Re: PCI Hotplug Drivers for 2.5

On Thu, 24 Oct 2002, Greg KH wrote:

> On Thu, Oct 24, 2002 at 10:52:09AM -0400, Jeff Garzik wrote:
> > Greg KH wrote:
> > >I think we now all agree that resource management should move into a
> > >place where it can be shared by all pci hotplug drivers, right?
> > >
> > >If so, anyone want to propose some common code?
> >
> >
> > drivers/pci/setup* is not enough?
> >
> > I am surprised that anything needed to be added here...
>
> There was some reason that code would not work out when I looked at it
> over a year ago. But I don't remember why, so I'll go look at it again,
> thanks for pointing it out.

I don't know if you looked at my cPCI driver patch in detail, but it uses
the setup-*.c code for all of its resource management. The only things
that were really missing in 2.4.x were:

- exports of a few things, most notably pci_scan_bridge
- code to update the resource windows of a newly added bridge (recursively)
- a pci_write_bridge_bases
- PCI resource reservation to allow hot insertion on dumb cPCI hardware
- on x86, the smarts to work back to the root PCI bus to figure out the
IRQ pin to use when looking in the pirq table

Since I've been swamped with other stuff, I just started finally porting
my cPCI stuff to 2.5 yesterday. :( I think I can get it up and running
relatively quickly, but figuring out Ivan's newer hotplug helper code
and how to take advantage of it might take me a couple of days.

Scott

--
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [email protected]

2002-10-24 17:53:04

by Matthew Wilcox

[permalink] [raw]

Subject: Re: [Linux-ia64] RE: PCI Hotplug Drivers for 2.5

On Thu, Oct 24, 2002 at 10:40:05AM -0700, Lee, Jung-Ik wrote:
> **resource management**
> Non-ACPI platforms uses $HRT/EBDA, pcibios_*(), SMBIOS, etc. for slot
> enumeration/configuration.
> DIG64/ACPI, and SHPC requires ACPI for this. IPF platforms only have ACPI
> _CRS, _PRT, _HPP, _BBN, _STA, _ADR, _SUN, etc on the namespace for PHP, and
> we have to use them. (as a side note, this functionality is common for other
> hotplug-* as mentioned in first mail. No API will be common for
> hotplug-everything, but functionality is common and has not to be
> duplicated)

> **event management in terms of controller/slot operations **
> ACPI provides only _EJ0, _PS?, _STA, etc for slot operations but these are
> not mandatory. That means, we can use either ACPI method or controller
> driver.
> intcphp driver has not enabled ACPI method based solution but uses
> controller driver.
> intcphp driver is also capable of performing ACPI method based solution
> since it works on ACPI namespace. This is why acpiphp and intcphp could be
> sharing resource management and event management.

Sounds like we want a library of ACPI code that can be used by individual
drivers rather than an ACPI driver with pluggable event management
functions then.

--
Revolutions do not require corporate support.

2002-10-24 17:46:55

by Jeff Garzik

[permalink] [raw]

Subject: Re: PCI Hotplug Drivers for 2.5

KOCHI, Takayoshi wrote:
>>We need this driver as it's the only solution for DIG64 compliant IPF
>>platforms.
>
>
> No, not for all DIG64 compliant IPF platforms. NEC TX7 is also
> a DIG64 compliant IPF platform but doesn't need your driver.

Tangent:

Intel is wrong by renaming IA64 to "IPF".

It was previously used as "Intel Processor Family". IA64 is a far
better name, and I will continue to use that in preference to IPF.
Re-using an acronym is silly and creates confusion.

Jeff

2002-10-24 18:33:36

[permalink] [raw]

Subject: RE: PCI Hotplug Drivers for 2.5

> > We need this driver as it's the only solution for DIG64
> compliant IPF
> > platforms.
>
> No, not for all DIG64 compliant IPF platforms. NEC TX7 is also
> a DIG64 compliant IPF platform but doesn't need your driver.

Well, I forgot acpiphp driver was removed in this driver patch :)
acpiphp is also for DIG64/ACPI and will do for some DIG64/ACPI machines
while intcphp is feature full driver for IPF platform PHP.

>
> DIG64(2.1) only states that:
>
> Firmware Support for PCI Hot-Plug
> : Recommended if PCI Hot-Plug is
> implemented
> ACPI Support for PCI Hot-Plug : Recommended for platforms that
> implement PCI Hot-Plug without SHPC
> Using PCI Hot-Plug Specifications
> : Recommended if PCI Hot-Plug is
> implemented

ACPI IS mandatory for DIG64 PHP resource management by SHPC, while ACPI
based slot operation is not required.
The above sentence only could be misleading.

>
> The spec also states that any PCI Hot-Plug controller must
> follow one of PCI Hot-Plug spec 1.1, SHPC 1.0 or CompactPCI Hot Swap
> spec. It also strongly recommends SHPC 1.0, which is not covered
> by J.I.'s driver yet.

intcphp is desined with SHPC on plan in terms of ACPI resource management,
as SHPC spec says
"DIG64 compliant platforms must use ACPI to describe resource allocation."
But it is not completely ready for SHPC yet. It's a matter of deployment
schedules of dependencies such as HPRT, ACPI methods OSHP, HBRB, etc which
will need to be enabled in Linux kernel ACPI driver/platform firmware.

>
> But anyway Itanium2 platform using intel's hot-plug controller
> will be shipping soon and J.I.'s driver has much better functionality
> than acpiphp. This would be a decent reason for having the
> driver in the mainline.
>
> And this also motivates us to clean up the duplicated code if
> it were in mainline:)

\o/ second to this :)

>
> Thanks,
> --
> KOCHI, Takayoshi <[email protected]/[email protected]>
>

2002-10-24 21:45:24

[permalink] [raw]

Subject: Re: [Pcihpd-discuss] Re: PCI Hotplug Drivers for 2.5

On Thu, Oct 24, 2002 at 01:44:06PM -0400, Scott Murray wrote:
>
> I don't know if you looked at my cPCI driver patch in detail, but it uses
> the setup-*.c code for all of its resource management.

I'm sorry, but I only glanced at it and missed this point.

> The only things that were really missing in 2.4.x were:
>
> - exports of a few things, most notably pci_scan_bridge
> - code to update the resource windows of a newly added bridge (recursively)
> - a pci_write_bridge_bases
> - PCI resource reservation to allow hot insertion on dumb cPCI hardware
> - on x86, the smarts to work back to the root PCI bus to figure out the
> IRQ pin to use when looking in the pirq table

All of these seem like things that should belong in the setup-*.c files
for others to use.

> Since I've been swamped with other stuff, I just started finally porting
> my cPCI stuff to 2.5 yesterday. :( I think I can get it up and running
> relatively quickly, but figuring out Ivan's newer hotplug helper code
> and how to take advantage of it might take me a couple of days.

Nice, I was wondering what happened. I'll go dig up your older patch
and take a closer look at it.

thanks,

greg k-h

2002-10-24 22:01:40

[permalink] [raw]

Subject: Re: PCI Hotplug Drivers for 2.5

On Thu, Oct 24, 2002 at 10:40:05AM -0700, Lee, Jung-Ik wrote:
>
> **resource management**
> Non-ACPI platforms uses $HRT/EBDA, pcibios_*(), SMBIOS, etc. for slot
> enumeration/configuration.
> DIG64/ACPI, and SHPC requires ACPI for this. IPF platforms only have ACPI
> _CRS, _PRT, _HPP, _BBN, _STA, _ADR, _SUN, etc on the namespace for PHP, and
> we have to use them. (as a side note, this functionality is common for other
> hotplug-* as mentioned in first mail. No API will be common for
> hotplug-everything, but functionality is common and has not to be
> duplicated)
>
> **event management in terms of controller/slot operations **
> ACPI provides only _EJ0, _PS?, _STA, etc for slot operations but these are
> not mandatory. That means, we can use either ACPI method or controller
> driver.
> intcphp driver has not enabled ACPI method based solution but uses
> controller driver.
> intcphp driver is also capable of performing ACPI method based solution
> since it works on ACPI namespace. This is why acpiphp and intcphp could be
> sharing resource management and event management.

Ok, that makes more sense to me now. Thank you for taking the time to
explain this.

> > As this means there is a lot of "dead code" in the driver, you should
> > take all of it out.
>
> Well, I removed many dead codes from the base driver. This is not dead code
> but needed to support other types.
> However, if it's not acceptable, I'll remove them.

If the code can never be called, it looks pretty dead to me :)

But as you're going to be sending me a patch for the existing driver, we
don't have to worry about this anymore.

> OK, then, I'll send you a patch against your cpqphp driver asap.

Looking forward to it.

thanks,

greg k-h

2002-10-24 22:16:35

[permalink] [raw]

Subject: Re: [Pcihpd-discuss] Re: PCI Hotplug Drivers for 2.5

On Thu, 24 Oct 2002, Greg KH wrote:

> On Thu, Oct 24, 2002 at 01:44:06PM -0400, Scott Murray wrote:
> >
> > I don't know if you looked at my cPCI driver patch in detail, but it uses
> > the setup-*.c code for all of its resource management.
>
> I'm sorry, but I only glanced at it and missed this point.

No problemo, I kind of vanished off the face of the earth after my last
mention of releasing a 2.5 patch, which was over a month and a half ago.
Now that we've got our new hardware platform up and running here at SOMA,
I'm back in a position to work on hotplug stuff again.

> > The only things that were really missing in 2.4.x were:
> >
> > - exports of a few things, most notably pci_scan_bridge
> > - code to update the resource windows of a newly added bridge (recursively)
> > - a pci_write_bridge_bases
> > - PCI resource reservation to allow hot insertion on dumb cPCI hardware
> > - on x86, the smarts to work back to the root PCI bus to figure out the
> > IRQ pin to use when looking in the pirq table
>
> All of these seem like things that should belong in the setup-*.c files
> for others to use.

I think Ivan's new code in setup-bus.c (pbus_size_bridges and friends)
removes the need for a pci_write_bridge_bases and my code to update the
bridge resource windows. I hope so, since I've changed my driver to use
it! ;)

> > Since I've been swamped with other stuff, I just started finally porting
> > my cPCI stuff to 2.5 yesterday. :( I think I can get it up and running
> > relatively quickly, but figuring out Ivan's newer hotplug helper code
> > and how to take advantage of it might take me a couple of days.
>
> Nice, I was wondering what happened. I'll go dig up your older patch
> and take a closer look at it.

I hopefully will have something working against 2.5.44 tomorrow. I think
the only potentially contentious piece that I'd like to get reviewed and
maybe integrated before the feature freeze is the resource reservation
stuff. There seemed to be no serious objections to the 2.4.x version I
posted a while back, so maybe this won't be a big deal. Everything else
is either __devinit/export tweaks or driver code.

Scott

--
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [email protected]

2002-10-25 15:32:48

by Ivan Kokshaysky

[permalink] [raw]

Subject: Re: [Pcihpd-discuss] Re: PCI Hotplug Drivers for 2.5

On Thu, Oct 24, 2002 at 06:22:44PM -0400, Scott Murray wrote:
> I hopefully will have something working against 2.5.44 tomorrow. I think
> the only potentially contentious piece that I'd like to get reviewed and
> maybe integrated before the feature freeze is the resource reservation
> stuff. There seemed to be no serious objections to the 2.4.x version I
> posted a while back, so maybe this won't be a big deal. Everything else
> is either __devinit/export tweaks or driver code.

The setup-bus code already does resource reservation, but only for
cardbus. It can be easily extended for any type of hotplug
controller though. Other enhancements (like configurable amount
of reserved IO/memory) also shouldn't be a problem.

Also I have a patch (appended) that allows to use pbus_size_bridges()
for cardbus bridges (which have different resource layout vs. PCI-to-PCI
ones).

BTW, 2.5 setup-* stuff went into 2.4 recently. :-)

Ivan.

--- 2.5.36/drivers/pci/setup-res.c Wed Sep 18 04:59:13 2002
+++ linux/drivers/pci/setup-res.c Thu Sep 19 19:31:45 2002
@@ -137,7 +137,7 @@ pci_assign_resource(struct pci_dev *dev,
}

/* Sort resources by alignment */
-void __init
+void __devinit
pdev_sort_resources(struct pci_dev *dev, struct resource_list *head)
{
int i;
--- 2.5.36/drivers/pci/setup-bus.c Wed Sep 18 04:58:56 2002
+++ linux/drivers/pci/setup-bus.c Thu Sep 19 19:29:04 2002
@@ -35,7 +35,7 @@

#define ROUND_UP(x, a) (((x) + (a) - 1) & ~((a) - 1))

-static int __init
+static int __devinit
pbus_assign_resources_sorted(struct pci_bus *bus)
{
struct list_head *ln;
@@ -85,7 +85,7 @@ pbus_assign_resources_sorted(struct pci_
requires that if there is no I/O ports or memory behind the
bridge, corresponding range must be turned off by writing base
value greater than limit to the bridge's base/limit registers. */
-static void __init
+static void __devinit
pci_setup_bridge(struct pci_bus *bus)
{
struct pbus_set_ranges_data ranges;
@@ -168,7 +168,7 @@ pci_setup_bridge(struct pci_bus *bus)
/* Check whether the bridge supports optional I/O and
prefetchable memory ranges. If not, the respective
base/limit registers must be read-only and read as 0. */
-static void __init
+static void __devinit
pci_bridge_check_ranges(struct pci_bus *bus)
{
u16 io;
@@ -206,20 +206,38 @@ pci_bridge_check_ranges(struct pci_bus *
b_res[2].flags |= IORESOURCE_MEM | IORESOURCE_PREFETCH;
}

+/* Find first free bus resource of a given type */
+static struct resource * __devinit
+pbus_find_resource(struct pci_bus *bus, unsigned long type)
+{
+ int i;
+ struct resource *r;
+
+ for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
+ r = bus->resource[i];
+ if (r && !((r->flags ^ type) & type) && !r->parent)
+ return r;
+ }
+ return NULL;
+}
+
/* Sizing the IO windows of the PCI-PCI bridge is trivial,
since these windows have 4K granularity and the IO ranges
of non-bridge PCI devices are limited to 256 bytes.
We must be careful with the ISA aliasing though. */
-static void __init
+static void __devinit
pbus_size_io(struct pci_bus *bus)
{
struct list_head *ln;
- struct resource *b_res = bus->resource[0];
+ struct resource *b_res = pbus_find_resource(bus, IORESOURCE_IO);
unsigned long size = 0, size1 = 0;

- if (!(b_res->flags & IORESOURCE_IO))
+ if (!b_res)
return;

+ DBGC((KERN_INFO "PCI: found %s resource %ld for IO\n",
+ bus->name, b_res - bus->resource[0]));
+
for (ln=bus->devices.next; ln != &bus->devices; ln=ln->next) {
struct pci_dev *dev = pci_dev_b(ln);
int i;
@@ -259,15 +277,21 @@ pbus_size_io(struct pci_bus *bus)

/* Calculate the size of the bus and minimal alignment which
guarantees that all child resources fit in this size. */
-static void __init
+static int __devinit
pbus_size_mem(struct pci_bus *bus, unsigned long mask, unsigned long type)
{
struct list_head *ln;
unsigned long min_align, align, size;
unsigned long aligns[12]; /* Alignments from 1Mb to 2Gb */
int order, max_order;
- struct resource *b_res = (type & IORESOURCE_PREFETCH) ?
- bus->resource[2] : bus->resource[1];
+ struct resource *b_res = pbus_find_resource(bus, type);
+
+ if (!b_res)
+ return 0;
+
+ DBGC((KERN_INFO "PCI: found %s resource %ld for %s\n",
+ bus->name, b_res - bus->resource[0],
+ type & IORESOURCE_PREFETCH ? "PREF" : "MEM"));

memset(aligns, 0, sizeof(aligns));
max_order = 0;
@@ -325,17 +349,18 @@ pbus_size_mem(struct pci_bus *bus, unsig
size = ROUND_UP(size, min_align);
if (!size) {
b_res->flags = 0;
- return;
+ return 1;
}
b_res->start = min_align;
b_res->end = size + min_align - 1;
+ return 1;
}

-void __init
+void __devinit
pbus_size_bridges(struct pci_bus *bus)
{
struct list_head *ln;
- unsigned long mask, type;
+ unsigned long mask, prefetch;

for (ln=bus->children.next; ln != &bus->children; ln=ln->next)
pbus_size_bridges(pci_bus_b(ln));
@@ -348,17 +373,15 @@ pbus_size_bridges(struct pci_bus *bus)

pbus_size_io(bus);

- mask = type = IORESOURCE_MEM;
+ mask = IORESOURCE_MEM;
+ prefetch = IORESOURCE_MEM | IORESOURCE_PREFETCH;
/* If the bridge supports prefetchable range, size it separately. */
- if (bus->resource[2] &&
- bus->resource[2]->flags & IORESOURCE_PREFETCH) {
- pbus_size_mem(bus, IORESOURCE_PREFETCH, IORESOURCE_PREFETCH);
- mask |= IORESOURCE_PREFETCH; /* Size non-prefetch only. */
- }
- pbus_size_mem(bus, mask, type);
+ if (pbus_size_mem(bus, prefetch, prefetch))
+ mask = prefetch; /* Size non-prefetch only. */
+ pbus_size_mem(bus, mask, IORESOURCE_MEM);
}

-void __init
+void __devinit
pbus_assign_resources(struct pci_bus *bus)
{
struct list_head *ln;
@@ -367,7 +390,8 @@ pbus_assign_resources(struct pci_bus *bu
if (found_vga) {
struct pci_bus *b;

- /* Propagate presence of the VGA to upstream bridges */
+ /* Propagate presence of the VGA to upstream bridges.
+ This hack eventually will go away. */
for (b = bus; b->parent; b = b->parent) {
b->resource[0]->flags |= IORESOURCE_BUS_HAS_VGA;
}

2002-10-25 21:56:25

[permalink] [raw]

Subject: Re: [Pcihpd-discuss] Re: PCI Hotplug Drivers for 2.5

On Fri, 25 Oct 2002, Ivan Kokshaysky wrote:

> On Thu, Oct 24, 2002 at 06:22:44PM -0400, Scott Murray wrote:
> > I hopefully will have something working against 2.5.44 tomorrow. I think
> > the only potentially contentious piece that I'd like to get reviewed and
> > maybe integrated before the feature freeze is the resource reservation
> > stuff. There seemed to be no serious objections to the 2.4.x version I
> > posted a while back, so maybe this won't be a big deal. Everything else
> > is either __devinit/export tweaks or driver code.
>
> The setup-bus code already does resource reservation, but only for
> cardbus. It can be easily extended for any type of hotplug
> controller though. Other enhancements (like configurable amount
> of reserved IO/memory) also shouldn't be a problem.

Unfortunately, my take on the scheme used to reserve space for CardBus
bridges was that it only works on platforms that use the setup-*.c code
to do their complete PCI subsystem initialization. On platforms like
x86, where the BIOS configures all the devices, something like my patch
is needed to fixup things to handle the desired reservation. I'm not
finished getting things ported to 2.5 yet, I'll post a patch ASAP once
I've got everything workin. If you're keen on devising an alternative
method, check put my old patch against 2.4.19 at:

http://marc.theaimsgroup.com/?l=linux-kernel&m=102866931731553&w=2

[snip]
> BTW, 2.5 setup-* stuff went into 2.4 recently. :-)

Cool, that definitely will make my life easier.

Thanks,

Scott

--
Scott Murray
SOMA Networks, Inc.
Toronto, Ontario
e-mail: [email protected]

2002-10-25 22:22:39

by Russell King

[permalink] [raw]

Subject: Re: [Pcihpd-discuss] Re: PCI Hotplug Drivers for 2.5

On Fri, Oct 25, 2002 at 06:02:31PM -0400, Scott Murray wrote:
> Unfortunately, my take on the scheme used to reserve space for CardBus
> bridges was that it only works on platforms that use the setup-*.c code
> to do their complete PCI subsystem initialization. On platforms like
> x86, where the BIOS configures all the devices, something like my patch
> is needed to fixup things to handle the desired reservation. I'm not
> finished getting things ported to 2.5 yet, I'll post a patch ASAP once
> I've got everything workin. If you're keen on devising an alternative
> method, check put my old patch against 2.4.19 at:

I've been working on this in 2.5 this week - I've got something working,
Alan's happy with the concept as far as the resource allocation goes.

The cardbus reservation method is actually flawed in setup-*.c if you
want to get rid of the stuff in yenta.c - again, I've fixed this lot
in my 2.5 tree already, and the patch is pending an update to the x86
code to do what yenta.c was doing (only setup bridge resources of the
ones already programmed are bad/wrong.)

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

2002-10-26 23:30:16