Submitter | Myles Watson |
---|---|
Date | 2009-09-24 14:18:50 |
Message ID | <2831fecf0909240718t5bb56e05kd569c0f2efab4636@mail.gmail.com> |
Download | mbox | patch |
Permalink | /patch/293/ |
State | Accepted |
Headers | show |
Comments
mylesgw wrote: > +config HT_CHAIN_UNITID_BASE > + hex > + default 0x0 > + depends on BOARD_ASUS_M2V_MX_SE .. > +config SB_HT_CHAIN_UNITID_OFFSET_ONLY > +config SB_HT_CHAIN_ON_BUS0 > +config HT_CHAIN_END_UNITID_BASE .. Does it make sense to try to keep these out of board-specific Kconfigs? Are they typically always different on all boards? I'm thinking that it would be nice to have the board just set CONFIG_HYPERTRANSPORT and nothing else, and have the individual values included when that is set. But for that to make sense each board should not need to override most of these values. //Peter
On Thu, Sep 24, 2009 at 8:34 AM, Peter Stuge <peter@stuge.se> wrote: > mylesgw wrote: > > +config HT_CHAIN_UNITID_BASE > > + hex > > + default 0x0 > > + depends on BOARD_ASUS_M2V_MX_SE > .. > > +config SB_HT_CHAIN_UNITID_OFFSET_ONLY > > +config SB_HT_CHAIN_ON_BUS0 > > +config HT_CHAIN_END_UNITID_BASE > .. > > Does it make sense to try to keep these out of board-specific > Kconfigs? > I don't think they should be handled by Kconfig at all, but the current HT code needs them defined, and they are very board-specific (actually most of the time they are HT chain specific). I think the best way would be to specify each HT chain's values in the device tree. Thanks, Myles
mylesgw wrote: > > Does it make sense to try to keep these out of board-specific > > Kconfigs? > > I don't think they should be handled by Kconfig at all, but the > current HT code needs them defined, and they are very board-specific Ok. > I think the best way would be to specify each HT chain's values in > the device tree. I like that. Values "belonging" to the source code is kept in the device tree, Kconfig is closer to the user who builds the code. //Peter
Patch
Index: svn/src/Kconfig =================================================================== --- svn.orig/src/Kconfig +++ svn/src/Kconfig @@ -44,14 +44,6 @@ config PCI_BUS_SEGN_BITS bool default n -config HT_CHAIN_UNITID_BASE - hex - default 0x1 - -config HT_CHAIN_END_UNITID_BASE - hex - default 0x20 - config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID hex default 0 Index: svn/src/devices/Kconfig =================================================================== --- svn.orig/src/devices/Kconfig +++ svn/src/devices/Kconfig @@ -79,7 +79,7 @@ config PCI_64BIT_PREF_MEM config HYPERTRANSPORT_PLUGIN_SUPPORT bool - default y + default n config PCIX_PLUGIN_SUPPORT bool Index: svn/src/devices/Makefile.inc =================================================================== --- svn.orig/src/devices/Makefile.inc +++ svn/src/devices/Makefile.inc @@ -2,7 +2,9 @@ obj-y += device.o obj-y += root_device.o obj-y += device_util.o obj-y += pci_device.o -obj-y += hypertransport.o +ifdef CONFIG_HT_CHAIN_UNITID_BASE + obj-y += hypertransport.o +endif obj-y += pcix_device.o obj-y += pciexp_device.o obj-y += agp_device.o Index: svn/src/mainboard/asus/m2v-mx_se/Kconfig =================================================================== --- svn.orig/src/mainboard/asus/m2v-mx_se/Kconfig +++ svn/src/mainboard/asus/m2v-mx_se/Kconfig @@ -108,7 +108,6 @@ config HAVE_ACPI_TABLES default y depends on BOARD_ASUS_M2V_MX_SE - config LB_CKS_RANGE_END int default 122 @@ -119,3 +118,23 @@ config LB_CKS_LOC default 123 depends on BOARD_ASUS_M2V_MX_SE +config HT_CHAIN_UNITID_BASE + hex + default 0x0 + depends on BOARD_ASUS_M2V_MX_SE + +config SB_HT_CHAIN_UNITID_OFFSET_ONLY + hex + default 0x0 + depends on BOARD_ASUS_M2V_MX_SE + +config SB_HT_CHAIN_ON_BUS0 + hex + default 0x1 + depends on BOARD_ASUS_M2V_MX_SE + +config HT_CHAIN_END_UNITID_BASE + hex + default 0x20 + depends on BOARD_ASUS_M2V_MX_SE +
There's no reason for a board without HyperTransport to compile it in. This patch removes it (saving 1K after compression.) I would have liked to set HYPERTRANSPORT_PLUGIN_SUPPORT the same way, but couldn't figure out how. I don't think plugin support for HT makes sense... kbuildall tested. Signed-off-by: Myles Watson <mylesgw@gmail.com> Thanks, Myles