--- linux-2.6.0-test2/include/linux/pci_ids.h~ 2003-08-06 13:32:28.000000000 -0600
+++ linux-2.6.0-test2/include/linux/pci_ids.h 2003-08-06 13:34:53.000000000 -0600
@@ -608,6 +608,7 @@
#define PCI_DEVICE_ID_HP_DIVA_TOSCA1 0x1049
#define PCI_DEVICE_ID_HP_DIVA_TOSCA2 0x104A
#define PCI_DEVICE_ID_HP_DIVA_MAESTRO 0x104B
+#define PCI_DEVICE_ID_HP_PCI_LBA 0x1054
#define PCI_DEVICE_ID_HP_REO_SBA 0x10f0
#define PCI_DEVICE_ID_HP_REO_IOC 0x10f1
#define PCI_DEVICE_ID_HP_VISUALIZE_FXE 0x108b
@@ -616,7 +617,7 @@
#define PCI_DEVICE_ID_HP_DIVA_POWERBAR 0x1227
#define PCI_DEVICE_ID_HP_ZX1_SBA 0x1229
#define PCI_DEVICE_ID_HP_ZX1_IOC 0x122a
-#define PCI_DEVICE_ID_HP_ZX1_LBA 0x122e
+#define PCI_DEVICE_ID_HP_PCIX_LBA 0x122e
#define PCI_DEVICE_ID_HP_SX1000_IOC 0x127c
#define PCI_DEVICE_ID_HP_DIVA_EVEREST 0x1282
#define PCI_DEVICE_ID_HP_DIVA_AUX 0x1290
--- linux-2.6.0-test2/drivers/pci/pci.ids~ 2003-08-06 13:32:08.000000000 -0600
+++ linux-2.6.0-test2/drivers/pci/pci.ids 2003-08-06 13:32:59.000000000 -0600
@@ -1286,6 +1286,7 @@
103c 1226 Keystone SP2
103c 1227 Powerbar SP2
103c 1282 Everest SP2
+ 1054 PCI Local Bus Adapter
1064 79C970 PCnet Ethernet Controller
108b Visualize FXe
10c1 NetServer Smart IRQ Router
@@ -1297,7 +1298,7 @@
121c NetServer PCI COM Port Decoder
1229 zx1 System Bus Adapter
122a zx1 I/O Controller
- 122e zx1 Local Bus Adapter
+ 122e PCI-X/AGP Local Bus Adapter
1290 Auxiliary Diva Serial Port
2910 E2910A PCIBus Exerciser
2925 E2925A 32 Bit, 33 MHzPCI Exerciser & Analyzer
--- linux-2.6.0-test2/drivers/char/agp/hp-agp.c~ 2003-08-06 13:32:54.000000000 -0600
+++ linux-2.6.0-test2/drivers/char/agp/hp-agp.c 2003-08-06 13:33:56.000000000 -0600
@@ -398,7 +398,7 @@
bridge->driver = &hp_zx1_driver;
fake_bridge_dev.vendor = PCI_VENDOR_ID_HP;
- fake_bridge_dev.device = PCI_DEVICE_ID_HP_ZX1_LBA;
+ fake_bridge_dev.device = PCI_DEVICE_ID_HP_PCIX_LBA;
bridge->dev = &fake_bridge_dev;
return agp_add_bridge(bridge);
On Wednesday 06 August 2003 1:54 pm, Alex Williamson wrote:
> This patch renames the PCI-X adapter found in HP zx1 and sx1000
> ia64 systems to something more generic and descriptive. It also
> adds an ID for the PCI adapter used in sx1000. Patches against
> 2.4.21+ia64 and 2.6.0-test2+ia64 attached. Thanks,
I applied this for the 2.4 ia64 patch.
Marcelo, do we need to do anything else to get this in your tree?
--- linux-2.4.21/include/linux/pci_ids.h~ 2003-08-06 13:18:56.000000000 -0600
+++ linux-2.4.21/include/linux/pci_ids.h 2003-08-06 13:19:07.000000000 -0600
@@ -539,11 +539,12 @@
#define PCI_DEVICE_ID_HP_DIVA1 0x1049
#define PCI_DEVICE_ID_HP_DIVA2 0x104A
#define PCI_DEVICE_ID_HP_SP2_0 0x104B
+#define PCI_DEVICE_ID_HP_PCI_LBA 0x1054
#define PCI_DEVICE_ID_HP_REO_SBA 0x10f0
#define PCI_DEVICE_ID_HP_REO_IOC 0x10f1
#define PCI_DEVICE_ID_HP_ZX1_SBA 0x1229
#define PCI_DEVICE_ID_HP_ZX1_IOC 0x122a
-#define PCI_DEVICE_ID_HP_ZX1_LBA 0x122e
+#define PCI_DEVICE_ID_HP_PCIX_LBA 0x122e
#define PCI_DEVICE_ID_HP_SX1000_IOC 0x127c
#define PCI_VENDOR_ID_PCTECH 0x1042
--- linux-2.4.21/drivers/pci/pci.ids~ 2003-08-06 13:18:30.000000000 -0600
+++ linux-2.4.21/drivers/pci/pci.ids 2003-08-06 13:19:07.000000000 -0600
@@ -1212,6 +1212,7 @@
103c 1226 Keystone SP2
103c 1227 Powerbar SP2
103c 1282 Everest SP2
+ 1054 PCI Local Bus Adapter
1064 79C970 PCnet Ethernet Controller
108b Visualize FXe
10c1 NetServer Smart IRQ Router
@@ -1223,7 +1224,7 @@
121c NetServer PCI COM Port Decoder
1229 zx1 System Bus Adapter
122a zx1 I/O Controller
- 122e zx1 Local Bus Adapter
+ 122e PCI-X/AGP Local Bus Adapter
1290 Auxiliary Diva Serial Port
2910 E2910A PCIBus Exerciser
2925 E2925A 32 Bit, 33 MHzPCI Exerciser & Analyzer
--- linux-2.4.21/drivers/char/agp/agpgart_be.c~ 2003-08-06 13:18:20.000000000 -0600
+++ linux-2.4.21/drivers/char/agp/agpgart_be.c 2003-08-06 13:19:07.000000000 -0600
@@ -4853,7 +4853,7 @@
agp_bridge.type = HP_ZX1;
fake_bridge_dev.vendor = PCI_VENDOR_ID_HP;
- fake_bridge_dev.device = PCI_DEVICE_ID_HP_ZX1_LBA;
+ fake_bridge_dev.device = PCI_DEVICE_ID_HP_PCIX_LBA;
return hp_zx1_ioc_init(ioc_hpa, lba_hpa);
}
On Wed, Aug 06, 2003 at 01:54:05PM -0600, Alex Williamson wrote:
>
> This patch renames the PCI-X adapter found in HP zx1 and sx1000
> ia64 systems to something more generic and descriptive. It also
> adds an ID for the PCI adapter used in sx1000. Patches against
> 2.4.21+ia64 and 2.6.0-test2+ia64 attached. Thanks,
I've applied the 2.6 patch to my trees and will send it on to Linus in a
few days, thanks.
greg k-h
Greg KH wrote:
> I've applied the 2.6 patch to my trees and will send it on to Linus in a
> few days, thanks.
Speaking of PCI... are we gonna have to zap __devinit too? Another
option is to think of add-new-pci-ids-on-the-fly as a CONFIG_HOTPLUG
feature, which should(?) maintain the current __devinit semantics: no
re-probes.
OTOH, __devinit already is a no-op for CONFIG_HOTPLUG cases (read: most
everybody), so I wonder if we care enough about __devinit anymore? I
used the same logic to support __devinitdata removal, after all.
Jeff
On Wed, Aug 06, 2003 at 07:21:23PM -0400, Jeff Garzik wrote:
> Greg KH wrote:
> >I've applied the 2.6 patch to my trees and will send it on to Linus in a
> >few days, thanks.
>
>
> Speaking of PCI... are we gonna have to zap __devinit too? Another
> option is to think of add-new-pci-ids-on-the-fly as a CONFIG_HOTPLUG
> feature, which should(?) maintain the current __devinit semantics: no
> re-probes.
Yeah, that option does break almost all current usages of __devinit* in
pci drivers today with CONFIG_HOTPLUG disabled :(
So either making it a different config option, or just dropping
__devinit* all together is fine with me, one of them needs to happen.
Any preferences from anyone else?
> OTOH, __devinit already is a no-op for CONFIG_HOTPLUG cases (read: most
> everybody), so I wonder if we care enough about __devinit anymore? I
> used the same logic to support __devinitdata removal, after all.
If we drop __devinit* then having CONFIG_HOTPLUG as a config option is
almost pointless as it doesn't really affect much code at all. Any
objections to just always enabling it?
Anyone want to make up any before and after memory usages with
CONFIG_HOTPLUG enabled and disabled to see if it's really as small as
I'm thinking it is?
Do the embedded people care? :)
thanks,
greg k-h
On Wed, 6 Aug 2003, Bjorn Helgaas wrote:
> On Wednesday 06 August 2003 1:54 pm, Alex Williamson wrote:
> > This patch renames the PCI-X adapter found in HP zx1 and sx1000
> > ia64 systems to something more generic and descriptive. It also
> > adds an ID for the PCI adapter used in sx1000. Patches against
> > 2.4.21+ia64 and 2.6.0-test2+ia64 attached. Thanks,
>
> I applied this for the 2.4 ia64 patch.
>
> Marcelo, do we need to do anything else to get this in your tree?
Nope. Its in.
On Wed, 6 Aug 2003, Bjorn Helgaas wrote:
> On Wednesday 06 August 2003 1:54 pm, Alex Williamson wrote:
> > This patch renames the PCI-X adapter found in HP zx1 and sx1000
> > ia64 systems to something more generic and descriptive. It also
> > adds an ID for the PCI adapter used in sx1000. Patches against
> > 2.4.21+ia64 and 2.6.0-test2+ia64 attached. Thanks,
>
> I applied this for the 2.4 ia64 patch.
>
> Marcelo, do we need to do anything else to get this in your tree?
Actually this doesnt apply cleanly to my tree Bjorn.
Can you please send me an updated patch?
On Thursday 07 August 2003 6:32 am, Marcelo Tosatti wrote:
> On Wed, 6 Aug 2003, Bjorn Helgaas wrote:
> > On Wednesday 06 August 2003 1:54 pm, Alex Williamson wrote:
> > > This patch renames the PCI-X adapter found in HP zx1 and sx1000
> > > ia64 systems to something more generic and descriptive. It also
> > > adds an ID for the PCI adapter used in sx1000. Patches against
> > > 2.4.21+ia64 and 2.6.0-test2+ia64 attached. Thanks,
> >
> > I applied this for the 2.4 ia64 patch.
> >
> > Marcelo, do we need to do anything else to get this in your tree?
>
>
> Actually this doesnt apply cleanly to my tree Bjorn.
>
> Can you please send me an updated patch?
Oops, sorry about that. Here's an updated one. It doesn't include
the agpgart bit because you don't have the latest HP ZX1 gart
code. I'll try to get that merged up soon.
===== drivers/pci/pci.ids 1.37 vs edited =====
--- 1.37/drivers/pci/pci.ids Sun Jun 29 09:10:14 2003
+++ edited/drivers/pci/pci.ids Thu Aug 7 10:43:57 2003
@@ -1348,6 +1348,7 @@
103c 1226 Keystone SP2
103c 1227 Powerbar SP2
103c 1282 Everest SP2
+ 1054 PCI Local Bus Adapter
1064 79C970 PCnet Ethernet Controller
108b Visualize FXe
10c1 NetServer Smart IRQ Router
@@ -1359,7 +1360,8 @@
121c NetServer PCI COM Port Decoder
1229 zx1 System Bus Adapter
122a zx1 I/O Controller
- 122e zx1 Local Bus Adapter
+ 122e PCI-X/AGP Local Bus Adapter
+ 127c sx1000 I/O Controller
1290 Auxiliary Diva Serial Port
2910 E2910A PCIBus Exerciser
2925 E2925A 32 Bit, 33 MHzPCI Exerciser & Analyzer
===== include/linux/pci_ids.h 1.67 vs edited =====
--- 1.67/include/linux/pci_ids.h Tue Aug 5 09:37:33 2003
+++ edited/include/linux/pci_ids.h Thu Aug 7 10:38:29 2003
@@ -589,11 +589,13 @@
#define PCI_DEVICE_ID_HP_DIVA1 0x1049
#define PCI_DEVICE_ID_HP_DIVA2 0x104A
#define PCI_DEVICE_ID_HP_SP2_0 0x104B
+#define PCI_DEVICE_ID_HP_PCI_LBA 0x1054
#define PCI_DEVICE_ID_HP_REO_SBA 0x10f0
#define PCI_DEVICE_ID_HP_REO_IOC 0x10f1
#define PCI_DEVICE_ID_HP_ZX1_SBA 0x1229
#define PCI_DEVICE_ID_HP_ZX1_IOC 0x122a
-#define PCI_DEVICE_ID_HP_ZX1_LBA 0x122e
+#define PCI_DEVICE_ID_HP_PCIX_LBA 0x122e
+#define PCI_DEVICE_ID_HP_SX1000_IOC 0x127c
#define PCI_VENDOR_ID_PCTECH 0x1042
#define PCI_DEVICE_ID_PCTECH_RZ1000 0x1000
On Wed, Aug 06, 2003 at 04:31:03PM -0700, Greg KH wrote:
> On Wed, Aug 06, 2003 at 07:21:23PM -0400, Jeff Garzik wrote:
> > Greg KH wrote:
> > >I've applied the 2.6 patch to my trees and will send it on to Linus in a
> > >few days, thanks.
> >
> >
> > Speaking of PCI... are we gonna have to zap __devinit too? Another
> > option is to think of add-new-pci-ids-on-the-fly as a CONFIG_HOTPLUG
> > feature, which should(?) maintain the current __devinit semantics: no
> > re-probes.
>
> Yeah, that option does break almost all current usages of __devinit* in
> pci drivers today with CONFIG_HOTPLUG disabled :(
>
> So either making it a different config option, or just dropping
> __devinit* all together is fine with me, one of them needs to happen.
>
> Any preferences from anyone else?
Make it an option.
> > OTOH, __devinit already is a no-op for CONFIG_HOTPLUG cases (read: most
> > everybody), so I wonder if we care enough about __devinit anymore? I
> > used the same logic to support __devinitdata removal, after all.
>
> If we drop __devinit* then having CONFIG_HOTPLUG as a config option is
> almost pointless as it doesn't really affect much code at all. Any
> objections to just always enabling it?
>
> Anyone want to make up any before and after memory usages with
> CONFIG_HOTPLUG enabled and disabled to see if it's really as small as
> I'm thinking it is?
Well, here's some numbers I came up with on 2.6.0-test2 on PPC. I
picked 3 boards, EmbeddedPlanet 8260, IBM Spruce and IBM Walnut, made
the vmlinux (with an occasional fix here and there for other issues),
and came up with the following size changes (see arch/ppc/configs/ for
the base config). From HOTPLUG=n to HOTPLUG=y, and with __devinit stuff
put in it's own section I got:
EmbeddedPlanet 8260 (PPC8260, CONFIG_PCI==n):
.text: +2580
.exit.text: same
.rodata: +104
__ksymtab: same
.data: +352
.init.text (excluding __devinit): same.
.init.dev.text: 1692.
.init.data vs .init.data: 84
IBM Spruce (PPC750):
.text: +18528
.exit.text: -300
.rodata: +956
__ksymstab: +96
.data: +6816
.init.text (excluding __devinit): +132
.init.dev.text: 13032
IBM Walnut (PPC405):
.text: +17648
.exit.text: -300
.rodata: +1288
__ksymstab: +96
.data: +5312
.init.text (excluding __devinit): +128
.init.dev.text: 10508
The 8260 board is almost all 'custom' drivers inside of arch/ppc (long
story) and don't make much use of __init-style markups. The other
boards make use of more standard drivers, and have PCI. Since this is
-test2, and not current BK I'm not sure how correct the .data figures
are now, but it looks like CONFIG_HOTPLUG adds ~13kB to a kernel. So
how about stubbing things out if that makes it easier to code up hotplug
stuff (which can be important on some embedded devices too) so there's
choice?
--
Tom Rini
http://gate.crashing.org/~trini/