* [PATCH v5 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board
From: Heiko Schocher @ 2012-05-30 10:18 UTC (permalink / raw)
To: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/
Cc: Heiko Schocher, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
David Woodhouse, Ben Dooks, Wolfram Sang, Sekhar Nori,
Kevin Hilman, Wolfgang Denk, Sergei Shtylyov, Grant Likely
this patchserie add support for the davinci am1808 based
enbw_cmc board.
changes for v2:
Post this patchserie now as v2, as reworked in the
comments I got for the RFC serie.
changes for v3:
- Interrupt Controller:
- comment from Sergei Shtylyov:
- rename compatible" prop to "ti,cp_intc"
- cp_intc_init() is now also for the of case
the name of the init function (it calls the
"new" __cp_intc_init() function, which was
the "old" cp_intc_init()). Through this
rework the changes for OF is better visible.
As the OF case uses the irq_domain rework from
Grant Likely, maybe the none OF case can use
this also, but this should be tested on a hw ...
changes for v4:
- Interrupt Controller:
- split in two patches as Nori Sekhar suggested
one for the irq_domain change
one for DT support
- add comment from Grant Likely for the DT part:
remove if/else clause, not needed.
Make use of DT runtime configurable
The non OF case is not tested!
changes for v5:
- Interrupt Controller:
add comments from Sergei Shtylyov:
- s/intc/cp_intc in commit subject
- Codingstyle fixes
add comment from Grant Likely:
- rename compatible" prop to "ti,cp-intc"
- call irq_domain_add also in the non DT case
(was fixed in v4)
- switched from using d->irq to d->hwirq for the hardware
irq number in irq_chip hooks
- I2C DT support:
add comments from Grant Likely:
- do not change value of dev->dev->platform_data, instead
hold a copy in davinci_i2c_dev.
Got no comments to the following points, I noted in the
RFC series, so posting this patchseries with them:
- ARM: davinci: configure davinci aemif chipselects through OF
not moved to mfd, as mentioned in this discussion:
http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-td7059739.html
instead use a phandle in the DTS, so drivers which
uses the davinci aemif, can call davinci_aemif_setup_timing_of()
This is just thought as an RFC ... The enbw_cmc board
support not really need to setup this bus timings, as
they are setup in U-Boot ... but I want to post this,
as I think, it is a nice to have, and I am not really
sure, if this has to be a MFD device (If so, all bus
interfaces for other SoCs should be converted also to
MFD devices) ... as an example how this can be used
I add this to the davinci nand controller OF support
patch, in this patchserie.
- ARM: davinci: mux: add OF support
I want to get rid of the pin setup code in board code ...
This patch introduces a davinci_cfg_reg_of() function,
which davinci drivers can call, if they found a
"pinmux-handle", so used in the following drivers in
this patchserie:
drivers/net/ethernet/ti/davinci_emac
drivers/i2c/busses/i2c-davinci.c
drivers/mtd/nand/davinci_nand.c
This is removed for v4 serie, as Nori Sekhar suggested.
- post this board support with USB support, even though
USB is only working with the 10 ms "workaround", posted here:
http://comments.gmane.org/gmane.linux.usb.general/54505
I see this issue also on the AM1808 TMDXEXP1808L evalboard.
change for v4:
The 10 ms delay is no longer needed, see discussion here:
http://www.spinics.net/lists/linux-usb/msg64232.html
shows the way to go ...
- MMC and USB are not using OF support yet, ideas how to port
this are welcome. I need for USB and MMC board specific
callbacks, how to solve this with OF support?
Signed-off-by: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
Cc: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
Cc: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>
Cc: Wolfgang Denk <wd-ynQEQJNshbs@public.gmane.org>
Cc: Sergei Shtylyov <sshtylyov-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Heiko Schocher (7):
ARM: davinci, cp_intc: Add irq domain support
ARM: davinci, cp_intc: Add OF support for TI interrupt controller
ARM: davinci: configure davinci aemif chipselects through OF
ARM: davinci: net: davinci_emac: add OF support
ARM: davinci: i2c: add OF support
ARM: mtd: nand: davinci: add OF support for davinci nand controller
ARM: davinci: add support for the am1808 based enbw_cmc board
.../devicetree/bindings/arm/davinci/aemif.txt | 119 +++++++
.../devicetree/bindings/arm/davinci/i2c.txt | 31 ++
.../devicetree/bindings/arm/davinci/intc.txt | 27 ++
.../devicetree/bindings/arm/davinci/nand.txt | 72 ++++
.../devicetree/bindings/net/davinci_emac.txt | 41 +++
arch/arm/boot/dts/enbw_cmc.dts | 172 +++++++++
arch/arm/configs/enbw_cmc_defconfig | 123 +++++++
arch/arm/mach-davinci/Kconfig | 9 +
arch/arm/mach-davinci/Makefile | 1 +
arch/arm/mach-davinci/aemif.c | 86 +++++-
arch/arm/mach-davinci/board-enbw-cmc.c | 374 ++++++++++++++++++++
arch/arm/mach-davinci/cp_intc.c | 83 ++++-
arch/arm/mach-davinci/include/mach/aemif.h | 1 +
arch/arm/mach-davinci/include/mach/uncompress.h | 1 +
drivers/i2c/busses/i2c-davinci.c | 49 +++-
drivers/mtd/nand/davinci_nand.c | 80 ++++-
drivers/net/ethernet/ti/davinci_emac.c | 87 +++++-
17 files changed, 1335 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt
create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt
create mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt
create mode 100644 Documentation/devicetree/bindings/net/davinci_emac.txt
create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
create mode 100644 arch/arm/configs/enbw_cmc_defconfig
create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c
--
1.7.7.6
^ permalink raw reply
* [PATCH v5 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
From: Heiko Schocher @ 2012-05-30 10:19 UTC (permalink / raw)
To: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/
Cc: Heiko Schocher, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
David Woodhouse, Ben Dooks, Wolfram Sang, Sekhar Nori,
Kevin Hilman, Wolfgang Denk, Scott Wood, Sylwester Nawrocki
In-Reply-To: <1338373143-7467-1-git-send-email-hs-ynQEQJNshbs@public.gmane.org>
- AM1808 based board
- 64 MiB DDR ram
- 2 MiB Nor flash
- 128 MiB NAND flash
- use internal RTC
- I2C support
- hwmon lm75 support
- UBI/UBIFS support
- MMC support
- USB OTG support
Signed-off-by: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
Cc: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
Cc: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>
Cc: Wolfgang Denk <wd-ynQEQJNshbs@public.gmane.org>
Cc: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
- post this board support with USB support, even though
USB is only working with the 10 ms "workaround", posted here:
http://comments.gmane.org/gmane.linux.usb.general/54505
I see this issue also on the AM1808 TMDXEXP1808L evalboard.
- MMC and USB are not using OF support yet, ideas how to port
this are welcome. I need for USB and MMC boards board
specific callbacks, how to solve this with OF support?
- changes for v2:
- changes in the nand node due to comments from Scott Wood:
- add "ti,davinci-" prefix
- Dashes are preferred to underscores
- rename "nandflash" to "nand"
- introduce new "ti,davinci" specific properties for setting
up ecc_mode, ecc_bits, options and bbt options, instead
using linux defines
- changes for i2c due to comments from Sylwester Nawrocki:
- use "cell-index" instead "id"
- OF_DEV_AUXDATA in the machine code, instead pre-define
platform device name
- add comment from Grant Likely for i2c:
- removed "id" resp. "cell-index" completely
- fixed documentation
- use of_match_ptr()
- use devm_kzalloc() for allocating plattform data mem
- fixed a whitespace issue
- add net comments from Grant Likely:
- add prefix "ti,davinci-" to davinci specific property names
- remove version property
- use compatible name "ti,davinci-dm6460-emac"
- add comment from Grant Likely:
- rename compatible node
- do not use cell-index
- CONFIG_OF required for this board
TODO:
- create a generic board support file, as I got no
answer to my ping to grant, maybe this could be done
in a second step?
- changes for v3:
- add comments from Sergei Shtylyov:
- rename compatible" prop to "ti,cp_intc"
- cp_intc_init now used for Interrupt controller init
- changes for v4:
add comment from Nori Sekhar:
- rename davinci emac compatible property to "ti,davinci-dm6467-emac"
- remove "pinmux-handle" property as discussed here:
http://www.spinics.net/lists/arm-kernel/msg175701.html
with Nori Sekhar
- changes for v5:
add comments from Grant Likely:
- rename compatible" prop to "ti,cp-intc"
arch/arm/boot/dts/enbw_cmc.dts | 172 +++++++++++
arch/arm/configs/enbw_cmc_defconfig | 123 ++++++++
arch/arm/mach-davinci/Kconfig | 9 +
arch/arm/mach-davinci/Makefile | 1 +
arch/arm/mach-davinci/board-enbw-cmc.c | 374 +++++++++++++++++++++++
arch/arm/mach-davinci/include/mach/uncompress.h | 1 +
6 files changed, 680 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
create mode 100644 arch/arm/configs/enbw_cmc_defconfig
create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c
diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts
new file mode 100644
index 0000000..19c7559
--- /dev/null
+++ b/arch/arm/boot/dts/enbw_cmc.dts
@@ -0,0 +1,172 @@
+/*
+ * Device Tree for the EnBW CMC plattform
+ *
+ * Copyright 2011 DENX Software Engineering GmbH
+ * Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "EnBW CMC";
+ compatible = "enbw,cmc";
+
+ aliases {
+ ethernet0 = ð0;
+ };
+
+ arm {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0xfffee000 0x00020000>;
+ intc: interrupt-controller@1 {
+ compatible = "ti,cp-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ ti,intc-size = <101>;
+ reg = <0x0 0x2000>;
+ };
+ };
+ soc@1c00000 {
+ compatible = "ti,da850";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x01c00000 0x400000>;
+
+ serial0: serial@1c42000 {
+ compatible = "ti,da850", "ns16550a";
+ reg = <0x42000 0x100>;
+ clock-frequency = <150000000>;
+ reg-shift = <2>;
+ interrupts = <25>;
+ interrupt-parent = <&intc>;
+ };
+ serial1: serial@1d0c000 {
+ compatible = "ti,da850", "ns16550a";
+ reg = <0x10c000 0x100>;
+ clock-frequency = <150000000>;
+ reg-shift = <2>;
+ interrupts = <53>;
+ interrupt-parent = <&intc>;
+ };
+ serial2: serial@1d0d000 {
+ compatible = "ti,da850", "ns16550a";
+ reg = <0x10d000 0x100>;
+ clock-frequency = <150000000>;
+ reg-shift = <2>;
+ interrupts = <61>;
+ interrupt-parent = <&intc>;
+ };
+
+ eth0: emac@1e20000 {
+ compatible = "ti,davinci-dm6467-emac";
+ reg = <0x220000 0x4000>;
+ ti,davinci-ctrl-reg-offset = <0x3000>;
+ ti,davinci-ctrl-mod-reg-offset = <0x2000>;
+ ti,davinci-ctrl-ram-offset = <0>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <33
+ 34
+ 35
+ 36
+ >;
+ interrupt-parent = <&intc>;
+ };
+
+ i2c@1c22000 {
+ compatible = "ti,davinci-i2c";
+ reg = <0x22000 0x1000>;
+ clock-frequency = <100000>;
+ interrupts = <15>;
+ interrupt-parent = <&intc>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dtt@48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+ };
+ };
+ onchipram@8000000 {
+ compatible = "ti,davinci-onchipram";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x80000000 0x20000>;
+ };
+ aemif@60000000 {
+ compatible = "ti,davinci-aemif";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x68000000 0x80000>;
+ ranges = <2 0 0x60000000 0x02000000
+ 3 0 0x62000000 0x02000000
+ 4 0 0x64000000 0x02000000
+ 5 0 0x66000000 0x02000000
+ 6 0 0x68000000 0x02000000>;
+ cs2@68000000 {
+ compatible = "ti,davinci-cs";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* all timings in nanoseconds */
+ cs = <2>;
+ asize = <1>;
+ ta = <0>;
+ rhold = <7>;
+ rstrobe = <42>;
+ rsetup = <14>;
+ whold = <7>;
+ wstrobe = <42>;
+ wsetup = <14>;
+ ew = <0>;
+ ss = <0>;
+ };
+ flash@2,0 {
+ compatible = "cfi-flash";
+ reg = <2 0x0 0x400000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <2>;
+ device-width = <2>;
+ };
+ nand_cs: cs3@68000000 {
+ compatible = "ti,davinci-cs";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* all timings in nanoseconds */
+ cs = <3>;
+ asize = <0>;
+ ta = <0>;
+ rhold = <7>;
+ rstrobe = <42>;
+ rsetup = <7>;
+ whold = <7>;
+ wstrobe = <14>;
+ wsetup = <7>;
+ ew = <0>;
+ ss = <0>;
+ };
+ nand@3,0 {
+ compatible = "ti,davinci-nand";
+ reg = <3 0x0 0x807ff
+ 6 0x0 0x8000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,davinci-chipselect = <1>;
+ ti,davinci-mask-ale = <0>;
+ ti,davinci-mask-cle = <0>;
+ ti,davinci-mask-chipsel = <0>;
+ ti,davinci-ecc-mode = "hw";
+ ti,davinci-ecc-bits = <4>;
+ ti,davinci-nand-use-bbt;
+ timing-handle = <&nand_cs>;
+ };
+
+ };
+};
diff --git a/arch/arm/configs/enbw_cmc_defconfig b/arch/arm/configs/enbw_cmc_defconfig
new file mode 100644
index 0000000..9d98e7f
--- /dev/null
+++ b/arch/arm/configs/enbw_cmc_defconfig
@@ -0,0 +1,123 @@
+CONFIG_EXPERIMENTAL=y
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_EXPERT=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_DAVINCI=y
+CONFIG_ARCH_DAVINCI_DA850=y
+# CONFIG_MACH_DAVINCI_DA850_EVM is not set
+CONFIG_GPIO_PCA953X=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+CONFIG_USE_OF=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_LRO is not set
+CONFIG_IPV6=y
+CONFIG_NETFILTER=y
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+# CONFIG_FW_LOADER is not set
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_DAVINCI=y
+CONFIG_MTD_UBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=1
+CONFIG_BLK_DEV_RAM_SIZE=32768
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_NETDEVICES=y
+CONFIG_MII=y
+CONFIG_TI_DAVINCI_EMAC=y
+# CONFIG_WLAN is not set
+CONFIG_INPUT_POLLDEV=y
+# CONFIG_INPUT_MOUSEDEV is not set
+CONFIG_INPUT_EVDEV=y
+CONFIG_INPUT_EVBUG=y
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=3
+CONFIG_SERIAL_8250_RUNTIME_UARTS=3
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_HW_RANDOM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_DAVINCI=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_PCF857X=y
+CONFIG_SENSORS_LM75=y
+CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+CONFIG_DAVINCI_WATCHDOG=y
+# CONFIG_HID_SUPPORT is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_MUSB_HDRC=y
+CONFIG_USB_MUSB_DA8XX=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_UAS=y
+CONFIG_USB_LIBUSUAL=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_FUSB300=y
+CONFIG_USB_ETH=y
+CONFIG_MMC=y
+CONFIG_MMC_DAVINCI=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_OMAP=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+CONFIG_AUTOFS4_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_UBIFS_FS=y
+CONFIG_CRAMFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_DEBUG_FS=y
+CONFIG_TIMER_STATS=y
+CONFIG_DEBUG_RT_MUTEXES=y
+CONFIG_DEBUG_MUTEXES=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+# CONFIG_CRYPTO_HW is not set
+CONFIG_CRC_CCITT=m
+CONFIG_CRC_T10DIF=m
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 32d837d..4cb0469 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -202,6 +202,15 @@ config DA850_WL12XX
Say Y if you want to use a wl1271 expansion card connected to the
AM18x EVM.
+config MACH_ENBW_CMC
+ bool "EnBW Communication Module Compact"
+ default ARCH_DAVINCI_DA850
+ depends on ARCH_DAVINCI_DA850
+ select OF
+ help
+ Say Y here to select the EnBW Communication Module Compact
+ board.
+
config GPIO_PCA953X
default MACH_DAVINCI_DA850_EVM
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 2db78bd..12f3166 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_MACH_DAVINCI_DA850_EVM) += board-da850-evm.o
obj-$(CONFIG_MACH_TNETV107X) += board-tnetv107x-evm.o
obj-$(CONFIG_MACH_MITYOMAPL138) += board-mityomapl138.o
obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD) += board-omapl138-hawk.o
+obj-$(CONFIG_MACH_ENBW_CMC) += board-enbw-cmc.o
# Power Management
obj-$(CONFIG_CPU_FREQ) += cpufreq.o
diff --git a/arch/arm/mach-davinci/board-enbw-cmc.c b/arch/arm/mach-davinci/board-enbw-cmc.c
new file mode 100644
index 0000000..fcec14f
--- /dev/null
+++ b/arch/arm/mach-davinci/board-enbw-cmc.c
@@ -0,0 +1,374 @@
+/*
+ * EnBW Communication Module Compact board
+ * Copyright 2011 DENX Software Engineering GmbH
+ * Author: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
+ *
+ * based on:
+ * TI DA850/OMAP-L138 EVM board
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Derived from: arch/arm/mach-davinci/board-da850-evm.c
+ * Original Copyrights follow:
+ *
+ * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/console.h>
+#include <linux/gpio.h>
+#include <linux/gpio_keys.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/physmap.h>
+#include <linux/of.h>
+#include <linux/of_net.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/phy.h>
+#include <linux/phy_fixed.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/aemif.h>
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+#include <mach/mux.h>
+#include <mach/nand.h>
+#include <mach/spi.h>
+
+#define ENBW_CMC_MMCSD_CD_PIN GPIO_TO_PIN(3, 13)
+
+/*
+ * USB1 VBUS is controlled by GPIO7[12], over-current is reported on GPIO7[8].
+ */
+#define DA850_USB_VBUS_PIN GPIO_TO_PIN(7, 12)
+#define ON_BD_USB_OVC GPIO_TO_PIN(7, 8)
+
+#if defined(CONFIG_USB_OHCI_HCD)
+static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id);
+static da8xx_ocic_handler_t enbw_cmc_usb_ocic_handler;
+
+static int enbw_cmc_usb_set_power(unsigned port, int on)
+{
+ gpio_set_value(DA850_USB_VBUS_PIN, on);
+ return 0;
+}
+
+static int enbw_cmc_usb_get_power(unsigned port)
+{
+ return gpio_get_value(DA850_USB_VBUS_PIN);
+}
+
+static int enbw_cmc_usb_get_oci(unsigned port)
+{
+ return !gpio_get_value(ON_BD_USB_OVC);
+}
+
+static irqreturn_t enbw_cmc_usb_ocic_irq(int, void *);
+
+static int enbw_cmc_usb_ocic_notify(da8xx_ocic_handler_t handler)
+{
+ int irq = gpio_to_irq(ON_BD_USB_OVC);
+ int error = 0;
+
+ if (handler != NULL) {
+ enbw_cmc_usb_ocic_handler = handler;
+
+ error = request_irq(irq, enbw_cmc_usb_ocic_irq,
+ IRQF_DISABLED | IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING,
+ "OHCI over-current indicator", NULL);
+ if (error)
+ pr_err("%s: could not request IRQ to watch "
+ "over-current indicator changes\n", __func__);
+ } else {
+ free_irq(irq, NULL);
+ }
+ return error;
+}
+
+static struct da8xx_ohci_root_hub enbw_cmc_usb11_pdata = {
+ .set_power = enbw_cmc_usb_set_power,
+ .get_power = enbw_cmc_usb_get_power,
+ .get_oci = enbw_cmc_usb_get_oci,
+ .ocic_notify = enbw_cmc_usb_ocic_notify,
+ .potpgt = (10 + 1) / 2, /* 10 ms max */
+};
+
+static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id)
+{
+ enbw_cmc_usb_ocic_handler(&enbw_cmc_usb11_pdata, 1);
+ return IRQ_HANDLED;
+}
+#endif
+
+static __init void enbw_cmc_usb_init(void)
+{
+ int ret;
+ u32 cfgchip2;
+
+ /* Set up USB clock/mode in the CFGCHIP2 register. */
+ cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ /* USB2.0 PHY reference clock is AUXCLK with 24MHz */
+ cfgchip2 &= ~CFGCHIP2_REFFREQ;
+ cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ;
+
+ /*
+ * Select internal reference clock for USB 2.0 PHY
+ * and use it as a clock source for USB 1.1 PHY
+ * (this is the default setting anyway).
+ */
+ cfgchip2 &= ~CFGCHIP2_USB1PHYCLKMUX;
+ cfgchip2 |= CFGCHIP2_USB2PHYCLKMUX;
+
+ cfgchip2 &= ~CFGCHIP2_OTGMODE;
+ cfgchip2 |= CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
+
+ __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+ /*
+ * SP2525A @ 5V supplies 500mA,
+ * with the power on to power good time of 10 ms.
+ */
+ ret = da8xx_register_usb20(500, 10);
+ if (ret)
+ pr_warning("%s: USB 2.0 registration failed: %d\n",
+ __func__, ret);
+
+#if defined(CONFIG_USB_OHCI_HCD)
+ ret = gpio_request_one(DA850_USB_VBUS_PIN,
+ GPIOF_DIR_OUT, "USB 1.1 VBUS");
+ if (ret < 0) {
+ pr_err("%s: failed to request GPIO for USB 1.1 port "
+ "power control: %d\n", __func__, ret);
+ return;
+ }
+ gpio_direction_input(DA850_USB_VBUS_PIN);
+
+ ret = gpio_request(ON_BD_USB_OVC, "ON_BD_USB_OVC");
+ if (ret) {
+ printk(KERN_ERR "%s: failed to request GPIO for USB 1.1 port "
+ "over-current indicator: %d\n", __func__, ret);
+ gpio_free(DA850_USB_VBUS_PIN);
+ return;
+ }
+ gpio_direction_input(ON_BD_USB_OVC);
+
+ ret = da8xx_register_usb11(&enbw_cmc_usb11_pdata);
+ if (ret) {
+ pr_warning("%s: USB 1.1 registration failed: %d\n",
+ __func__, ret);
+ gpio_free(ON_BD_USB_OVC);
+ gpio_free(DA850_USB_VBUS_PIN);
+ }
+#endif
+
+ return;
+}
+
+static int enbw_cmc_mmc_get_ro(int index)
+{
+ return 0;
+}
+
+static int enbw_cmc_mmc_get_cd(int index)
+{
+ return gpio_get_value(ENBW_CMC_MMCSD_CD_PIN) ? 1 : 0;
+}
+
+static struct davinci_mmc_config enbw_cmc_mmc_config = {
+ .get_ro = enbw_cmc_mmc_get_ro,
+ .get_cd = enbw_cmc_mmc_get_cd,
+ .wires = 4,
+ .max_freq = 50000000,
+ .caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
+ .version = MMC_CTLR_VERSION_2,
+};
+
+static int __init enbw_cmc_config_emac(void)
+{
+ void __iomem *cfg_chip3_base;
+ u32 val;
+ struct davinci_soc_info *soc_info = &davinci_soc_info;
+
+ if (!machine_is_enbw_cmc())
+ return 0;
+
+ cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
+ val = __raw_readl(cfg_chip3_base);
+ val &= ~BIT(8);
+ pr_info("EMAC: MII PHY configured, RMII PHY will not be"
+ " functional\n");
+
+ /* configure the CFGCHIP3 register for MII */
+ __raw_writel(val, cfg_chip3_base);
+
+ /* use complete info from OF */
+ soc_info->emac_pdata = NULL;
+
+ return 0;
+}
+device_initcall(enbw_cmc_config_emac);
+
+static const s16 da850_dma0_rsv_chans[][2] = {
+ /* (offset, number) */
+ {-1, -1}
+};
+
+static const s16 da850_dma0_rsv_slots[][2] = {
+ /* (offset, number) */
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_chans[][2] = {
+ /* (offset, number) */
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_slots[][2] = {
+ /* (offset, number) */
+ {-1, -1}
+};
+
+static struct edma_rsv_info da850_edma_cc0_rsv = {
+ .rsv_chans = da850_dma0_rsv_chans,
+ .rsv_slots = da850_dma0_rsv_slots,
+};
+
+static struct edma_rsv_info da850_edma_cc1_rsv = {
+ .rsv_chans = da850_dma1_rsv_chans,
+ .rsv_slots = da850_dma1_rsv_slots,
+};
+
+static struct edma_rsv_info *da850_edma_rsv[2] = {
+ &da850_edma_cc0_rsv,
+ &da850_edma_cc1_rsv,
+};
+
+#ifdef CONFIG_CPU_FREQ
+static __init int da850_evm_init_cpufreq(void)
+{
+ switch (system_rev & 0xF) {
+ case 3:
+ da850_max_speed = 456000;
+ break;
+ case 2:
+ da850_max_speed = 408000;
+ break;
+ case 1:
+ da850_max_speed = 372000;
+ break;
+ }
+
+ return da850_register_cpufreq("pll0_sysclk3");
+}
+#else
+static __init int da850_evm_init_cpufreq(void) { return 0; }
+#endif
+
+struct of_dev_auxdata enbw_cmc_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "ti,davinci-wdt", NULL),
+ OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
+ OF_DEV_AUXDATA("ti,davinci-i2c", 0x01e28000, "i2c_davinci.2", NULL),
+ OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e20000, "davinci_emac.1",
+ NULL),
+ {}
+};
+
+const struct of_device_id enbw_cmc_bus_match_table[] = {
+ { .compatible = "simple-bus", },
+ { .compatible = "ti,da850", },
+ { .compatible = "ti,davinci-onchipram", },
+ { .compatible = "ti,davinci-aemif", },
+ {} /* Empty terminated list */
+};
+
+static __init void enbw_cmc_init(void)
+{
+ int ret;
+
+ of_platform_populate(NULL, enbw_cmc_bus_match_table,
+ enbw_cmc_auxdata_lookup, NULL);
+
+ ret = da8xx_register_watchdog();
+ if (ret)
+ pr_warning("enbw_cmc_init: watchdog registration failed: %d\n",
+ ret);
+
+ ret = da850_register_edma(da850_edma_rsv);
+ if (ret)
+ pr_warning("enbw_cmc_init: edma registration failed: %d\n",
+ ret);
+
+ /*
+ * shut down uart 0 this port is not used on the board
+ */
+ __raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
+
+ ret = da8xx_register_rtc();
+ if (ret)
+ pr_warning("enbw_cmc_init: rtc setup failed: %d\n", ret);
+
+ ret = da850_evm_init_cpufreq();
+ if (ret)
+ pr_warning("enbw_cmc_init: cpufreq registration failed: %d\n",
+ ret);
+
+ ret = da8xx_register_cpuidle();
+ if (ret)
+ pr_warning("enbw_cmc_init: cpuidle registration failed: %d\n",
+ ret);
+
+ ret = gpio_request(ENBW_CMC_MMCSD_CD_PIN, "MMC CD\n");
+ if (ret)
+ pr_warning("enbw_cmc_init: can not open GPIO %d\n",
+ ENBW_CMC_MMCSD_CD_PIN);
+ gpio_direction_input(ENBW_CMC_MMCSD_CD_PIN);
+
+ ret = da850_register_mmcsd1(&enbw_cmc_mmc_config);
+ if (ret)
+ pr_warning("enbw_cmc_init: mmcsd1 registration failed:"
+ " %d\n", ret);
+
+ enbw_cmc_usb_init();
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init enbw_cmc_console_init(void)
+{
+ if (!machine_is_enbw_cmc())
+ return 0;
+
+ return add_preferred_console("ttyS", 2, "115200");
+}
+console_initcall(enbw_cmc_console_init);
+#endif
+
+static void __init enbw_cmc_map_io(void)
+{
+ da850_init();
+}
+
+static const char *enbw_cmc_board_compat[] __initconst = {
+ "enbw,cmc",
+ NULL
+};
+
+MACHINE_START(ENBW_CMC, "EnBW CMC")
+ .map_io = enbw_cmc_map_io,
+ .init_irq = cp_intc_init,
+ .timer = &davinci_timer,
+ .init_machine = enbw_cmc_init,
+ .dt_compat = enbw_cmc_board_compat,
+ .dma_zone_size = SZ_128M,
+ .restart = da8xx_restart,
+MACHINE_END
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index da2fb2c..6119543 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -98,6 +98,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
DEBUG_LL_DA8XX(davinci_da850_evm, 2);
DEBUG_LL_DA8XX(mityomapl138, 1);
DEBUG_LL_DA8XX(omapl138_hawkboard, 2);
+ DEBUG_LL_DA8XX(enbw_cmc, 2);
/* TNETV107x boards */
DEBUG_LL_TNETV107X(tnetv107x, 1);
--
1.7.7.6
^ permalink raw reply related
* [PATCH v5 4/7] ARM: davinci: net: davinci_emac: add OF support
From: Heiko Schocher @ 2012-05-30 10:19 UTC (permalink / raw)
To: davinci-linux-open-source
Cc: Heiko Schocher, linux-arm-kernel, devicetree-discuss, netdev,
Grant Likely, Sekhar Nori, Wolfgang Denk, Anatoly Sivov
In-Reply-To: <1338373143-7467-1-git-send-email-hs@denx.de>
add of support for the davinci_emac driver.
Signed-off-by: Heiko Schocher <hs@denx.de>
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: netdev@vger.kernel.org
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Anatoly Sivov <mm05@mail.ru>
---
- changes for v2:
- add comment from Anatoly Sivov
- fix typo in davinci_emac.txt
- add comment from Grant Likely:
- add prefix "ti,davinci-" to davinci specific property names
- remove version property
- use compatible name "ti,davinci-dm6460-emac"
- use devm_kzalloc()
- use of_match_ptr()
- document all new properties
- remove of_address_to_resource() and do not overwrite
resource table
- whitespace fixes
- remove hw_ram_addr as it is not used in current
board code
- no changes for v3
- changes for v4:
add comments from Nori Sekhar:
- move devictree documentation to:
Documentation/devicetree/bindings/net/davinci_emac.txt
- fix typo in it
- rename compatible property to "ti,davinci-dm6467-emac"
- remove pinmux-handle
- set version directly in pdata->version
- no changes for v5
.../devicetree/bindings/net/davinci_emac.txt | 41 +++++++++
drivers/net/ethernet/ti/davinci_emac.c | 87 +++++++++++++++++++-
2 files changed, 127 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/davinci_emac.txt
diff --git a/Documentation/devicetree/bindings/net/davinci_emac.txt b/Documentation/devicetree/bindings/net/davinci_emac.txt
new file mode 100644
index 0000000..48b259e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -0,0 +1,41 @@
+* Texas Instruments Davinci EMAC
+
+This file provides information, what the device node
+for the davinci_emac interface contains.
+
+Required properties:
+- compatible: "ti,davinci-dm6467-emac";
+- reg: Offset and length of the register set for the device
+- ti,davinci-ctrl-reg-offset: offset to control register
+- ti,davinci-ctrl-mod-reg-offset: offset to control module register
+- ti,davinci-ctrl-ram-offset: offset to control module ram
+- ti,davinci-ctrl-ram-size: size of control module ram
+- ti,davinci-rmii-en: use RMII
+- ti,davinci-no-bd-ram: has the emac controller BD RAM
+- phy-handle: Contains a phandle to an Ethernet PHY.
+ if not, davinci_emac driver defaults to 100/FULL
+- interrupts: interrupt mapping for the davinci emac interrupts sources:
+ 4 sources: <Receive Threshold Interrupt
+ Receive Interrupt
+ Transmit Interrupt
+ Miscellaneous Interrupt>
+
+Optional properties:
+- local-mac-address : 6 bytes, mac address
+
+Example (enbw_cmc board):
+ eth0: emac@1e20000 {
+ compatible = "ti,davinci-dm6467-emac";
+ reg = <0x220000 0x4000>;
+ ti,davinci-ctrl-reg-offset = <0x3000>;
+ ti,davinci-ctrl-mod-reg-offset = <0x2000>;
+ ti,davinci-ctrl-ram-offset = <0>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <33
+ 34
+ 35
+ 36
+ >;
+ interrupt-parent = <&intc>;
+ };
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 4da93a5..645618d 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -58,6 +58,12 @@
#include <linux/io.h>
#include <linux/uaccess.h>
#include <linux/davinci_emac.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_net.h>
+
+#include <mach/mux.h>
#include <asm/irq.h>
#include <asm/page.h>
@@ -339,6 +345,9 @@ struct emac_priv {
u32 rx_addr_type;
atomic_t cur_tx;
const char *phy_id;
+#ifdef CONFIG_OF
+ struct device_node *phy_node;
+#endif
struct phy_device *phydev;
spinlock_t lock;
/*platform specific members*/
@@ -1762,6 +1771,75 @@ static const struct net_device_ops emac_netdev_ops = {
#endif
};
+#ifdef CONFIG_OF
+static struct emac_platform_data
+ *davinci_emac_of_get_pdata(struct platform_device *pdev,
+ struct emac_priv *priv)
+{
+ struct device_node *np;
+ struct emac_platform_data *pdata = NULL;
+ const u8 *mac_addr;
+ u32 data;
+ int ret;
+
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto nodata;
+ }
+
+ np = pdev->dev.of_node;
+ if (!np)
+ goto nodata;
+ else
+ pdata->version = EMAC_VERSION_2;
+
+ mac_addr = of_get_mac_address(np);
+ if (mac_addr)
+ memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
+
+ ret = of_property_read_u32(np, "ti,davinci-ctrl-reg-offset", &data);
+ if (!ret)
+ pdata->ctrl_reg_offset = data;
+
+ ret = of_property_read_u32(np, "ti,davinci-ctrl-mod-reg-offset",
+ &data);
+ if (!ret)
+ pdata->ctrl_mod_reg_offset = data;
+
+ ret = of_property_read_u32(np, "ti,davinci-ctrl-ram-offset", &data);
+ if (!ret)
+ pdata->ctrl_ram_offset = data;
+
+ ret = of_property_read_u32(np, "ti,davinci-ctrl-ram-size", &data);
+ if (!ret)
+ pdata->ctrl_ram_size = data;
+
+ ret = of_property_read_u32(np, "ti,davinci-rmii-en", &data);
+ if (!ret)
+ pdata->rmii_en = data;
+
+ ret = of_property_read_u32(np, "ti,davinci-no-bd-ram", &data);
+ if (!ret)
+ pdata->no_bd_ram = data;
+
+ priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
+ if (!priv->phy_node)
+ pdata->phy_id = "";
+
+ pdev->dev.platform_data = pdata;
+nodata:
+ return pdata;
+}
+#else
+static struct emac_platform_data
+ *davinci_emac_of_get_pdata(struct platform_device *pdev,
+ struct emac_priv *priv)
+{
+ return pdev->dev.platform_data;
+}
+#endif
/**
* davinci_emac_probe: EMAC device probe
* @pdev: The DaVinci EMAC device that we are removing
@@ -1804,7 +1882,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
spin_lock_init(&priv->lock);
- pdata = pdev->dev.platform_data;
+ pdata = davinci_emac_of_get_pdata(pdev, priv);
if (!pdata) {
dev_err(&pdev->dev, "no platform data\n");
rc = -ENODEV;
@@ -2015,6 +2093,12 @@ static const struct dev_pm_ops davinci_emac_pm_ops = {
.resume = davinci_emac_resume,
};
+static const struct of_device_id davinci_emac_of_match[] = {
+ {.compatible = "ti,davinci-dm6467-emac", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, davinci_emac_of_match);
+
/**
* davinci_emac_driver: EMAC platform driver structure
*/
@@ -2023,6 +2107,7 @@ static struct platform_driver davinci_emac_driver = {
.name = "davinci_emac",
.owner = THIS_MODULE,
.pm = &davinci_emac_pm_ops,
+ .of_match_table = of_match_ptr(davinci_emac_of_match),
},
.probe = davinci_emac_probe,
.remove = __devexit_p(davinci_emac_remove),
--
1.7.7.6
^ permalink raw reply related
* RE: Difficulties to get 1Gbps on be2net ethernet card
From: Eric Dumazet @ 2012-05-30 10:30 UTC (permalink / raw)
To: Sathya.Perla; +Cc: jhautbois, netdev
In-Reply-To: <3367B80B08154D42A3B2BC708B5D41F647C678B73F@EXMAIL.ad.emulex.com>
On Wed, 2012-05-30 at 03:04 -0700, Sathya.Perla@Emulex.Com wrote:
> >-----Original Message-----
> >From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> >Behalf Of Jean-Michel Hautbois
> >
> >2012/5/30 Jean-Michel Hautbois <jhautbois@gmail.com>:
> >
> >I used vmstat in order to see the differences between the two kernels.
> >The main difference is the number of interrupts per second.
> >I have an average of 87500 on 3.2 and 7500 on 2.6, 10 times lower !
> >I suspect the be2net driver to be the main cause, and I checkes the
> >/proc/interrupts file in order to be sure.
> >
> >I have for eth1-tx on 2.6.26 about 2200 interrupts per second and 23000 on 3.2.
> >BTW, it is named eth1-q0 on 3.2 (and tx and rx are the same IRQ)
> >whereas there is eth1-rx0 and eth1-tx on 2.6.26.
>
> Yes, there is an issue with be2net interrupt mitigation in the recent code with
> RX and TX on the same Evt-Q (commit 10ef9ab4). The high interrupt rate happens when a TX blast is
> done while RX is relatively silent on a queue pair. Interrupt rate due to TX completions is not being
> mitigated.
>
> I have a fix and will send it out soon..
I also have a benet fix for non GRO :
Pulling 64 bytes in skb head is too much for TCP IPv4 with no
timestamps, as this makes splice() or TCP coalescing less effective.
(Having tcp payload in linear part of the skb disables various optims)
Could you please test it ?
Thanks
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 08efd30..f446b11 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1202,15 +1202,19 @@ static void skb_fill_rx_data(struct be_rx_obj *rxo, struct sk_buff *skb,
/* Copy data in the first descriptor of this completion */
curr_frag_len = min(rxcp->pkt_size, rx_frag_size);
- /* Copy the header portion into skb_data */
- hdr_len = min(BE_HDR_LEN, curr_frag_len);
+ /* If frame is small enough to fit in skb->head, pull it completely.
+ * If not, only pull ethernet header so that splice() or TCP coalesce
+ * are more efficient.
+ */
+ hdr_len = (curr_frag_len <= skb_tailroom(skb)) ?
+ curr_frag_len : ETH_HLEN;
+
memcpy(skb->data, start, hdr_len);
skb->len = curr_frag_len;
- if (curr_frag_len <= BE_HDR_LEN) { /* tiny packet */
+ skb->tail += hdr_len;
+ if (hdr_len == curr_frag_len) { /* tiny packet */
/* Complete packet has now been moved to data */
put_page(page_info->page);
- skb->data_len = 0;
- skb->tail += curr_frag_len;
} else {
skb_shinfo(skb)->nr_frags = 1;
skb_frag_set_page(skb, 0, page_info->page);
@@ -1219,7 +1223,6 @@ static void skb_fill_rx_data(struct be_rx_obj *rxo, struct sk_buff *skb,
skb_frag_size_set(&skb_shinfo(skb)->frags[0], curr_frag_len - hdr_len);
skb->data_len = curr_frag_len - hdr_len;
skb->truesize += rx_frag_size;
- skb->tail += hdr_len;
}
page_info->page = NULL;
^ permalink raw reply related
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Hiroaki SHIMODA @ 2012-05-30 10:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tom Herbert, Denys Fedoryshchenko, netdev, e1000-devel,
jeffrey.t.kirsher, jesse.brandeburg, davem
In-Reply-To: <1338367231.2760.125.camel@edumazet-glaptop>
On Wed, 30 May 2012 10:40:31 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2012-05-30 at 09:06 +0900, Hiroaki SHIMODA wrote:
> > While reading the bql code, I have some questions.
> >
> > 1) dql_completed() and dql_queued() can be called concurrently,
> > so dql->num_queued could change while processing
> > dql_completed().
> > Is it intentional to refer num_queued from "dql->" each time ?
> >
>
> not sure it can have problems, but doing the read once is indeed a good
> plan.
>
> > 2) From the comment in the code
> > * - The queue was over-limit in the previous interval and
> > * when enqueuing it was possible that all queued data
> > * had been consumed.
> >
> > and
> >
> > * Queue was not starved, check if the limit can be decreased.
> > * A decrease is only considered if the queue has been busy in
> > * the whole interval (the check above).
> >
> > the calculation of all_prev_completed should take into account
> > completed == dql->prev_num_queued case ?
> > On current implementation, limit shrinks easily and some NIC
> > hit TX stalls.
> > To mitigate TX stalls, should we fix all_prev_completed rather
> > than individual driver ?
> >
>
> Not sure what you mean
While examining ping problem, below pattern is often observed.
TIME
dql_queued() dql_completed() |
a) initial state |
|
b) X bytes queued V
c) Y bytes queued
d) X bytes completed
e) Z bytes queued
f) Y bytes completed
a) dql->limit has already some value and there is no in-flight packet.
b) X bytes queued.
c) Y bytes queued and excess limit.
d) X bytes completed and dql->prev_ovlimit is set and also
dql->prev_num_queued is set Y.
e) Z bytes queued.
f) Y bytes completed. inprogress and prev_inprogress are true.
At f), if I read the comment correctly, all_prev_completed becomes
true and limit should be increased. But POSDIFF() ignores
(A == B) case, so limit is decreased.
I thought excess limit decrement induces the TX stalls.
>
> > 3) limit calculation fails to consider integer wrap around in
> > one place ?
> >
>
> Yes
>
> > Here is the patch what I meant.
> >
> > diff --git a/lib/dynamic_queue_limits.c b/lib/dynamic_queue_limits.c
> > @@ -11,22 +11,27 @@
> > #include <linux/dynamic_queue_limits.h>
> >
> > #define POSDIFF(A, B) ((A) > (B) ? (A) - (B) : 0)
> > +#define POSDIFFI(A, B) ((int)((A) - (B)) > 0 ? (A) - (B) : 0)
> > +#define AFTER_EQ(A, B) ((int)((A) - (B)) >= 0)
> >
> > /* Records completed count and recalculates the queue limit */
> > void dql_completed(struct dql *dql, unsigned int count)
> > {
> > unsigned int inprogress, prev_inprogress, limit;
> > - unsigned int ovlimit, all_prev_completed, completed;
> > + unsigned int ovlimit, completed, num_queued;
> > + bool all_prev_completed;
> > +
> > + num_queued = dql->num_queued;
>
>
> I suggest :
>
> num_queued = ACCESS_ONCE(dql->num_queued);
>
> Or else compiler is free to do whatever he wants.
Thank you for your suggestion.
^ permalink raw reply
* RE: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: David Laight @ 2012-05-30 10:52 UTC (permalink / raw)
To: Eric Dumazet, Hiroaki SHIMODA
Cc: Tom Herbert, Denys Fedoryshchenko, netdev, e1000-devel,
jeffrey.t.kirsher, jesse.brandeburg, davem
In-Reply-To: <1338367231.2760.125.camel@edumazet-glaptop>
> > + num_queued = dql->num_queued;
>
>
> I suggest :
>
> num_queued = ACCESS_ONCE(dql->num_queued);
>
> Or else compiler is free to do whatever he wants.
Or make the structure member volatile, then the
compiler can only read it once.
Probably worth while if the value is expected to
be read like that.
David
^ permalink raw reply
* RE: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-30 11:04 UTC (permalink / raw)
To: David Laight
Cc: Hiroaki SHIMODA, Tom Herbert, Denys Fedoryshchenko, netdev,
e1000-devel, jeffrey.t.kirsher, jesse.brandeburg, davem
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6F31@saturn3.aculab.com>
On Wed, 2012-05-30 at 11:52 +0100, David Laight wrote:
> > > + num_queued = dql->num_queued;
> >
> >
> > I suggest :
> >
> > num_queued = ACCESS_ONCE(dql->num_queued);
> >
> > Or else compiler is free to do whatever he wants.
>
> Or make the structure member volatile, then the
> compiler can only read it once.
No. Compiler can read it several times. Really.
> Probably worth while if the value is expected to
> be read like that.
Please don't use lazy volatile.
Unless you really want Linus flames (and ours)
ACCESS_ONCE() is much cleaner.
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-30 11:08 UTC (permalink / raw)
To: Hiroaki SHIMODA
Cc: Tom Herbert, Denys Fedoryshchenko, netdev, e1000-devel,
jeffrey.t.kirsher, jesse.brandeburg, davem
In-Reply-To: <20120530194355.92bf5d51.shimoda.hiroaki@gmail.com>
On Wed, 2012-05-30 at 19:43 +0900, Hiroaki SHIMODA wrote:
> While examining ping problem, below pattern is often observed.
>
> TIME
> dql_queued() dql_completed() |
> a) initial state |
> |
> b) X bytes queued V
>
> c) Y bytes queued
> d) X bytes completed
> e) Z bytes queued
> f) Y bytes completed
>
> a) dql->limit has already some value and there is no in-flight packet.
> b) X bytes queued.
> c) Y bytes queued and excess limit.
> d) X bytes completed and dql->prev_ovlimit is set and also
> dql->prev_num_queued is set Y.
> e) Z bytes queued.
> f) Y bytes completed. inprogress and prev_inprogress are true.
>
> At f), if I read the comment correctly, all_prev_completed becomes
> true and limit should be increased. But POSDIFF() ignores
> (A == B) case, so limit is decreased.
Which POSDIFF(), because there are many ;)
By the way, given complexity of this I suggest you split your ideas in
independent patches.
Mabe we should change all POSDIFF(), not selected ones.
#define POSDIFF(A, B) ((int)((A) - (B)) > 0 ? (A) - (B) : 0)
^ permalink raw reply
* RE: Difficulties to get 1Gbps on be2net ethernet card
From: Sathya.Perla @ 2012-05-30 11:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: jhautbois, netdev
In-Reply-To: <1338373857.2760.150.camel@edumazet-glaptop>
>-----Original Message-----
>From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>
>I also have a benet fix for non GRO :
>
>Pulling 64 bytes in skb head is too much for TCP IPv4 with no
>timestamps, as this makes splice() or TCP coalescing less effective.
>
>(Having tcp payload in linear part of the skb disables various optims)
>
>Could you please test it ?
>
Sure! thanks...
^ permalink raw reply
* RE: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-30 11:12 UTC (permalink / raw)
To: David Laight
Cc: Hiroaki SHIMODA, Tom Herbert, Denys Fedoryshchenko, netdev,
e1000-devel, jeffrey.t.kirsher, jesse.brandeburg, davem
In-Reply-To: <1338375895.2760.153.camel@edumazet-glaptop>
On Wed, 2012-05-30 at 13:04 +0200, Eric Dumazet wrote:
> Please don't use lazy volatile.
>
> Unless you really want Linus flames (and ours)
>
> ACCESS_ONCE() is much cleaner.
>
http://yarchive.net/comp/linux/ACCESS_ONCE.html
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Joe Perches @ 2012-05-30 11:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Denys Fedoryshchenko, e1000-devel, netdev, jesse.brandeburg,
davem, Tom Herbert
In-Reply-To: <1338376107.2760.156.camel@edumazet-glaptop>
On Wed, 2012-05-30 at 13:08 +0200, Eric Dumazet wrote:
> Maybe we should change all POSDIFF(), not selected ones.
> #define POSDIFF(A, B) ((int)((A) - (B)) > 0 ? (A) - (B) : 0)
maybe use an eval once statement expression macro
({
typeof (A) _a = (A);
typeof (B) _b = (B);
((int)(_a - _b) > 0 ? _a - _b : 0;
})
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [RFC PATCH 2/2] tcp: Early SYN limit and SYN cookie handling to mitigate SYN floods
From: Hans Schillstrom @ 2012-05-30 11:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, Jesper Dangaard Brouer, Jesper Dangaard Brouer,
netdev@vger.kernel.org, Christoph Paasch, David S. Miller,
Martin Topholm, Florian Westphal, Tom Herbert
In-Reply-To: <1338366288.2760.115.camel@edumazet-glaptop>
On Wednesday 30 May 2012 10:24:48 Eric Dumazet wrote:
> On Wed, 2012-05-30 at 10:03 +0200, Hans Schillstrom wrote:
>
> > We have this option running right now, and it gave slightly higher values.
> > The upside is only one core is running at 100% load.
> >
> > To be able to process more SYN an attempt was made to spread them with RPS to
> > 2 other cores gave 60% more SYN:s per sec
> > i.e. syn filter in NIC sending all irq:s to one core gave ~ 52k syn. pkts/sec
> > adding RPS and sending syn to two other core:s gave ~80k syn. pkts/sec
> > Adding more cores than two didn't help that much.
>
> When you say 52.000 pkt/s, is that for fully established sockets, or
> SYNFLOOD ?
SYN Flood with hping3 random source ip, dest port 5060
and there is a listener on that port.
(kernel 3.0.13)
> 19.23 us to handle _one_ SYN message seems pretty wrong to me, if there
> is no contention on listener socket.
>
BTW.
I also see a strange behavior during SYN flood.
The client starts data sending directly in the ack,
and that first packet is more or less always retransmitted once.
I'll dig into that later, or do anyone have an idea of the reason ?
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Hiroaki SHIMODA @ 2012-05-30 11:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: Denys Fedoryshchenko, e1000-devel, netdev, jesse.brandeburg,
davem, Tom Herbert
In-Reply-To: <1338376107.2760.156.camel@edumazet-glaptop>
On Wed, 30 May 2012 13:08:27 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2012-05-30 at 19:43 +0900, Hiroaki SHIMODA wrote:
>
> > While examining ping problem, below pattern is often observed.
> >
> > TIME
> > dql_queued() dql_completed() |
> > a) initial state |
> > |
> > b) X bytes queued V
> >
> > c) Y bytes queued
> > d) X bytes completed
> > e) Z bytes queued
> > f) Y bytes completed
> >
> > a) dql->limit has already some value and there is no in-flight packet.
> > b) X bytes queued.
> > c) Y bytes queued and excess limit.
> > d) X bytes completed and dql->prev_ovlimit is set and also
> > dql->prev_num_queued is set Y.
> > e) Z bytes queued.
> > f) Y bytes completed. inprogress and prev_inprogress are true.
> >
> > At f), if I read the comment correctly, all_prev_completed becomes
> > true and limit should be increased. But POSDIFF() ignores
> > (A == B) case, so limit is decreased.
>
> Which POSDIFF(), because there are many ;)
I mean,
all_prev_completed = POSDIFF(completed, dql->prev_num_queued);
> By the way, given complexity of this I suggest you split your ideas in
> independent patches.
In this case, here is the patch what I thinking.
diff --git a/lib/dynamic_queue_limits.c b/lib/dynamic_queue_limits.c
@@ -11,12 +11,14 @@
#include <linux/dynamic_queue_limits.h>
#define POSDIFF(A, B) ((A) > (B) ? (A) - (B) : 0)
+#define #define AFTER_EQ(A, B) ((int)((A) - (B)) >= 0)
/* Records completed count and recalculates the queue limit */
void dql_completed(struct dql *dql, unsigned int count)
{
unsigned int inprogress, prev_inprogress, limit;
- unsigned int ovlimit, all_prev_completed, completed;
+ unsigned int ovlimit, completed;
+ bool all_prev_completed;
/* Can't complete more than what's in queue */
BUG_ON(count > dql->num_queued - dql->num_completed);
@@ -26,7 +28,7 @@ void dql_completed(struct dql *dql, unsigned int count)
ovlimit = POSDIFF(dql->num_queued - dql->num_completed, limit);
inprogress = dql->num_queued - completed;
prev_inprogress = dql->prev_num_queued - dql->num_completed;
- all_prev_completed = POSDIFF(completed, dql->prev_num_queued);
+ all_prev_completed = AFTER_EQ(completed, dql->prev_num_queued);
if ((ovlimit && !inprogress) ||
(dql->prev_ovlimit && all_prev_completed)) {
> Mabe we should change all POSDIFF(), not selected ones.
>
> #define POSDIFF(A, B) ((int)((A) - (B)) > 0 ? (A) - (B) : 0)
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-30 11:59 UTC (permalink / raw)
To: Joe Perches
Cc: Hiroaki SHIMODA, Tom Herbert, Denys Fedoryshchenko, netdev,
e1000-devel, jeffrey.t.kirsher, jesse.brandeburg, davem
In-Reply-To: <1338376817.32113.5.camel@joe2Laptop>
On Wed, 2012-05-30 at 04:20 -0700, Joe Perches wrote:
> On Wed, 2012-05-30 at 13:08 +0200, Eric Dumazet wrote:
> > Maybe we should change all POSDIFF(), not selected ones.
> > #define POSDIFF(A, B) ((int)((A) - (B)) > 0 ? (A) - (B) : 0)
>
> maybe use an eval once statement expression macro
> ({
> typeof (A) _a = (A);
> typeof (B) _b = (B);
> ((int)(_a - _b) > 0 ? _a - _b : 0;
> })
>
>
Well, many choices are possible, including
#define POSDIFF(A, B) max_t(int, (A) - (B), 0);
^ permalink raw reply
* Re: [RFC PATCH 0/4] inet: add second hash table
From: Daniel Baluta @ 2012-05-30 12:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexandru Copot, davem, gerrit, kuznet, jmorris, yoshfuji, kaber,
netdev, Lucian Grijincu
In-Reply-To: <1338364640.2760.96.camel@edumazet-glaptop>
On Wed, May 30, 2012 at 10:57 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2012-05-30 at 10:36 +0300, Alexandru Copot wrote:
>> This patchset implements all the operations needed to use a second
>> (port,address) bind hash table for inet. It uses a similar approach
>> as the UDP implementation.
>>
>> The performance improvements for port allocation are very good and
>> detailed in the last message.
>>
>> This is based on a series of patches written by Lucian Grijincu at Ixia.
>>
>> Signed-off-by: Alexandru Copot <alex.mihai.c@gmail.com>
>> Cc: Daniel Baluta <dbaluta@ixiacom.com>
>> Cc: Lucian Grijincu <lucian.grijincu@gmail.com>
>> ---
>> Alexandru Copot (4):
>> inet: add counter to inet_bind_hashbucket
>> inet: add a second bind hash
>> inet: add/remove inet buckets in the second bind hash
>> inet: use second hash in inet_csk_get_port
>>
>> include/net/inet_hashtables.h | 140 +++++++++++++++++++++++++++++++--
>> include/net/inet_timewait_sock.h | 5 +-
>> net/dccp/proto.c | 37 ++++++++-
>> net/ipv4/inet_connection_sock.c | 66 ++++++++--------
>> net/ipv4/inet_hashtables.c | 158 ++++++++++++++++++++++++++++++++++++--
>> net/ipv4/inet_timewait_sock.c | 16 ++--
>> net/ipv4/tcp.c | 17 ++++
>> net/ipv6/inet6_hashtables.c | 95 +++++++++++++++++++++++
>> 8 files changed, 477 insertions(+), 57 deletions(-)
>
>
> Its a huge change (with many details to look at), for a yet to be
> understood need.
>
> What sensible workload needs this at all ?
Hi Eric,
Usually our tests use a huge number of virtual interfaces.
Using this patch we get a massive improvement when there are many sockets
bound to the same port, but different addresses for both bind() and
listen() system calls (both call inet_csk_get_port).
We provided some data points in the fourth patch:
For 16.000 interfaces each with a distinct IPv4 address, doing bind
and then listen we get:
* Without patch and without SO_REUSEADDR:
* bind: 1.543 s
* listen: 3.050 s
* Without patch and with SO_REUSEADDR set:
* bind: 0.066 s
* listen: 3.050 s
* With patch and SO_REUSEADDR set / without SO_REUSEADDR:
* bind: 0.066 s
* listen: 0.095 s
The source code for tests can be found here [1].
Just run:
* ./prepare_test2.sh
* ./avg_tcp.sh
If I understood it correctly, a similar patch was introduced
for UDP some time ago. [2]
thanks,
Daniel.
[1] http://ixlabs.cs.pub.ro/gitweb/?p=port-allocation.git;a=tree;f=testbind;h=687e4452101e13cb5995b43c1351d76786d98fdd;hb=HEAD
[2] http://www.spinics.net/lists/netdev/msg112056.html
^ permalink raw reply
* Re: [RFC PATCH 0/4] inet: add second hash table
From: Eric Dumazet @ 2012-05-30 12:41 UTC (permalink / raw)
To: Daniel Baluta
Cc: Alexandru Copot, davem, gerrit, kuznet, jmorris, yoshfuji, kaber,
netdev, Lucian Grijincu
In-Reply-To: <CAEnQRZD3o_+fRnnbd74VeFuNvjAVVyq-rE241J96iRXWFDAEPQ@mail.gmail.com>
On Wed, 2012-05-30 at 15:32 +0300, Daniel Baluta wrote:
> Hi Eric,
>
> Usually our tests use a huge number of virtual interfaces.
> Using this patch we get a massive improvement when there are many sockets
> bound to the same port, but different addresses for both bind() and
> listen() system calls (both call inet_csk_get_port).
>
> We provided some data points in the fourth patch:
>
> For 16.000 interfaces each with a distinct IPv4 address, doing bind
> and then listen we get:
>
>
> If I understood it correctly, a similar patch was introduced
> for UDP some time ago. [2]
>
> thanks,
> Daniel.
>
> [1] http://ixlabs.cs.pub.ro/gitweb/?p=port-allocation.git;a=tree;f=testbind;h=687e4452101e13cb5995b43c1351d76786d98fdd;hb=HEAD
> [2] http://www.spinics.net/lists/netdev/msg112056.html
UDP case was a bit different, since production machine could really have
thousand of UDP flows for tunnel terminations.
But for TCP, unless your very specific needs I don't see the real need
to review 400 lines of patches ?
Nobody but you ever complained of listen() being performance critical
with 16.000 IP on a machime...
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Joe Perches @ 2012-05-30 14:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: Denys Fedoryshchenko, e1000-devel, netdev, jesse.brandeburg,
davem, Tom Herbert
In-Reply-To: <1338379151.2760.166.camel@edumazet-glaptop>
On Wed, 2012-05-30 at 13:59 +0200, Eric Dumazet wrote:
> On Wed, 2012-05-30 at 04:20 -0700, Joe Perches wrote:
> > On Wed, 2012-05-30 at 13:08 +0200, Eric Dumazet wrote:
> > > Maybe we should change all POSDIFF(), not selected ones.
> > > #define POSDIFF(A, B) ((int)((A) - (B)) > 0 ? (A) - (B) : 0)
> >
> > maybe use an eval once statement expression macro
> > ({
> > typeof (A) _a = (A);
> > typeof (B) _b = (B);
> > ((int)(_a - _b) > 0 ? _a - _b : 0;
> > })
>
> Well, many choices are possible, including
> #define POSDIFF(A, B) max_t(int, (A) - (B), 0);
Maybe. If the intent to always return an int.
The current macro doesn't.
Whatever evals A and B once would be better.
cheers, Joe
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH repost] virtio-net: remove useless disable on freeze
From: Michael S. Tsirkin @ 2012-05-30 14:21 UTC (permalink / raw)
To: Rusty Russell, Michael S. Tsirkin, virtualization, netdev,
linux-kernel
disable_cb is just an optimization: it
can not guarantee that there are no callbacks.
In particular it doesn't have any effect when
event index is on.
Instead, detach, napi disable and reset on freeze ensure we don't run
concurrently with a callback.
Remove the useless calls so we get same behaviour
with and without event index.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
Reposting a patch that seems to have fallen through cracks.
drivers/net/virtio_net.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 9ce6995..5214b1e 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1231,11 +1231,6 @@ static int virtnet_freeze(struct virtio_device *vdev)
vi->config_enable = false;
mutex_unlock(&vi->config_lock);
- virtqueue_disable_cb(vi->rvq);
- virtqueue_disable_cb(vi->svq);
- if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ))
- virtqueue_disable_cb(vi->cvq);
-
netif_device_detach(vi->dev);
cancel_delayed_work_sync(&vi->refill);
--
MST
^ permalink raw reply related
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-30 14:42 UTC (permalink / raw)
To: Joe Perches
Cc: Denys Fedoryshchenko, e1000-devel, netdev, jesse.brandeburg,
davem, Tom Herbert
In-Reply-To: <1338386973.32113.23.camel@joe2Laptop>
On Wed, 2012-05-30 at 07:09 -0700, Joe Perches wrote:
> Whatever evals A and B once would be better.
Why do you believe they could be evaluated several time ?
#define POSDIFF(A, B) max_t(int, (A) - (B), 0)
(A) - (B) is done once, or its a huge max_t() bug.
By the way, we handle 32bit values here. No way BQL can overflow a 4GB
limit.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-30 14:49 UTC (permalink / raw)
To: Hiroaki SHIMODA
Cc: Denys Fedoryshchenko, e1000-devel, netdev, jesse.brandeburg,
davem, Tom Herbert
In-Reply-To: <20120530202917.b2642929.shimoda.hiroaki@gmail.com>
On Wed, 2012-05-30 at 20:29 +0900, Hiroaki SHIMODA wrote:
> On Wed, 30 May 2012 13:08:27 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Wed, 2012-05-30 at 19:43 +0900, Hiroaki SHIMODA wrote:
> >
> > > While examining ping problem, below pattern is often observed.
> > >
> > > TIME
> > > dql_queued() dql_completed() |
> > > a) initial state |
> > > |
> > > b) X bytes queued V
> > >
> > > c) Y bytes queued
> > > d) X bytes completed
> > > e) Z bytes queued
> > > f) Y bytes completed
> > >
> > > a) dql->limit has already some value and there is no in-flight packet.
> > > b) X bytes queued.
> > > c) Y bytes queued and excess limit.
> > > d) X bytes completed and dql->prev_ovlimit is set and also
> > > dql->prev_num_queued is set Y.
> > > e) Z bytes queued.
> > > f) Y bytes completed. inprogress and prev_inprogress are true.
> > >
> > > At f), if I read the comment correctly, all_prev_completed becomes
> > > true and limit should be increased. But POSDIFF() ignores
> > > (A == B) case, so limit is decreased.
> >
> > Which POSDIFF(), because there are many ;)
>
> I mean,
> all_prev_completed = POSDIFF(completed, dql->prev_num_queued);
>
> > By the way, given complexity of this I suggest you split your ideas in
> > independent patches.
>
> In this case, here is the patch what I thinking.
>
> diff --git a/lib/dynamic_queue_limits.c b/lib/dynamic_queue_limits.c
> @@ -11,12 +11,14 @@
> #include <linux/dynamic_queue_limits.h>
>
> #define POSDIFF(A, B) ((A) > (B) ? (A) - (B) : 0)
> +#define #define AFTER_EQ(A, B) ((int)((A) - (B)) >= 0)
>
> /* Records completed count and recalculates the queue limit */
> void dql_completed(struct dql *dql, unsigned int count)
> {
> unsigned int inprogress, prev_inprogress, limit;
> - unsigned int ovlimit, all_prev_completed, completed;
> + unsigned int ovlimit, completed;
> + bool all_prev_completed;
>
> /* Can't complete more than what's in queue */
> BUG_ON(count > dql->num_queued - dql->num_completed);
> @@ -26,7 +28,7 @@ void dql_completed(struct dql *dql, unsigned int count)
> ovlimit = POSDIFF(dql->num_queued - dql->num_completed, limit);
> inprogress = dql->num_queued - completed;
> prev_inprogress = dql->prev_num_queued - dql->num_completed;
> - all_prev_completed = POSDIFF(completed, dql->prev_num_queued);
> + all_prev_completed = AFTER_EQ(completed, dql->prev_num_queued);
>
> if ((ovlimit && !inprogress) ||
> (dql->prev_ovlimit && all_prev_completed)) {
I am fine with this one.
Can you send official patches please ?
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Joe Perches @ 2012-05-30 14:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: Denys Fedoryshchenko, e1000-devel, netdev, jesse.brandeburg,
davem, Tom Herbert
In-Reply-To: <1338388974.2760.193.camel@edumazet-glaptop>
On Wed, 2012-05-30 at 16:42 +0200, Eric Dumazet wrote:
> On Wed, 2012-05-30 at 07:09 -0700, Joe Perches wrote:
>
> > Whatever evals A and B once would be better.
>
> Why do you believe they could be evaluated several time ?
>
> #define POSDIFF(A, B) max_t(int, (A) - (B), 0)
I don't and didn't say I did.
> By the way, we handle 32bit values here. No way BQL can overflow a 4GB
> limit.
swell.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: dave taht @ 2012-05-30 15:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hiroaki SHIMODA, Tom Herbert, Denys Fedoryshchenko, netdev,
e1000-devel, jeffrey.t.kirsher, jesse.brandeburg, davem
In-Reply-To: <1338389342.2760.195.camel@edumazet-glaptop>
On 05/30/2012 07:49 AM, Eric Dumazet wrote:
> On Wed, 2012-05-30 at 20:29 +0900, Hiroaki SHIMODA wrote:
>> On Wed, 30 May 2012 13:08:27 +0200
>> Eric Dumazet<eric.dumazet@gmail.com> wrote:
>>
>>> On Wed, 2012-05-30 at 19:43 +0900, Hiroaki SHIMODA wrote:
>>>
>>>> While examining ping problem, below pattern is often observed.
>>>>
>>>> TIME
>>>> dql_queued() dql_completed() |
>>>> a) initial state |
>>>> |
>>>> b) X bytes queued V
>>>>
>>>> c) Y bytes queued
>>>> d) X bytes completed
>>>> e) Z bytes queued
>>>> f) Y bytes completed
>>>>
>>>> a) dql->limit has already some value and there is no in-flight packet.
>>>> b) X bytes queued.
>>>> c) Y bytes queued and excess limit.
>>>> d) X bytes completed and dql->prev_ovlimit is set and also
>>>> dql->prev_num_queued is set Y.
>>>> e) Z bytes queued.
>>>> f) Y bytes completed. inprogress and prev_inprogress are true.
>>>>
>>>> At f), if I read the comment correctly, all_prev_completed becomes
>>>> true and limit should be increased. But POSDIFF() ignores
>>>> (A == B) case, so limit is decreased.
>>> Which POSDIFF(), because there are many ;)
>> I mean,
>> all_prev_completed = POSDIFF(completed, dql->prev_num_queued);
>>
>>> By the way, given complexity of this I suggest you split your ideas in
>>> independent patches.
>> In this case, here is the patch what I thinking.
>>
>> diff --git a/lib/dynamic_queue_limits.c b/lib/dynamic_queue_limits.c
>> @@ -11,12 +11,14 @@
>> #include<linux/dynamic_queue_limits.h>
>>
>> #define POSDIFF(A, B) ((A)> (B) ? (A) - (B) : 0)
>> +#define #define AFTER_EQ(A, B) ((int)((A) - (B))>= 0)
>>
>> /* Records completed count and recalculates the queue limit */
>> void dql_completed(struct dql *dql, unsigned int count)
>> {
>> unsigned int inprogress, prev_inprogress, limit;
>> - unsigned int ovlimit, all_prev_completed, completed;
>> + unsigned int ovlimit, completed;
>> + bool all_prev_completed;
>>
>> /* Can't complete more than what's in queue */
>> BUG_ON(count> dql->num_queued - dql->num_completed);
>> @@ -26,7 +28,7 @@ void dql_completed(struct dql *dql, unsigned int count)
>> ovlimit = POSDIFF(dql->num_queued - dql->num_completed, limit);
>> inprogress = dql->num_queued - completed;
>> prev_inprogress = dql->prev_num_queued - dql->num_completed;
>> - all_prev_completed = POSDIFF(completed, dql->prev_num_queued);
>> + all_prev_completed = AFTER_EQ(completed, dql->prev_num_queued);
>>
>> if ((ovlimit&& !inprogress) ||
>> (dql->prev_ovlimit&& all_prev_completed)) {
> I am fine with this one.
>
> Can you send official patches please ?
While this looks encouraging, BQL presently overbuffers by about a
factor of 2 in low (sub 100Mbit) scenarios
on the hardware I have available to me.
I look forward to re-running benchmarks with this patch however.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: bug in ip -s xfrm state list
From: Stephen Hemminger @ 2012-05-30 15:13 UTC (permalink / raw)
To: Jaroslav Šafka; +Cc: netdev
In-Reply-To: <1938601.tRGYljKHkq@notebook>
On Wed, 30 May 2012 15:00:05 +0200
Jaroslav Šafka <jaroslav.safka@siemens.com> wrote:
> Hello guys,
> I found small problem in printing "seq" number.
> I think the problem is visible in diff below ;-)
>
> Best regards
> Jarek
>
> diff --git a/ip/ipxfrm.c b/ip/ipxfrm.c
> index c7b3420..67fe838 100644
> --- a/ip/ipxfrm.c
> +++ b/ip/ipxfrm.c
> @@ -843,7 +843,7 @@ void xfrm_state_info_print(struct xfrm_usersa_info
> *xsinfo,
> fputs(buf, fp);
> fprintf(fp, "replay-window %u ", xsinfo->replay_window);
> if (show_stats > 0)
> - fprintf(fp, "seq 0x%08u ", xsinfo->seq);
> + fprintf(fp, "seq %08u ", ntohl(xsinfo->seq));
> if (show_stats > 0 || xsinfo->flags) {
> __u8 flags = xsinfo->flags;
>
>
>
Moving to netdev list for more feedback.
Your change has two components:
1. printing sequence number in decimal notation with 0x prefix.
2. doing ntohl().
The first is an obvious bug in the original code. Not sure about
the second. It looks like sequence numbers generated by the kernel
come from xfrm_get_acqseq() which generates sequence numbers in host
byte order. But sequence numbers entered from user space (vi xfrm_seq_parse)
are encoded in network byte order. This looks like a flaw in the original design.
The kernel networking code tries to be careful about documenting network
verus host byte order via the typedef __be32 vs __u32. Given that the kernel
is using __u32 for sequence number in xfrm fairly consistently; my opninon
is that iproute2 should change and go with the kernel practice and
use host byte order.
^ permalink raw reply
* Re: [RFC PATCH 0/4] inet: add second hash table
From: Ben Greear @ 2012-05-30 16:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: Daniel Baluta, Alexandru Copot, davem, gerrit, kuznet, jmorris,
yoshfuji, kaber, netdev, Lucian Grijincu
In-Reply-To: <1338381662.2760.172.camel@edumazet-glaptop>
On 05/30/2012 05:41 AM, Eric Dumazet wrote:
> On Wed, 2012-05-30 at 15:32 +0300, Daniel Baluta wrote:
> UDP case was a bit different, since production machine could really have
> thousand of UDP flows for tunnel terminations.
>
> But for TCP, unless your very specific needs I don't see the real need
> to review 400 lines of patches ?
>
> Nobody but you ever complained of listen() being performance critical
> with 16.000 IP on a machime...
Well, we do similar things and would probably benefit from this change...
If it would help, I'll add these to our kernels and run them through
some of our test cases..but will probably be a week or two at soonest...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC PATCH 4/4] inet: use second hash in inet_csk_get_port
From: Eric Dumazet @ 2012-05-30 16:42 UTC (permalink / raw)
To: Alexandru Copot
Cc: davem, gerrit, kuznet, jmorris, yoshfuji, kaber, netdev,
Daniel Baluta, Lucian Grijincu
In-Reply-To: <1338363410-6562-5-git-send-email-alex.mihai.c@gmail.com>
On Wed, 2012-05-30 at 10:36 +0300, Alexandru Copot wrote:
> diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
> index bc06168..2f589bb 100644
> --- a/include/net/inet_hashtables.h
> +++ b/include/net/inet_hashtables.h
> @@ -81,6 +81,15 @@ struct inet_bind_bucket {
> struct net *ib_net;
> #endif
> unsigned short port;
> + union {
> + struct in6_addr ib_addr_ipv6;
> + struct {
> + __be32 _1;
> + __be32 _2;
> + __be32 _3;
> + __be32 ib_addr_ipv4;
> + };
> + };
> signed short fastreuse;
> int num_owners;
> struct hlist_node node;
Yet another poor choice, adding two holes in this structure.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox