pxa: make lubbock to use smc91x platform data
Subsystems (5)
PATCH 6/8 pxa: make lubbock to use smc91x platform data
--- arch/arm/mach-pxa/lubbock.c | 8 ++++++++ drivers/net/smc91x.h | 19 +------------------ 2 files changed, 9 insertions(+), 18 deletions(-)
arch/arm/mach-pxa/lubbock.c +8 -0
@@ -21,6 +21,7 @@#include <linux/interrupt.h> #include <linux/mtd/mtd.h> #include <linux/mtd/partitions.h> +#include <linux/smc91x.h> #include <linux/spi/spi.h> #include <linux/spi/ads7846.h>
@@ -335,11 +336,18 @@ static struct resource smc91x_resources[] = { }, }; +static struct smc91x_platdata lubbock_smc91x_info = { + .flags =SMC91X_USE_16BIT |SMC91X_NOWAIT |SMC91X_IO_SHIFT_2 , +}; +static struct platform_device smc91x_device = { .name ="smc91x" , .id =-1 , .num_resources =ARRAY_SIZE (smc91x_resources), .resource = smc91x_resources, + .dev = { + .platform_data = &lubbock_smc91x_info, + }, };static struct resource flash_resources[] = {
drivers/net/smc91x.h +1 -18
@@ -40,24 +40,7 @@* Define your architecture specific bus configuration parameters here. */ -#if defined(CONFIG_ARCH_LUBBOCK ) - -/* We can only do 16-bit reads and writes in the static memory space. */ -#define SMC_CAN_USE_8BIT 0 -#define SMC_CAN_USE_16BIT 1 -#define SMC_CAN_USE_32BIT 0 -#define SMC_NOWAIT 1 - -/* The first two address lines aren't connected... */ -#define SMC_IO_SHIFT 2 - -#define SMC_inw (a, r) readw((a) + (r)) -#define SMC_outw (v, a, r) writew(v, (a) + (r)) -#define SMC_insw (a, r, p, l) readsw((a) + (r), p, l) -#define SMC_outsw (a, r, p, l) writesw((a) + (r), p, l) -#define SMC_IRQ_FLAGS (-1)/* from resource */ - -#elif defined(CONFIG_BLACKFIN ) +#if defined(CONFIG_BLACKFIN )#define SMC_IRQ_FLAGS IRQF_TRIGGER_HIGH#define RPC_LSA_DEFAULT RPC_LED_100_10
Signature · 1 line
1.5.4.3
Quoted 2 lines · Eric Miao
Signed-off-by Eric Miao <[email protected]>
This (and 7/8 and 8/8) are a bit unfortunate. Maybe not as visible on Lubbock which has a SMC91C94 which can do 10mbps only, but the others will have poorer performances because of those patches. Did you compare performances, let's say with netperf, before and after those patches are applied?
I understand your goal of wanting to have a single kernel image that dynamically can select the right bus access method for all the concerned platforms. But I think you'll see that the runtime overhead has a significant impact on network throughput and CPU usage.
I think that some other solution should be explored such that when only one machine type (or machine types with the same bus config) is configured then the compile time optimizations should remain. Something based on the machine_is_lubbock(), machine_is_Mainstone(), and so on, which becomes constants with the right kernel configuration.
Nicolas
Quoted 15 lines · Nicolas Pitre
Quoted 1 line · Eric Miao
Signed-off-by Eric Miao <[email protected]>This (and 7/8 and 8/8) are a bit unfortunate. Maybe not as visible on Lubbock which has a SMC91C94 which can do 10mbps only, but the others will have poorer performances because of those patches. Did you compare performances, let's say with netperf, before and after those patches are applied?
I understand your goal of wanting to have a single kernel image that dynamically can select the right bus access method for all the concerned platforms. But I think you'll see that the runtime overhead has a significant impact on network throughput and CPU usage.
Quoted 6 lines
I think that some other solution should be explored such that when only one machine type (or machine types with the same bus config) is configured then the compile time optimizations should remain. Something based on the
machine_is_lubbock(),machine_is_Mainstone(), and so on, which becomes constants with the right kernel configuration.
OK, I know your concern. Let's see if we can work this out in another way.
Quoted 2 lines
Nicolas