Skip to contentSkip to conversation

rtl8139.c: use PCI IO map

PATCH New Lucas Jin 5 participants 8 messages Oct 13, 2007 – Oct 16, 2007

lore
Share & tools
lore

Lucas Jin

author
#0 lore raw

PATCH 1/1 rtl8139.c: use PCI IO map

Signed-off-by Lucas Jin <[email protected]>
drivers/rtl8139.c renamed from drivers/rtl8139.c.orig +3 -3
@@ -104,8 +104,8 @@
 #undef DEBUG_RX
 
 #define currticks()	get_timer(0)
-#define bus_to_phys(a)	pci_mem_to_phys((pci_dev_t)dev->priv, a)
-#define phys_to_bus(a)	pci_phys_to_mem((pci_dev_t)dev->priv, a)
+#define bus_to_phys(a)	pci_io_to_phys((pci_dev_t)dev->priv, a)
+#define phys_to_bus(a)	pci_phys_to_io((pci_dev_t)dev->priv, a)
 
 /* Symbolic offsets to registers. */
 enum RTL8139_registers {

@@ -213,7 +213,7 @@
 		if ((devno = pci_find_devices(supported, idx++)) < 0)
 			break;
 
-		pci_read_config_dword(devno, PCI_BASE_ADDRESS_1, &iobase);
+		pci_read_config_dword(devno, PCI_BASE_ADDRESS_0, &iobase);
 		iobase &= ~0xf;
 
 		debug ("rtl8139: REALTEK RTL8139 @0x%x\n", iobase);

--------------
Lucas Jin

#1 lore raw

PATCH 1/1 rtl8139.c: use PCI IO map

drivers/rtl8139.c

Quoted 5 lines · In message <[email protected]> you wrote:
Signed-off-by Lucas Jin <[email protected]>
drivers/rtl8139.c renamed from drivers/rtl8139.c.orig +0 -0

Could you please explain which problem this patch is supposed to fix?

Best regards,

Wolfgang Denk

Signature · 7 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Nearly everyone is in favor of going  to  heaven  but  too  many  are
hoping  they'll  live  long  enough  to see an easing of the entrance
requirements. Never appeal to a man's "better nature." he  might  not
have one.
author
#2 lore raw

PATCH 1/1 rtl8139.c: use PCI IO map

Wolfgang Denk Wrote:

Quoted 8 lines

drivers/rtl8139.c

Quoted 5 lines · In message <[email protected]> you wrote:
Signed-off-by Lucas Jin <[email protected]>
drivers/rtl8139.c renamed from drivers/rtl8139.c.orig +0 -0

Could you please explain which problem this patch is supposed to fix?

The rtl8139 specification says the configuration registers can be accessed through PCI memory mapping or PCI IO mapping.

The u-boot driver uses PCI memory mapping, but it doesn't work, so I changed it to PCI IO mapping.

The driver of rtl8139 in Linux Kernel also uses PCI IO mapping to access the configuration registers.

Quoted 13 lines

Best regards,

Wolfgang Denk

Signature · 7 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Nearly everyone is in favor of going  to  heaven  but  too  many  are
hoping  they'll  live  long  enough  to see an easing of the entrance
requirements. Never appeal to a man's "better nature." he  might  not
have one.

------------------
Thanks
Lucas Jin

#3 lore raw

PATCH 1/1 rtl8139.c: use PCI IO map

Quoted 5 lines · Lucas Jin

Wolfgang Denk Wrote:

Quoted 3 lines
Quoted 2 lines · In message <[email protected]> you wrote:
Signed-off-by Lucas Jin <[email protected]>
Quoted 7 lines
Quoted 3 lines

drivers/rtl8139.c

Quoted 2 lines
drivers/rtl8139.c renamed from drivers/rtl8139.c.orig +0 -0

Could you please explain which problem this patch is supposed to fix?

The rtl8139 specification says the configuration registers can be accessed through PCI memory mapping or PCI IO mapping.

The u-boot driver uses PCI memory mapping, but it doesn't work, so I changed it to PCI IO mapping.

On my target RTL8139 or its variant works fine without such a change. Why do you think doesn't work? Could you elaborate please?

Quoted 1 line

The driver of rtl8139 in Linux Kernel also uses PCI IO mapping to access the configuration registers.

Do you mean CONFIG_8139TOO_PIO?

thanks,

Shinya

author
#4 lore raw

PATCH 1/1 rtl8139.c: use PCI IO map

Shinya Kuribayashi Wrote:

Quoted 10 lines
Quoted 9 lines · Lucas Jin

Wolfgang Denk Wrote:

Quoted 6 lines

drivers/rtl8139.c

Quoted 4 lines · In message <[email protected]> you wrote:
Signed-off-by Lucas Jin <[email protected]>
drivers/rtl8139.c renamed from drivers/rtl8139.c.orig +0 -0

Could you please explain which problem this patch is supposed to fix?

Quoted 6 lines
Quoted 3 lines

The rtl8139 specification says the configuration registers can be accessed through PCI memory mapping or PCI IO mapping.

The u-boot driver uses PCI memory mapping, but it doesn't work, so I changed it to PCI IO mapping.

On my target RTL8139 or its variant works fine without such a change. Why do you think doesn't work? Could you elaborate please?

When I used PCI memory mapping to access rtl8139 configuration registers, like MAC0-MAC05, the CPU paniced, as I described in the subject "a problem about rtl8139 driver on sandpoint8245board" I proposed Sep. 30th 2007.

After changing to PCI IO mapping, the problem was solved.

Quoted 4 lines
Quoted 2 lines

The driver of rtl8139 in Linux Kernel also uses PCI IO mapping to access the configuration registers.

Do you mean CONFIG_8139TOO_PIO?

I don't what you mean by CONFIG_8139TOO_PIO, there is not such a define in U-Boot.

Quoted 4 lines

thanks,

Shinya

------------------
Thanks
Lucas Jin

#5 lore raw

PATCH 1/1 rtl8139.c: use PCI IO map

Dear Lucas,

I used RTL8139 driver on MPC8241 board. It works fine. The followings are defined in the configuration file.

/* PCI memory */

#define CFG_IBAT2L      (0x80000000 | BATL_PP_10 | BATL_CACHEINHIBIT)
#define CFG_IBAT2U      (0x80000000 | BATU_BL_256M | BATU_VS | BATU_VP)

#define CFG_DBAT2L CFG_IBAT2L
#define CFG_DBAT2U CFG_IBAT2U

/* PCI Stuff */
#define CONFIG_PCI
#define CONFIG_PCI_PNP

#define CONFIG_NET_MULTI

#define CONFIG_RTL8139
/* for RTL8139 */
#define KSEG1ADDR(x) ({u32 _x=le32_to_cpu(*(u32 *)(x)); (&_x);})
#define _IO_BASE 0x00000000

The result of pci command are

# pci
Scanning PCI devices on bus 0
BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
_____________________________________________________________
00.00.00   0x1057     0x0006     Bridge device           0x00
00.0c.00   0x10ec     0x8139     Network controller      0x00
		:
# pci header 00.0c.00
   vendor ID =                   0x10ec
   device ID =                   0x8139
   command register =            0x0007
   status register =             0x0290
   revision ID =                 0x20
   class code =                  0x02 (Network controller)
   sub class code =              0x00
   programming interface =       0x00
   cache line =                  0x08
   latency time =                0x20
   header type =                 0x00
   BIST =                        0x00
   base address 0 =              0x00000001
   base address 1 =              0x80000000
   base address 2 =              0x00000000
   base address 3 =              0x00000000
   base address 4 =              0x00000000
   base address 5 =              0x00000000
   cardBus CIS pointer =         0x00000000
   sub system vendor ID =        0x11ec
   sub system ID =               0x8139
   expansion ROM base address =  0x00000000
   interrupt line =              0xff
   interrupt pin =               0x01
   min Grant =                   0x20
   max Latency =                 0x40

Masami Komiya

#7 lore raw

PATCH 1/1 rtl8139.c: use PCI IO map

In reply to Lucas Jin
Quoted 3 lines · Lucas Jin

When I used PCI memory mapping to access rtl8139 configuration registers, like MAC0-MAC05, the CPU paniced, as I described in the subject "a problem about rtl8139 driver on sandpoint8245board" I proposed Sep. 30th 2007.

Sounds more like a problem with PCI setup, than with the driver or the hardware.

-Scott

author
#6 lore raw

PATCH 1/1 rtl8139.c: use PCI IO map

In reply to Masami Komiya

Masami Komiya Wrote:

Yes, you are right, I didn't configurated my board correctly.

Quoted 8 lines

Dear Lucas,

I used RTL8139 driver on MPC8241 board. It works fine. The followings are defined in the configuration file.

/* PCI memory */

#define CFG_IBAT2L      (0x80000000 | BATL_PP_10 | BATL_CACHEINHIBIT)
#define CFG_IBAT2U      (0x80000000 | BATU_BL_256M | BATU_VS | BATU_VP)

The former developer of my project changed the two defines above to

#define CFG_IBAT2L (0x78000000 | BATL_PP_10 | BATL_CACHEINHIBIT)
#define CFG_IBAT2U (0x78000000 | BATU_BL_128K | BATU_VS | BATU_VP)

and I didn't realize that.

Quoted 55 lines

#define CFG_DBAT2L CFG_IBAT2L
#define CFG_DBAT2U CFG_IBAT2U

/* PCI Stuff */
#define CONFIG_PCI
#define CONFIG_PCI_PNP

#define CONFIG_NET_MULTI

#define CONFIG_RTL8139
/* for RTL8139 */
#define KSEG1ADDR(x) ({u32 _x=le32_to_cpu(*(u32 *)(x)); (&_x);})
#define _IO_BASE 0x00000000

The result of pci command are

# pci
Scanning PCI devices on bus 0
BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
_____________________________________________________________
00.00.00   0x1057     0x0006     Bridge device           0x00
00.0c.00   0x10ec     0x8139     Network controller      0x00
		:
# pci header 00.0c.00
  vendor ID =                   0x10ec
  device ID =                   0x8139
  command register =            0x0007
  status register =             0x0290
  revision ID =                 0x20
  class code =                  0x02 (Network controller)
  sub class code =              0x00
  programming interface =       0x00
  cache line =                  0x08
  latency time =                0x20
  header type =                 0x00
  BIST =                        0x00
  base address 0 =              0x00000001
  base address 1 =              0x80000000
  base address 2 =              0x00000000
  base address 3 =              0x00000000
  base address 4 =              0x00000000
  base address 5 =              0x00000000
  cardBus CIS pointer =         0x00000000
  sub system vendor ID =        0x11ec
  sub system ID =               0x8139
  expansion ROM base address =  0x00000000
  interrupt line =              0xff
  interrupt pin =               0x01
  min Grant =                   0x20
  max Latency =                 0x40

Masami Komiya

Quoted 9 lines

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

------------------
Thanks
Lucas Jin