Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ARM: mxs: dt: Add Crystalfontz CFA-10037 device tree support
From: Maxime Ripard @ 2013-01-22 16:35 UTC (permalink / raw)
  To: linux-arm-kernel

The CFA-10037 is another expansion board for the CFA-10036 module, with
only a USB Host, a Ethernet device and a lot of gpios.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10037.dts |   77 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-mxs/mach-mxs.c         |    8 ++++
 2 files changed, 85 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx28-cfa10037.dts

diff --git a/arch/arm/boot/dts/imx28-cfa10037.dts b/arch/arm/boot/dts/imx28-cfa10037.dts
new file mode 100644
index 0000000..c2ef3a3
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-cfa10037.dts
@@ -0,0 +1,77 @@
+/*
+ * Copyright 2012 Free Electrons
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/*
+ * The CFA-10049 is an expansion board for the CFA-10036 module, thus we
+ * need to include the CFA-10036 DTS.
+ */
+/include/ "imx28-cfa10036.dts"
+
+/ {
+	model = "Crystalfontz CFA-10037 Board";
+	compatible = "crystalfontz,cfa10037", "crystalfontz,cfa10036", "fsl,imx28";
+
+	apb at 80000000 {
+		apbh at 80000000 {
+			pinctrl at 80018000 {
+				pinctrl-names = "default", "default";
+				pinctrl-1 = <&hog_pins_cfa10037>;
+
+				hog_pins_cfa10037: hog-10037 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x0073 /* MX28_PAD_GPMI_D7__GPIO_0_7 */
+						0x2153 /* MX28_PAD_SSP2_D5__GPIO_2_21 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+			};
+		};
+
+		apbx at 80040000 {
+			usbphy1: usbphy at 8007e000 {
+				status = "okay";
+			};
+		};
+	};
+
+	ahb at 80080000 {
+		usb1: usb at 80090000 {
+			vbus-supply = <&reg_usb1_vbus>;
+			pinctrl-0 = <&usbphy1_pins_a>;
+			pinctrl-names = "default";
+			status = "okay";
+		};
+
+		mac0: ethernet at 800f0000 {
+			phy-mode = "rmii";
+			pinctrl-names = "default";
+			pinctrl-0 = <&mac0_pins_a>;
+			phy-reset-gpios = <&gpio2 21 0>;
+			phy-reset-duration = <100>;
+			status = "okay";
+		};
+	};
+
+	regulators {
+		compatible = "simple-bus";
+
+		reg_usb1_vbus: usb1_vbus {
+			compatible = "regulator-fixed";
+			regulator-name = "usb1_vbus";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			gpio = <&gpio0 7 1>;
+		};
+	};
+};
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index 4668cf7..622c45a 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -417,6 +417,12 @@ static void __init cfa10049_init(void)
 	mxsfb_pdata.ld_intf_width = STMLCDIF_18BIT;
 }
 
+static void __init cfa10037_init(void)
+{
+	enable_clk_enet_out();
+	update_fec_mac_prop(OUI_CRYSTALFONTZ);
+}
+
 static void __init apf28_init(void)
 {
 	enable_clk_enet_out();
@@ -437,6 +443,8 @@ static void __init mxs_machine_init(void)
 		m28evk_init();
 	else if (of_machine_is_compatible("bluegiga,apx4devkit"))
 		apx4devkit_init();
+	else if (of_machine_is_compatible("crystalfontz,cfa10037"))
+		cfa10037_init();
 	else if (of_machine_is_compatible("crystalfontz,cfa10049"))
 		cfa10049_init();
 	else if (of_machine_is_compatible("armadeus,imx28-apf28"))
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 3/6] arm: kconfig: don't select TWD with local timer for Armada 370/XP
From: Gregory CLEMENT @ 2013-01-22 16:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <201301221557.02976.arnd@arndb.de>

On 01/22/2013 04:57 PM, Arnd Bergmann wrote:
> On Monday 21 January 2013, Gregory CLEMENT wrote:
>> I don't see a strong reason to not enable it if we don't use it. My concern
>> was that I don't need it so I didn't want to include it and generating extra
>> code for nothing. Then just after having sent this patch set, I received your
>> patch set about build regression in 3.8 and especially the part about
>> CONFIG_MULTIPLATFORM made me realized that it could be a problem.
> 
> Ok.
> 
>>> Maybe it can be written as
>>>
>>> config LOCAL_TIMERS
>>>       bool "Use local timer interrupts"
>>>       depends on SMP
>>>       default y
>>>
>>> config HAVE_ARM_TWD
>>>       depends on LOCAL_TIMERS
>>>       default ARCH_MULTIPLATFORM || (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
>>
>> So in this case why not written something like this:
>>         default ARCH_MULTIPLATFORM || (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT && !ARMADA_370_XP_TIMER)
> 
> That does not change anything, because ARMADA_370_XP_TIMER is only ever enabled
> when ARCH_MULTIPLATFORM is enabled as well.

Yes you're right.

So I remove this patch of my series as I don't need it anymore for supporting local
timer on Armada XP/370.

And I will submit this patch as a standalone one.

> 
>>>       default y
>> I am not a kconfig expert, but won't this line set HAVE_ARM_TWD to 'y' whatever
>> the result of the previous line?
> 
> Yes, that was a mistake on my side.
> 
> 	Arnd
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply

* [PATCH 3/3] ARM: dts: mxs: Add the LCD to the 10049 board
From: Maxime Ripard @ 2013-01-22 16:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1358871791-14214-1-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/imx28-cfa10049.dts |   99 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-mxs/mach-mxs.c         |   22 ++++++++
 2 files changed, 121 insertions(+)

diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index dd91244..cabc33a 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -30,9 +30,11 @@
 					reg = <0>;
 					fsl,pinmux-ids = <
 						0x0073 /* MX28_PAD_GPMI_D7__GPIO_0_7 */
+						0x1153 /* MX28_PAD_LCD_D22__GPIO_1_21 */
 						0x1163 /* MX28_PAD_LCD_D22__GPIO_1_22 */
 						0x1173 /* MX28_PAD_LCD_D22__GPIO_1_23 */
 						0x2153 /* MX28_PAD_SSP2_D5__GPIO_2_21 */
+						0x3173 /* MX28_PAD_LCD_RESET__GPIO_3_23 */
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
@@ -43,12 +45,25 @@
 					reg = <0>;
 					fsl,pinmux-ids = <
 						0x2133 /* MX28_PAD_SSP2_D3__GPIO_2_19 */
+						0x31e3 /* MX28_PAD_LCD_RESET__GPIO_3_30 */
 					>;
 					fsl,drive-strength = <0>;
 					fsl,voltage = <1>;
 					fsl,pull-up = <1>;
 				};
 
+				spi2_pins_cfa10049: spi2-cfa10049 at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x2103 /* MX28_PAD_SSP2_SCK__GPIO_2_16 */
+						0x2113 /* MX28_PAD_SSP2_CMD__GPIO_2_17 */
+						0x2123 /* MX28_PAD_SSP2_D0__GPIO_2_18 */
+					>;
+					fsl,drive-strength = <1>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <1>;
+				};
+
 				spi3_pins_cfa10049: spi3-cfa10049 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
@@ -62,10 +77,63 @@
 					fsl,voltage = <1>;
 					fsl,pull-up = <1>;
 				};
+
+				lcdif_18bit_pins_cfa10049: lcdif-18bit at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x1000 /* MX28_PAD_LCD_D00__LCD_D0 */
+						0x1010 /* MX28_PAD_LCD_D01__LCD_D1 */
+						0x1020 /* MX28_PAD_LCD_D02__LCD_D2 */
+						0x1030 /* MX28_PAD_LCD_D03__LCD_D3 */
+						0x1040 /* MX28_PAD_LCD_D04__LCD_D4 */
+						0x1050 /* MX28_PAD_LCD_D05__LCD_D5 */
+						0x1060 /* MX28_PAD_LCD_D06__LCD_D6 */
+						0x1070 /* MX28_PAD_LCD_D07__LCD_D7 */
+						0x1080 /* MX28_PAD_LCD_D08__LCD_D8 */
+						0x1090 /* MX28_PAD_LCD_D09__LCD_D9 */
+						0x10a0 /* MX28_PAD_LCD_D10__LCD_D10 */
+						0x10b0 /* MX28_PAD_LCD_D11__LCD_D11 */
+						0x10c0 /* MX28_PAD_LCD_D12__LCD_D12 */
+						0x10d0 /* MX28_PAD_LCD_D13__LCD_D13 */
+						0x10e0 /* MX28_PAD_LCD_D14__LCD_D14 */
+						0x10f0 /* MX28_PAD_LCD_D15__LCD_D15 */
+						0x1100 /* MX28_PAD_LCD_D16__LCD_D16 */
+						0x1110 /* MX28_PAD_LCD_D17__LCD_D17 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
+				lcdif_pins_cfa10049: lcdif-evk at 0 {
+					reg = <0>;
+					fsl,pinmux-ids = <
+						0x1181 /* MX28_PAD_LCD_RD_E__LCD_VSYNC */
+						0x1191 /* MX28_PAD_LCD_WR_RWN__LCD_HSYNC */
+						0x11a1 /* MX28_PAD_LCD_RS__LCD_DOTCLK */
+						0x11b1 /* MX28_PAD_LCD_CS__LCD_ENABLE */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+			};
+
+			lcdif at 80030000 {
+				pinctrl-names = "default";
+				pinctrl-0 = <&lcdif_18bit_pins_cfa10049
+					     &lcdif_pins_cfa10049>;
+				status = "okay";
 			};
 		};
 
 		apbx at 80040000 {
+			pwm: pwm at 80064000 {
+				pinctrl-names = "default", "default";
+				pinctrl-1 = <&pwm3_pins_b>;
+				status = "okay";
+			};
+
 			i2c1: i2c at 8005a000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&i2c1_pins_a>;
@@ -147,6 +215,30 @@
 		};
 	};
 
+	spi2 {
+		compatible = "spi-gpio";
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi2_pins_cfa10049>;
+		status = "okay";
+		gpio-sck = <&gpio2 16 0>;
+		gpio-mosi = <&gpio2 17 0>;
+		gpio-miso = <&gpio2 18 0>;
+		cs-gpios = <&gpio3 23 0>;
+		num-chipselects = <1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		hx8357: hx8357 at 0 {
+			compatible = "himax,hx8357b", "himax,hx8357";
+			reg = <0>;
+			spi-max-frequency = <100000>;
+			spi-cpol;
+			spi-cpha;
+			gpios-reset = <&gpio3 30 0>;
+			im-gpios = <&gpio5 4 0 &gpio5 5 0 &gpio5 6 0>;
+		};
+	};
+
 	spi3 {
 		compatible = "spi-gpio";
 		pinctrl-names = "default";
@@ -183,4 +275,11 @@
 			spi-max-frequency = <100000>;
 		};
 	};
+
+	backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm 3 5000000>;
+		brightness-levels = <0 4 8 16 32 64 128 255>;
+		default-brightness-level = <6>;
+	};
 };
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index c66129b..4668cf7 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -119,6 +119,23 @@ static struct fb_videomode apf28dev_video_modes[] = {
 	},
 };
 
+static struct fb_videomode cfa10049_video_modes[] = {
+	{
+		.name		= "Himax HX8357-B",
+		.refresh	= 60,
+		.xres		= 320,
+		.yres		= 480,
+		.pixclock	= 108506, /* picosecond (9.216 MHz) */
+		.left_margin	= 2,
+		.right_margin	= 2,
+		.upper_margin	= 2,
+		.lower_margin	= 2,
+		.hsync_len	= 15,
+		.vsync_len	= 15,
+		.sync		= FB_SYNC_DATA_ENABLE_HIGH_ACT
+	},
+};
+
 static struct mxsfb_platform_data mxsfb_pdata __initdata;
 
 /*
@@ -393,6 +410,11 @@ static void __init cfa10049_init(void)
 {
 	enable_clk_enet_out();
 	update_fec_mac_prop(OUI_CRYSTALFONTZ);
+
+	mxsfb_pdata.mode_list = cfa10049_video_modes;
+	mxsfb_pdata.mode_count = ARRAY_SIZE(cfa10049_video_modes);
+	mxsfb_pdata.default_bpp = 32;
+	mxsfb_pdata.ld_intf_width = STMLCDIF_18BIT;
 }
 
 static void __init apf28_init(void)
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 2/3] ARM: dts: mxs: Add muxing options for the third PWM
From: Maxime Ripard @ 2013-01-22 16:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1358871791-14214-1-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/boot/dts/imx28.dtsi |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 13b7053..7ba4966 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -502,6 +502,16 @@
 					fsl,pull-up = <0>;
 				};
 
+				pwm3_pins_b: pwm3 at 1 {
+					reg = <1>;
+					fsl,pinmux-ids = <
+						0x3141 /* MX28_PAD_SAIF0_MCLK__PWM3 */
+					>;
+					fsl,drive-strength = <0>;
+					fsl,voltage = <1>;
+					fsl,pull-up = <0>;
+				};
+
 				pwm4_pins_a: pwm4 at 0 {
 					reg = <0>;
 					fsl,pinmux-ids = <
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 1/3] fb: backlight: Add the Himax HX-8357B LCD controller
From: Maxime Ripard @ 2013-01-22 16:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1358871791-14214-1-git-send-email-maxime.ripard@free-electrons.com>

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 drivers/video/backlight/Kconfig  |    7 +
 drivers/video/backlight/Makefile |    1 +
 drivers/video/backlight/hx8357.c |  482 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 490 insertions(+)
 create mode 100644 drivers/video/backlight/hx8357.c

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 765a945..c39bed0 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -126,6 +126,13 @@ config LCD_AMS369FG06
 	  If you have an AMS369FG06 AMOLED Panel, say Y to enable its
 	  LCD control driver.
 
+config LCD_HX8357
+	tristate "Himax HX-8357 LCD Driver"
+	depends on SPI
+	help
+	  If you have a HX-8357 LCD panel, say Y to enable its LCD control
+	  driver.
+
 endif # LCD_CLASS_DEVICE
 
 #
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index e7ce729..b69d391 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_LCD_TOSA)		   += tosa_lcd.o
 obj-$(CONFIG_LCD_S6E63M0)	+= s6e63m0.o
 obj-$(CONFIG_LCD_LD9040)	+= ld9040.o
 obj-$(CONFIG_LCD_AMS369FG06)	+= ams369fg06.o
+obj-$(CONFIG_LCD_HX8357)	+= hx8357.o
 
 obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o
 obj-$(CONFIG_BACKLIGHT_ATMEL_PWM)    += atmel-pwm-bl.o
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
new file mode 100644
index 0000000..ee4d607
--- /dev/null
+++ b/drivers/video/backlight/hx8357.c
@@ -0,0 +1,482 @@
+/*
+ * Driver for the Himax HX-8357 LCD Controller
+ *
+ * Copyright 2012 Free Electrons
+ *
+ * Licensed under the GPLv2 or later.
+ */
+
+#include <linux/delay.h>
+#include <linux/lcd.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
+#include <linux/spi/spi.h>
+
+#define HX8357_NUM_IM_PINS	3
+
+#define HX8357_SWRESET			0x01
+#define HX8357_GET_RED_CHANNEL		0x06
+#define HX8357_GET_GREEN_CHANNEL	0x07
+#define HX8357_GET_BLUE_CHANNEL		0x08
+#define HX8357_GET_POWER_MODE		0x0a
+#define HX8357_GET_MADCTL		0x0b
+#define HX8357_GET_PIXEL_FORMAT		0x0c
+#define HX8357_GET_DISPLAY_MODE		0x0d
+#define HX8357_GET_SIGNAL_MODE		0x0e
+#define HX8357_GET_DIAGNOSTIC_RESULT	0x0f
+#define HX8357_ENTER_SLEEP_MODE		0x10
+#define HX8357_EXIT_SLEEP_MODE		0x11
+#define HX8357_ENTER_PARTIAL_MODE	0x12
+#define HX8357_ENTER_NORMAL_MODE	0x13
+#define HX8357_EXIT_INVERSION_MODE	0x20
+#define HX8357_ENTER_INVERSION_MODE	0x21
+#define HX8357_SET_DISPLAY_OFF		0x28
+#define HX8357_SET_DISPLAY_ON		0x29
+#define HX8357_SET_COLUMN_ADDRESS	0x2a
+#define HX8357_SET_PAGE_ADDRESS		0x2b
+#define HX8357_WRITE_MEMORY_START	0x2c
+#define HX8357_READ_MEMORY_START	0x2e
+#define HX8357_SET_PARTIAL_AREA		0x30
+#define HX8357_SET_SCROLL_AREA		0x33
+#define HX8357_SET_TEAR_OFF		0x34
+#define HX8357_SET_TEAR_ON		0x35
+#define HX8357_SET_ADDRESS_MODE		0x36
+#define HX8357_SET_SCROLL_START		0x37
+#define HX8357_EXIT_IDLE_MODE		0x38
+#define HX8357_ENTER_IDLE_MOD		0x39
+#define HX8357_SET_PIXEL_FORMAT		0x3a
+#define HX8357_SET_PIXEL_FORMAT_DBI_3BIT	(0x1)
+#define HX8357_SET_PIXEL_FORMAT_DBI_16BIT	(0x5)
+#define HX8357_SET_PIXEL_FORMAT_DBI_18BIT	(0x6)
+#define HX8357_SET_PIXEL_FORMAT_DPI_3BIT	(0x1 << 4)
+#define HX8357_SET_PIXEL_FORMAT_DPI_16BIT	(0x5 << 4)
+#define HX8357_SET_PIXEL_FORMAT_DPI_18BIT	(0x6 << 4)
+#define HX8357_WRITE_MEMORY_CONTINUE	0x3c
+#define HX8357_READ_MEMORY_CONTINUE	0x3e
+#define HX8357_SET_TEAR_SCAN_LINES	0x44
+#define HX8357_GET_SCAN_LINES		0x45
+#define HX8357_READ_DDB_START		0xa1
+#define HX8357_SET_DISPLAY_MODE		0xb4
+#define HX8357_SET_DISPLAY_MODE_RGB_THROUGH	(0x3)
+#define HX8357_SET_DISPLAY_MODE_RGB_INTERFACE	(1 << 4)
+#define HX8357_SET_PANEL_DRIVING	0xc0
+#define HX8357_SET_DISPLAY_FRAME	0xc5
+#define HX8357_SET_RGB			0xc6
+#define HX8357_SET_RGB_ENABLE_HIGH		(1 << 1)
+#define HX8357_SET_GAMMA		0xc8
+#define HX8357_SET_POWER		0xd0
+#define HX8357_SET_VCOM			0xd1
+#define HX8357_SET_POWER_NORMAL		0xd2
+#define HX8357_SET_PANEL_RELATED	0xe9
+
+struct hx8357_data {
+	unsigned		im_pins[HX8357_NUM_IM_PINS];
+	unsigned		reset;
+	struct spi_device	*spi;
+	int			state;
+};
+
+static int hx8357_spi_write_then_read(struct lcd_device *lcdev,
+				void *txbuf, u16 txlen,
+				void *rxbuf, u16 rxlen)
+{
+	struct hx8357_data *lcd = lcd_get_data(lcdev);
+	struct spi_message msg;
+	struct spi_transfer xfer[2];
+	u16 *local_txbuf = NULL;
+	int ret = 0;
+
+	memset(xfer, 0, sizeof(xfer));
+	spi_message_init(&msg);
+
+	if (txlen) {
+		int i;
+
+		local_txbuf = kcalloc(sizeof(*local_txbuf), txlen, GFP_KERNEL);
+
+		if (!local_txbuf) {
+			dev_err(&lcdev->dev, "Couldn't allocate data buffer.\n");
+			return -ENOMEM;
+		}
+
+		for (i = 0; i < txlen; i++) {
+			local_txbuf[i] = ((u8 *)txbuf)[i];
+			if (i > 0)
+				local_txbuf[i] |= 1 << 8;
+		}
+
+		xfer[0].len = 2 * txlen;
+		xfer[0].bits_per_word = 9;
+		xfer[0].tx_buf = local_txbuf;
+		spi_message_add_tail(&xfer[0], &msg);
+	}
+
+	if (rxlen) {
+		xfer[1].len = rxlen;
+		xfer[1].bits_per_word = 8;
+		xfer[1].rx_buf = rxbuf;
+		spi_message_add_tail(&xfer[1], &msg);
+	}
+
+	ret = spi_sync(lcd->spi, &msg);
+	if (ret < 0)
+		dev_err(&lcdev->dev, "Couldn't send SPI data.\n");
+
+	if (txlen)
+		kfree(local_txbuf);
+
+	return ret;
+}
+
+static inline int hx8357_spi_write_array(struct lcd_device *lcdev,
+					u8 *value, u8 len)
+{
+	return hx8357_spi_write_then_read(lcdev, value, len, NULL, 0);
+}
+
+static inline int hx8357_spi_write_byte(struct lcd_device *lcdev,
+					u8 value)
+{
+	return hx8357_spi_write_then_read(lcdev, &value, 1, NULL, 0);
+}
+
+static int hx8357_enter_standby(struct lcd_device *lcdev)
+{
+	int ret;
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_OFF);
+	if (ret < 0)
+		return ret;
+
+	usleep_range(10000, 12000);
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_ENTER_SLEEP_MODE);
+	if (ret < 0)
+		return ret;
+
+	msleep(120);
+
+	return 0;
+}
+
+static int hx8357_exit_standby(struct lcd_device *lcdev)
+{
+	int ret;
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_EXIT_SLEEP_MODE);
+	if (ret < 0)
+		return ret;
+
+	msleep(120);
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
+static int hx8357_lcd_init(struct lcd_device *lcdev)
+{
+	struct hx8357_data *lcd = lcd_get_data(lcdev);
+	u8 buf[16];
+	int ret;
+
+	/*
+	 * Set the interface selection pins to SPI mode, with three
+	 * wires
+	 */
+	gpio_set_value_cansleep(lcd->im_pins[0], 1);
+	gpio_set_value_cansleep(lcd->im_pins[1], 0);
+	gpio_set_value_cansleep(lcd->im_pins[2], 1);
+
+	/* Reset the screen */
+	gpio_set_value(lcd->reset, 1);
+	usleep_range(10000, 12000);
+	gpio_set_value(lcd->reset, 0);
+	usleep_range(10000, 12000);
+	gpio_set_value(lcd->reset, 1);
+	msleep(120);
+
+	buf[0] = HX8357_SET_POWER;
+	buf[1] = 0x44;
+	buf[2] = 0x41;
+	buf[3] = 0x06;
+	ret = hx8357_spi_write_array(lcdev, buf, 4);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_VCOM;
+	buf[1] = 0x40;
+	buf[2] = 0x10;
+	ret = hx8357_spi_write_array(lcdev, buf, 3);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_POWER_NORMAL;
+	buf[1] = 0x05;
+	buf[2] = 0x12;
+	ret = hx8357_spi_write_array(lcdev, buf, 3);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_PANEL_DRIVING;
+	buf[1] = 0x14;
+	buf[2] = 0x3b;
+	buf[3] = 0x00;
+	buf[4] = 0x02;
+	buf[5] = 0x11;
+	ret = hx8357_spi_write_array(lcdev, buf, 6);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_DISPLAY_FRAME;
+	buf[1] = 0x0c;
+	ret = hx8357_spi_write_array(lcdev, buf, 2);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_PANEL_RELATED;
+	buf[1] = 0x01;
+	ret = hx8357_spi_write_array(lcdev, buf, 2);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = 0xea;
+	buf[1] = 0x03;
+	buf[2] = 0x00;
+	buf[3] = 0x00;
+	ret = hx8357_spi_write_array(lcdev, buf, 4);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = 0xeb;
+	buf[1] = 0x40;
+	buf[2] = 0x54;
+	buf[3] = 0x26;
+	buf[4] = 0xdb;
+	ret = hx8357_spi_write_array(lcdev, buf, 5);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_GAMMA;
+	buf[1] = 0x00;
+	buf[2] = 0x15;
+	buf[3] = 0x00;
+	buf[4] = 0x22;
+	buf[5] = 0x00;
+	buf[6] = 0x08;
+	buf[7] = 0x77;
+	buf[8] = 0x26;
+	buf[9] = 0x77;
+	buf[10] = 0x22;
+	buf[11] = 0x04;
+	buf[12] = 0x00;
+	ret = hx8357_spi_write_array(lcdev, buf, 13);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_ADDRESS_MODE;
+	buf[1] = 0xc0;
+	ret = hx8357_spi_write_array(lcdev, buf, 2);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_PIXEL_FORMAT;
+	buf[1] = HX8357_SET_PIXEL_FORMAT_DPI_18BIT |
+		HX8357_SET_PIXEL_FORMAT_DBI_18BIT;
+	ret = hx8357_spi_write_array(lcdev, buf, 2);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_COLUMN_ADDRESS;
+	buf[1] = 0x00;
+	buf[2] = 0x00;
+	buf[3] = 0x01;
+	buf[4] = 0x3f;
+	ret = hx8357_spi_write_array(lcdev, buf, 5);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_PAGE_ADDRESS;
+	buf[1] = 0x00;
+	buf[2] = 0x00;
+	buf[3] = 0x01;
+	buf[4] = 0xdf;
+	ret = hx8357_spi_write_array(lcdev, buf, 5);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_RGB;
+	buf[1] = 0x02;
+	ret = hx8357_spi_write_array(lcdev, buf, 2);
+	if (ret < 0)
+		return ret;
+
+	buf[0] = HX8357_SET_DISPLAY_MODE;
+	buf[1] = HX8357_SET_DISPLAY_MODE_RGB_THROUGH |
+		HX8357_SET_DISPLAY_MODE_RGB_INTERFACE;
+	ret = hx8357_spi_write_array(lcdev, buf, 2);
+	if (ret < 0)
+		return ret;
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_EXIT_SLEEP_MODE);
+	if (ret < 0)
+		return ret;
+
+	msleep(120);
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_SET_DISPLAY_ON);
+	if (ret < 0)
+		return ret;
+
+	usleep_range(5000, 7000);
+
+	ret = hx8357_spi_write_byte(lcdev, HX8357_WRITE_MEMORY_START);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
+#define POWER_IS_ON(pwr)	((pwr) <= FB_BLANK_NORMAL)
+
+static int hx8357_set_power(struct lcd_device *lcdev, int power)
+{
+	struct hx8357_data *lcd = lcd_get_data(lcdev);
+	int ret = 0;
+
+	if (POWER_IS_ON(power) && !POWER_IS_ON(lcd->state))
+		ret = hx8357_exit_standby(lcdev);
+	else if (!POWER_IS_ON(power) && POWER_IS_ON(lcd->state))
+		ret = hx8357_enter_standby(lcdev);
+
+	if (ret == 0)
+		lcd->state = power;
+	else
+		dev_warn(&lcdev->dev, "failed to set power mode %d\n", power);
+
+	return ret;
+}
+
+static int hx8357_get_power(struct lcd_device *lcdev)
+{
+	struct hx8357_data *lcd = lcd_get_data(lcdev);
+
+	return lcd->state;
+}
+
+static struct lcd_ops hx8357_ops = {
+	.set_power	= hx8357_set_power,
+	.get_power	= hx8357_get_power,
+};
+
+static int __devinit hx8357_probe(struct spi_device *spi)
+{
+	struct lcd_device *lcdev;
+	struct hx8357_data *lcd;
+	int i, ret;
+
+	lcd = devm_kzalloc(&spi->dev, sizeof(*lcd), GFP_KERNEL);
+	if (!lcd) {
+		dev_err(&spi->dev, "Couldn't allocate lcd internal structure!\n");
+		return -ENOMEM;
+	}
+
+	ret = spi_setup(spi);
+	if (ret < 0) {
+		dev_err(&spi->dev, "SPI setup failed.\n");
+		return ret;
+	}
+
+	lcd->spi = spi;
+
+	lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0);
+	if (!gpio_is_valid(lcd->reset)) {
+		dev_err(&spi->dev, "Missing dt property: gpios-reset\n");
+		return -EINVAL;
+	}
+
+	ret = devm_gpio_request_one(&spi->dev, lcd->reset,
+				    GPIOF_OUT_INIT_HIGH,
+				    "hx8357-reset");
+	if (ret) {
+		dev_err(&spi->dev,
+			"failed to request gpio %d: %d\n",
+			lcd->reset, ret);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
+		lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
+						"im-gpios", i);
+		if (lcd->im_pins[i] == -EPROBE_DEFER) {
+			dev_info(&spi->dev, "GPIO requested is not here yet, deferring the probe\n");
+			return -EPROBE_DEFER;
+		}
+		if (!gpio_is_valid(lcd->im_pins[i])) {
+			dev_err(&spi->dev, "Missing dt property: im-gpios\n");
+			return -EINVAL;
+		}
+
+		ret = devm_gpio_request_one(&spi->dev, lcd->im_pins[i],
+					GPIOF_DIR_OUT, "im_pins");
+		if (ret) {
+			dev_err(&spi->dev, "failed to request gpio %d: %d\n",
+				lcd->im_pins[i], ret);
+			return -EINVAL;
+		}
+	}
+
+	lcdev = lcd_device_register("mxsfb", &spi->dev, lcd, &hx8357_ops);
+	if (IS_ERR(lcdev)) {
+		ret = PTR_ERR(lcdev);
+		return ret;
+	}
+	spi_set_drvdata(spi, lcdev);
+
+	ret = hx8357_lcd_init(lcdev);
+	if (ret) {
+		dev_err(&spi->dev, "Couldn't initialize panel\n");
+		goto init_error;
+	}
+
+	dev_info(&spi->dev, "Panel probed\n");
+
+	return 0;
+
+init_error:
+	lcd_device_unregister(lcdev);
+	return ret;
+}
+
+static int __devexit hx8357_remove(struct spi_device *spi)
+{
+	struct lcd_device *lcdev = spi_get_drvdata(spi);
+
+	lcd_device_unregister(lcdev);
+	return 0;
+}
+
+static const struct of_device_id hx8357_dt_ids[] = {
+	{ .compatible = "himax,hx8357" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
+
+static struct spi_driver hx8357_driver = {
+	.probe  = hx8357_probe,
+	.remove = __devexit_p(hx8357_remove),
+	.driver = {
+		.name = "hx8357",
+		.of_match_table = of_match_ptr(hx8357_dt_ids),
+	},
+};
+
+module_spi_driver(hx8357_driver);
+
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
+MODULE_DESCRIPTION("Himax HX-8357 LCD Driver");
+MODULE_LICENSE("GPL");
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH 0/3] Add framebuffer support to the CFA-10049
From: Maxime Ripard @ 2013-01-22 16:23 UTC (permalink / raw)
  To: linux-arm-kernel

The CFA-10049 embeds a LCD screen that is using a Himax HX-8357B
that needs to be initialized through SPI before being able to use
its RGB interface.

This patchset adds a driver for this controller, and the needed
pieces in the 10049 device tree to enable it.

Maxime

Maxime Ripard (3):
  fb: backlight: Add the Himax HX-8357B LCD controller
  ARM: dts: mxs: Add muxing options for the third PWM
  ARM: dts: mxs: Add the LCD to the 10049 board

 arch/arm/boot/dts/imx28-cfa10049.dts |   99 +++++++
 arch/arm/boot/dts/imx28.dtsi         |   10 +
 arch/arm/mach-mxs/mach-mxs.c         |   22 ++
 drivers/video/backlight/Kconfig      |    7 +
 drivers/video/backlight/Makefile     |    1 +
 drivers/video/backlight/hx8357.c     |  482 ++++++++++++++++++++++++++++++++++
 6 files changed, 621 insertions(+)
 create mode 100644 drivers/video/backlight/hx8357.c

-- 
1.7.10.4

^ permalink raw reply

* [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
From: kishon @ 2013-01-22 16:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <50FEB3FD.3050001@ti.com>

Hi,

On Tuesday 22 January 2013 09:15 PM, kishon wrote:
> On Tuesday 22 January 2013 09:11 PM, Koen Kooi wrote:
>>
>> Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I <kishon@ti.com>
>> het volgende geschreven:
>>
>>> This patch series adds support for adding multiple PHY's (of same type).
>>> The binding information has to be present in the PHY library (otg.c) in
>>> order for it to return the appropriate PHY whenever the USB controller
>>> request for the PHY. So added a new API usb_bind_phy() to pass the
>>> binding
>>> information. This API should be called by platform specific
>>> initialization
>>> code.
>>>
>>> So the binding should be done something like
>>> usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto"); specifying
>>> the USB
>>> controller device name, index, and the PHY device name.
>>> I have done this binding for OMAP platforms, but it should be done for
>>> all the platforms.
>>>
>>> After this design, the phy can be got by passing the USB controller
>>> device
>>> pointer and the index.
>>>
>>> Developed this patch series on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
>>> after applying "usb: musb: add driver for control module" patch series
>>> and "ARM: dts: omap: add dt data for MUSB"
>>>
>>> Did basic enumeration testing in omap4 panda and omap3 beagle.
>>
>> With this patchset USB completely breaks on am33xx beaglebone, is that
>> intended?
> Not really.
> Does am33xx makes use of omap2430.c? Which PHY does am33xx uses?

I figured out it uses drivers/usb/musb/musb_dsps.c (So it doesn't use 
omap2430.c). I think it uses TWL4030_USB (TPS659x0) as PHY.

Then we need to adapt am33xx to use devm_usb_get_phy_by_phandle.
I'll see how to do it.

Thank you for testing and reporting it :-)

Thanks
Kishon

^ permalink raw reply

* [PATCH 3/6] arm: kconfig: don't select TWD with local timer for Armada 370/XP
From: Arnd Bergmann @ 2013-01-22 15:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <50FDC322.2040107@free-electrons.com>

On Monday 21 January 2013, Gregory CLEMENT wrote:
> I don't see a strong reason to not enable it if we don't use it. My concern
> was that I don't need it so I didn't want to include it and generating extra
> code for nothing. Then just after having sent this patch set, I received your
> patch set about build regression in 3.8 and especially the part about
> CONFIG_MULTIPLATFORM made me realized that it could be a problem.

Ok.

> > Maybe it can be written as
> > 
> > config LOCAL_TIMERS
> >       bool "Use local timer interrupts"
> >       depends on SMP
> >       default y
> > 
> > config HAVE_ARM_TWD
> >       depends on LOCAL_TIMERS
> >       default ARCH_MULTIPLATFORM || (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
> 
> So in this case why not written something like this:
>         default ARCH_MULTIPLATFORM || (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT && !ARMADA_370_XP_TIMER)

That does not change anything, because ARMADA_370_XP_TIMER is only ever enabled
when ARCH_MULTIPLATFORM is enabled as well.

> >       default y
> I am not a kconfig expert, but won't this line set HAVE_ARM_TWD to 'y' whatever
> the result of the previous line?

Yes, that was a mistake on my side.

	Arnd

^ permalink raw reply

* [PATCH v5 00/14] DMA Engine support for AM33XX
From: Sekhar Nori @ 2013-01-22 15:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>

Hi Tony,

On 1/16/2013 2:02 AM, Matt Porter wrote:

> This series adds DMA Engine support for AM33xx, which uses
> an EDMA DMAC. The EDMA DMAC has been previously supported by only
> a private API implementation (much like the situation with OMAP
> DMA) found on the DaVinci family of SoCs.

Will you take this series through the OMAP tree? Only 1/14 touches
mach-davinci and I am mostly okay with it except some changes I just
requested Matt to make in another thread.

Thanks,
Sekhar

^ permalink raw reply

* [PATCH 1/2] spi: spi-gpio: Add checks for the dt properties
From: Maxime Ripard @ 2013-01-22 15:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <50ED2C2D.7030608@free-electrons.com>

On 09/01/2013 09:37, Maxime Ripard wrote:
> On 27/12/2012 22:54, Maxime Ripard wrote:
>> The bindings assumed that the gpios properties were always there, which
>> made the NO_TX and NO_RX mode not usable from device tree. Add extra
>> checks to make sure that the driver can work if either MOSI or MISO is
>> not used.
> 
> Can you give me your Acked-by on this, or do you have any comments on this?

Ping?


-- 
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply

* Compilation problem with drivers/staging/zsmalloc when !SMP on ARM
From: Minchan Kim @ 2013-01-22 15:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKGA1bk3xdD5sTnn8DR9HQ4ae1sUsEnC1ENcwa3jfjDQgGp6QA@mail.gmail.com>

Hi Matt,

On Mon, Jan 21, 2013 at 10:00:17AM -0600, Matt Sealey wrote:
> Hi Minchan,
> 
> On Sun, Jan 20, 2013 at 11:55 PM, Minchan Kim <minchan@kernel.org> wrote:
> > On Fri, Jan 18, 2013 at 11:46:02PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Jan 18, 2013 at 07:11:32PM -0600, Matt Sealey wrote:
> >> >
> >> > diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
> >> > b/drivers/staging/zsmalloc/zsmalloc-main.c
> >> > index 09a9d35..ecf75fb 100644
> >>       > --- a/drivers/staging/zsmalloc/zsmalloc-main.c
> >> > +++ b/drivers/staging/zsmalloc/zsmalloc-main.c
> >> > @@ -228,7 +228,7 @@ struct zs_pool {
> >> >   * mapping rather than copying
> >> >   * for object mapping.
> >> >  */
> >> > -#if defined(CONFIG_ARM)
> >> > +#if defined(CONFIG_ARM) && defined(CONFIG_SMP)
> >> >  #define USE_PGTABLE_MAPPING
> >
> > I don't get it. How to prevent the problem Russel described?
> > The problem is that other CPU can prefetch _speculatively_ under us.
> 
> It prevents no problems, but if that isn't there, kernels build
> without SMP support (i.e. specifically uniprocessor kernels) will fail
> at the linker stage.
> 
> That's not desirable.
> 
> We have 3 problems here, this solves the first of them, and creates
> the third. The second is constant regardless..
> 
> 1) zsmalloc will not build on ARM without CONFIG_SMP because on UP
> local_tlb_flush_kern_range uses a function which uses an export which
> isn't required on SMP
> 
> Basically, with CONFIG_SMP (and CONFIG_UP_ON_SMP),
> local_tlb_flush_kern_range is calling functions by dereference from
> the per-cpu global cpu_tlb structure.
> 
> On UP (!CONFIG_SMP), it is calling functions directly (in my case,
> v7wbi_local_tlb_flush_kern_range or whatever, but on v6, v5, v4 ARM
> processor kernel builds it may be different) which need to be exported
> outside of the MM core.
> 
> If this difference is going to stick around - Russell is refusing here
> to export that/those direct functions - then the optimized vm mapping
> code simply should never be allowed to run on non-SMP systems to keep
> it building for everyone.
> 
> The patch above is simply a build fix for !CONFIG_SMP in this case to
> force it to use the slow path for systems where the above missing
> export problem will cause the linker failure.
> 
> 2) the optimized vm mapping isn't per-cpu aware as per Russell's
> arguments. I'll let you guys discuss that as I have no idea what the
> real implications are for SMP systems (and my current testing is only
> on a non-SMP CPU, I will have to go grab a couple boards from the lab
> for SMP)
> 
> 3) it somewhat defeats the purpose of the optimization if UP systems
> (which tend to have less memory and might benefit from things like
> zsmalloc/zram more) cannot use it, but SMP systems which tend to have
> more memory (unless we're talking about a frugal configuration of a
> virtual machine, perhaps). Given the myriad use cases of zram that is
> not a pervasive or persuasive argument, I know, but it does seem
> slightly backwards.
> 
> > If I don't miss something, we could have 2 choice.
> >
> > 1) use flush_tlb_kernel_range instead of local_flush_tlb_kernel_range
> > Or
> > 2) use only memory copy
> >
> > I guess everybody want 2 because it makes code very simple and maintainable.
> > Even, rencently Joonsoo sent optimize patch.
> > Look at https://lkml.org/lkml/2013/1/16/68 so zram/zcache effect caused by 2
> > would be minimized.
> >
> > But please give me the time and I will borrow quad-core embedded target board
> > and test 1 on the phone with Seth's benchmark.
> 
> In the meantime please take into account building a non-SMP kernel for
> this board and testing that; if there is a way to do the flush without
> using the particular function which uses the particular export that
> Russell will not export, then that would be better. Maybe for
> !CONFIG_SMP using flush_tlb_kernel_range is doing the exact same job
> and the real patch is not to disable the optimization with
> !CONFIG_SMP, but to additionally #if defined(CONFIG_SMP) around
> local_flush_tlb_kernel_range and alternatively for UP use
> flush_tlb_kernel_range which.. probably.. doesn't use that contentious
> export?
> 
> This is far beyond the level I want to be digging around in the Linux
> kernel so I am not comfortable even trying that to find out.
> 

How about this? Could you confirm it? If you confirm, I will send it
to stable, too.
Thanks!

>From 7e1f315bef3e1956a32665335c3f86321c069947 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan@kernel.org>
Date: Wed, 23 Jan 2013 00:28:02 +0900
Subject: [PATCH] Fix build error in !CONFIG_SMP and CONFIG_ARM

Matt Sealey reported he fail to build zsmalloc due to use of
local_flush_tlb_kernel_range which are architecture dependent
function so !CONFIG_SMP in ARM couldn't implement it so it ends up
build error.

  MODPOST 216 modules
  LZMA    arch/arm/boot/compressed/piggy.lzma
  AS      arch/arm/boot/compressed/lib1funcs.o
ERROR: "v7wbi_flush_kern_tlb_range"
[drivers/staging/zsmalloc/zsmalloc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs....

The reason we used that function is copy method by [1]
was really slow in ARM but at that time, we didn't check
local_flush_tlb_kernel_range and flush_tlb_kernel_range's
performance gap.

Today, my experiment in ARMv7 processor 4 core didn't make
any difference with zsmapbench[2] but still page-table based
is better than copy-based.

* bigger is better.

1. local_flush_tlb_kernel_range: 3918795 mappings
2. flush_tlb_kernel_range : 3989538 mappings
3. copy-based: 635158 mappings

This patch replace local_flush_tlb_kernel_range with
flush_tlb_kernel_range which are avaialbe in all architectures
because it is already used by vmalloc allocator which are generic one.
So build problem should go away and performane loss shoud be void.

[1] f553646, zsmalloc: add page table mapping method
[2] https://github.com/spartacus06/zsmapbench

Reported-by: Matt Sealey <matt@genesi-usa.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
 drivers/staging/zsmalloc/zsmalloc-main.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c b/drivers/staging/zsmalloc/zsmalloc-main.c
index eb00772..66aa4df 100644
--- a/drivers/staging/zsmalloc/zsmalloc-main.c
+++ b/drivers/staging/zsmalloc/zsmalloc-main.c
@@ -663,7 +663,7 @@ static inline void __zs_unmap_object(struct mapping_area *area,
 
 	flush_cache_vunmap(addr, end);
 	unmap_kernel_range_noflush(addr, PAGE_SIZE * 2);
-	local_flush_tlb_kernel_range(addr, end);
+	flush_tlb_kernel_range(addr, end);
 }
 
 #else /* USE_PGTABLE_MAPPING */
-- 
1.7.9.5


-- 
Kind regards,
Minchan Kim

^ permalink raw reply related

* [PATCH v7 09/15] gpio: pl061: set initcall level to module init
From: Dinh Nguyen @ 2013-01-22 15:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACRpkdbTZGEMScK34vCE8qw8Kwug1SNQv_G8-hCjTRjZFvVNZw@mail.gmail.com>

Hi Linus,

On Tue, 2013-01-22 at 10:44 +0100, Linus Walleij wrote:
> On Mon, Jan 21, 2013 at 9:20 PM, Dinh Nguyen <dinguyen@altera.com> wrote:
> 
> >> > Pawel, Dinh: are you OK with this change?
> >
> > Still works ok on mach-socfpga.
> 
> Thanks! Adding your Tested-by tag, OK?

Yep, thanks.

Dinh
> 
> Yours,
> Linus Walleij
> 

^ permalink raw reply

* [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
From: kishon @ 2013-01-22 15:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <2D906ABA-71F2-4843-9DBE-F82527A1240A@dominion.thruhere.net>

On Tuesday 22 January 2013 09:11 PM, Koen Kooi wrote:
>
> Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I <kishon@ti.com> het volgende geschreven:
>
>> This patch series adds support for adding multiple PHY's (of same type).
>> The binding information has to be present in the PHY library (otg.c) in
>> order for it to return the appropriate PHY whenever the USB controller
>> request for the PHY. So added a new API usb_bind_phy() to pass the binding
>> information. This API should be called by platform specific initialization
>> code.
>>
>> So the binding should be done something like
>> usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto"); specifying the USB
>> controller device name, index, and the PHY device name.
>> I have done this binding for OMAP platforms, but it should be done for
>> all the platforms.
>>
>> After this design, the phy can be got by passing the USB controller device
>> pointer and the index.
>>
>> Developed this patch series on
>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
>> after applying "usb: musb: add driver for control module" patch series
>> and "ARM: dts: omap: add dt data for MUSB"
>>
>> Did basic enumeration testing in omap4 panda and omap3 beagle.
>
> With this patchset USB completely breaks on am33xx beaglebone, is that intended?
Not really.
Does am33xx makes use of omap2430.c? Which PHY does am33xx uses?

Thanks
Kishon

^ permalink raw reply

* [PATCH 06/15] clk: export __clk_get_name
From: Arnd Bergmann @ 2013-01-22 15:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAOMZO5AON+FhTQpTbEdjwZaEaxsPoEVLeALhH2s34biWH_EeOA@mail.gmail.com>

On Tuesday 22 January 2013, Fabio Estevam wrote:
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Mike Turquette <mturquette@linaro.org>
> 
> A fix from Niels de Vos has already been applied into clk-next:
> https://patchwork.kernel.org/patch/1871981/

Ok, very good. Mike, I saw that the patch is over
a month old. Any reason it hasn't made it into v3.8.rc yet?

	Arnd

^ permalink raw reply

* [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
From: Koen Kooi @ 2013-01-22 15:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1358848694-20145-1-git-send-email-kishon@ti.com>


Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I <kishon@ti.com> het volgende geschreven:

> This patch series adds support for adding multiple PHY's (of same type).
> The binding information has to be present in the PHY library (otg.c) in
> order for it to return the appropriate PHY whenever the USB controller
> request for the PHY. So added a new API usb_bind_phy() to pass the binding
> information. This API should be called by platform specific initialization
> code.
> 
> So the binding should be done something like
> usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto"); specifying the USB
> controller device name, index, and the PHY device name.
> I have done this binding for OMAP platforms, but it should be done for
> all the platforms.
> 
> After this design, the phy can be got by passing the USB controller device
> pointer and the index.
> 
> Developed this patch series on
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
> after applying "usb: musb: add driver for control module" patch series
> and "ARM: dts: omap: add dt data for MUSB"
> 
> Did basic enumeration testing in omap4 panda and omap3 beagle.

With this patchset USB completely breaks on am33xx beaglebone, is that intended?

^ permalink raw reply

* [PATCH 09/15] media: coda: don't build on multiplatform
From: Arnd Bergmann @ 2013-01-22 15:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20130122082158.GC9414@pengutronix.de>

On Tuesday 22 January 2013, Sascha Hauer wrote:
> On Mon, Jan 21, 2013 at 05:16:02PM +0000, Arnd Bergmann wrote:
> > The coda video codec driver depends on a mach-imx or mach-mxs specific
> > header file "mach/iram.h". This is not available when building for
> > multiplatform, so let us disable this driver for v3.8 when building
> > multiplatform, and hopefully find a proper fix for v3.9.
> > 
> > drivers/media/platform/coda.c:27:23: fatal error: mach/iram.h: No such file or directory
> 
> I just sent a pull request for this with a proper fix.

Ok, even better. Thanks for taking care of it!

	Arnd

^ permalink raw reply

* [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
From: kishon @ 2013-01-22 15:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <50FEB275.80504@ti.com>

Hi,

On Tuesday 22 January 2013 09:08 PM, Peter Ujfalusi wrote:
> On 01/22/2013 04:21 PM, kishon wrote:
>> But it's better to check if deferred probing
>> takes place whenever a new driver is bound to a device as you just mentioned.
>
> Whenever you load (might be also when you unload) a driver the deferred
> modules will try to probe again. This is to check back if the dependency of
> the deferred modules has been fulfilled by the new driver or not.

Thanks Peter.

-Kishon

^ permalink raw reply

* [RFC PATCH v3 02/16] ARM: davinci: move private EDMA API to arm/common
From: Sekhar Nori @ 2013-01-22 15:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20130110235157.GU14660@beef>

Matt,

Sorry about the late reply. I noticed this mail only after I started to
look at v5 of your series :(

On 1/11/2013 5:21 AM, Matt Porter wrote:
> On Sun, Oct 28, 2012 at 01:47:09PM +0530, Sekhar Nori wrote:
>> On 10/18/2012 6:56 PM, Matt Porter wrote:
>>> Move mach-davinci/dma.c to common/edma.c so it can be used
>>> by OMAP (specifically AM33xx) as well. This just moves the
>>> private EDMA API but does not support OMAP.
>>>
>>> Signed-off-by: Matt Porter <mporter@ti.com>
>>> ---
>>
>>> diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
>>> index 4c48a36..f45d591 100644
>>> --- a/arch/arm/mach-davinci/devices.c
>>> +++ b/arch/arm/mach-davinci/devices.c
>>> @@ -19,9 +19,10 @@
>>>  #include <mach/irqs.h>
>>>  #include <mach/cputype.h>
>>>  #include <mach/mux.h>
>>> -#include <mach/edma.h>
>>>  #include <linux/platform_data/mmc-davinci.h>
>>>  #include <mach/time.h>
>>> +#include <linux/platform_data/edma.h>
>>
>> Can you please introduce a patch to clean this mixture of linux/ and
>> mach/ includes?
> 
> Yeah, are you ok with a follow on series to clean all these files? I
> don't want to make this series longer with something not dma related
> that's purely cleanup from the great header reorg of 2012.

Okay. I agree doing this sort of change now will cause merge issues.

> 
>>> +
>>>  
>>>  #include "davinci.h"
>>>  #include "clock.h"
>>> @@ -141,10 +142,10 @@ static struct resource mmcsd0_resources[] = {
>>>  	},
>>>  	/* DMA channels: RX, then TX */
>>>  	{
>>> -		.start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCRXEVT),
>>> +		.start = EDMA_CTLR_CHAN(0, 26),
>>
>> Instead of just replacing the event #defines with plain numbers, can you
>> introduce a mach-davinci local edma.h which can then be included in the
>> davinci platform files which refer to edma channel numbers?
> 
> Ok, so when I removed the old edma.h it was full of unused defines and
> we are left with just this one. If I introduced something like that it
> would be used in just one place here. and only for these two values.
> How about we just add a comment?

I prefer adding a local #define in this file. This will keep it
consistent with what is done in arch/arm/mach-davinci/dm365.c for
example. Same for the change in sound/soc/davinci/davinci-sffsdr.c

> 
>>
>>> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
>>> index 7cd56ed..153fab8 100644
>>> --- a/arch/arm/plat-omap/Kconfig
>>> +++ b/arch/arm/plat-omap/Kconfig
>>> @@ -28,6 +28,7 @@ config ARCH_OMAP2PLUS
>>>  	select OMAP_DM_TIMER
>>>  	select PROC_DEVICETREE if PROC_FS
>>>  	select SPARSE_IRQ
>>> +	select TI_PRIV_EDMA
>>
>> This hunk does not seem to belong to subject of this patch.
> 
> Let me reword the subject/description. The idea of this logical
> chunk was to put everything in place to make it build on OMAP,
> with the expectation that the build fails without the next patch
> in the series.

But this will break bisect. With just this patch applied, omap build
breaks. Looks like it will be more logical to merge this hunk with 3/14
since that's when you really start using the private DMA support on OMAP
platforms.

This issue is a must fix IMO.

I am ok with the patch otherwise. With these changes done, you can add:

Acked-by: Sekhar Nori <nsekhar@ti.com>

Thanks,
Sekhar

^ permalink raw reply

* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
From: Arnd Bergmann @ 2013-01-22 15:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1301221011190.1510-100000@iolanthe.rowland.org>

On Tuesday 22 January 2013, Alan Stern wrote:
> In order to prevent this, you have to make sure that each glue driver
> depends on USB_ARCH_HAS_EHCI.  A simple way to do this is to surround
> the Kconfig entries for those drivers with "if USB && 
> USB_ARCH_HAS_EHCI" ... "endif".

I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
as well once we have inverted the logic for selecting USB_EHCI_HCD,
but there is another problem with that, because then we still need
something to select USB_ARCH_HAS_HCD, or kill that symbol as well.

	Arnd

^ permalink raw reply

* [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
From: Peter Ujfalusi @ 2013-01-22 15:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <50FEAE96.30706@ti.com>

On 01/22/2013 04:21 PM, kishon wrote:
> But it's better to check if deferred probing
> takes place whenever a new driver is bound to a device as you just mentioned.

Whenever you load (might be also when you unload) a driver the deferred
modules will try to probe again. This is to check back if the dependency of
the deferred modules has been fulfilled by the new driver or not.

-- 
P?ter

^ permalink raw reply

* [PATCH v1 5/6] usb: otg: add device tree support to otg library
From: kishon @ 2013-01-22 15:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20130122103650.GB18876@e106331-lin.cambridge.arm.com>

Hi,

On Tuesday 22 January 2013 04:06 PM, Mark Rutland wrote:
>> +struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
>> +	const char *phandle, u8 index)
>> +{
>> +	struct usb_phy	*phy = NULL, **ptr;
>> +	unsigned long	flags;
>> +	struct device_node *node;
>> +
>> +	if (!dev->of_node) {
>> +		dev_dbg(dev, "device does not have a device node entry\n");
>> +		return ERR_PTR(-EINVAL);
>> +	}
>> +
>> +	node = of_parse_phandle(dev->of_node, phandle, index);
>> +	if (!node) {
>> +		dev_dbg(dev, "failed to get %s phandle in %s node\n", phandle,
>> +			dev->of_node->full_name);
>> +		return ERR_PTR(-ENODEV);
>> +	}
>
> At any point past this, node's refcount is incremented (done automatically by
> of_parse_phandle => of_find_node_by_phandle).
>
>> +
>> +	ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
>> +	if (!ptr) {
>> +		dev_dbg(dev, "failed to allocate memory for devres\n");
>> +		return ERR_PTR(-ENOMEM);
>> +	}
>> +
>> +	spin_lock_irqsave(&phy_lock, flags);
>> +
>> +	phy = __of_usb_find_phy(node);
>> +	if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
>> +		phy = ERR_PTR(-EPROBE_DEFER);
>> +		devres_free(ptr);
>> +		goto err0;
>> +	}
>> +
>> +	*ptr = phy;
>> +	devres_add(dev, ptr);
>> +
>> +	get_device(phy->dev);
>> +
>> +err0:
>> +	spin_unlock_irqrestore(&phy_lock, flags);
>> +
>> +	return phy;
>> +}
>
> This means that on all of the exit paths, node's refcount is left incremented
> incorrectly. You'll need an of_node_put(node) on each exit path.

Ok. Will fix it.

Thanks
Kishon

^ permalink raw reply

* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
From: Alan Stern @ 2013-01-22 15:30 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20130122061116.GD29677@S2100-06.ap.freescale.net>

On Tue, 22 Jan 2013, Shawn Guo wrote:

> On Mon, Jan 21, 2013 at 09:37:42PM +0000, Arnd Bergmann wrote:
> > > Arnd, please take a look at
> > > 
> > >         http://marc.info/?l=linux-usb&amp;m=135843716515529&amp;w=2
> > > 
> > > I can't test it easily, not being set up for cross compilation.  I'm 
> > > waiting to hear from anybody whether it works before submitting it.
> > > (There's also a report of memory corruption involving a similar patch 
> > > for ehci-omap; it hasn't been tracked down yet.)
> > 
> > Your patch looks good to me, but it also seems to do some other
> > changes that are not required to fix the problem but could wait
> > for 3.9 instead. You definitely have my Ack if you are willing
> > to take it for 3.8 though.

I think it's not too late to submit this for 3.8.  Thanks for the Ack.

> > Shawn or Sascha should be able to test it.
> > 
> Alan,
> 
> Thanks for the patch.  I just gave it try.  The USB Host port still
> works for me with a couple of fixes on your changes integrated (one
> for compiling and the other for probing).  So you have my ACK with
> the changes below rolled into your patch.

Right, I have merged your changes into the patch.  Will submit shortly.

Alan Stern

^ permalink raw reply

* [PATCH] net: fec: Add support for multiple phys on mdiobus
From: Wolfgang Grandegger @ 2013-01-22 15:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <50FEAE12.7090307@openwrt.org>

On 01/22/2013 04:19 PM, Florian Fainelli wrote:
> On 01/22/2013 04:03 PM, Wolfgang Grandegger wrote:
>> On 01/22/2013 03:47 PM, Florian Fainelli wrote:
>>> On 01/22/2013 08:22 AM, Wolfgang Grandegger wrote:
>>>>> Well this could be done when the fixed phy driver could be registered
>>>>> with the devicetree, maybe like this:
>>>>>
>>>>>      fixed-phy: mdiophy {
>>>>>          compatible = "mdio-fixed-phy";
>>>>>          link = "100FD";
>>>>>      };
>>>> I find that confusing. There is *no* phy but just a fixed link to the
>>>> switch...
>>>>
>>>>> The good thing about this would be that every ethernet driver could
>>>>> just
>>>>> use such a fixed phy, any external mdio phy (like on Marvell
>>>>> Armada) or
>>>>> just a phy connected to the internal mdio interface provided by the
>>>>> ethernet
>>>>> core.
>>>> What is wrong with the existing "fixed-link" property of the *ethernet*
>>>> node. The fixed-link handling should/could be done in the phy layer,
>>>> and
>>>> not in the driver as it currently is implemented. Maybe that's the
>>>> reason why the current code is regarded as hack!
>>> As far as I have used it with the CPMAC driver, the fixed PHY is a
>>> specific PHY device and there is no specific handling to be done by the
>>> Ethernet MAC driver but eventually changing its MII bus id so that it is
>>> named "fixed-0" to allow the fixed PHY driver to bind. Put differently,
>> There is special handling for the fixed link, e.g. here:
>>
>> http://lxr.linux.no/#linux+v3.7.4/drivers/net/ethernet/freescale/gianfar.c#L1462
>>
>>
>> This could be hidden in the PHY layer allowing all ethernet drivers
>> using the "fixed-link" property.
> 
> Ok, so in the end you could have potentially an ethernet PHY node
> containing the following properties:
> - fixed-link
> - fixed-speed
> - fixed-duplex
> 
> and treat it as a fixed-phy. If so, this would be pretty handy.

The "fixed-link" property already allows to specify speed, duplex, etc.:

http://lxr.linux.no/#linux+v3.7.4/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt#L48

Wolfgang.

^ permalink raw reply

* [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
From: kishon @ 2013-01-22 15:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <50FEA696.8000506@ti.com>

On Tuesday 22 January 2013 08:17 PM, Roger Quadros wrote:
> On 01/22/2013 04:37 PM, kishon wrote:
>> On Tuesday 22 January 2013 07:47 PM, Roger Quadros wrote:
>>> On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
>>>> The OMAP glue has been modified to get PHY by phandle for dt boot.
>>>>
>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>> ---
>>>>    drivers/usb/musb/omap2430.c |    7 ++++++-
>>>>    1 file changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>>>> index 1a8cf6d..e43faeb 100644
>>>> --- a/drivers/usb/musb/omap2430.c
>>>> +++ b/drivers/usb/musb/omap2430.c
>>>> @@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
>>>>         * up through ULPI.  TWL4030-family PMICs include one,
>>>>         * which needs a driver, drivers aren't always needed.
>>>>         */
>>>> -    musb->xceiv = devm_usb_get_phy_dev(dev, 0);
>>>> +    if (dev->parent->of_node)
>>>> +        musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
>>>> +            "usb_phy", 0);
>>>> +    else
>>>> +        musb->xceiv = devm_usb_get_phy_dev(dev, 0);
>>>> +
>>>>        if (IS_ERR_OR_NULL(musb->xceiv)) {
>>>>            pr_err("HS USB OTG: no transceiver configured\n");
>>>>            return -ENODEV;
>>>
>>> This will not work with PHY driver as a module. You need to use deferred probing mechanism here
>>> after you have addressed my comment in patch 2 and also devm_usb_get_phy_by_phandle()
>>
>> IIUC, even using -EPROBE_DEFER might not help if we are making the PHY driver as module, since the kernel will try to probe only till the prompt comes.
>>
> Oh really? I thought deferred probing takes place whenever a new driver is bound to a device.
You might also be right. I'm not so sure.

What does "prompt comes" have to do with it?

I just meant end of boot process. But it's better to check if deferred 
probing takes place whenever a new driver is bound to a device as you 
just mentioned.

Thanks
Kishon

^ permalink raw reply

* [PATCH] net: fec: Add support for multiple phys on mdiobus
From: Florian Fainelli @ 2013-01-22 15:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <50FEAA28.1070003@grandegger.com>

On 01/22/2013 04:03 PM, Wolfgang Grandegger wrote:
> On 01/22/2013 03:47 PM, Florian Fainelli wrote:
>> On 01/22/2013 08:22 AM, Wolfgang Grandegger wrote:
>>>> Well this could be done when the fixed phy driver could be registered
>>>> with the devicetree, maybe like this:
>>>>
>>>>      fixed-phy: mdiophy {
>>>>          compatible = "mdio-fixed-phy";
>>>>          link = "100FD";
>>>>      };
>>> I find that confusing. There is *no* phy but just a fixed link to the
>>> switch...
>>>
>>>> The good thing about this would be that every ethernet driver could just
>>>> use such a fixed phy, any external mdio phy (like on Marvell Armada) or
>>>> just a phy connected to the internal mdio interface provided by the
>>>> ethernet
>>>> core.
>>> What is wrong with the existing "fixed-link" property of the *ethernet*
>>> node. The fixed-link handling should/could be done in the phy layer, and
>>> not in the driver as it currently is implemented. Maybe that's the
>>> reason why the current code is regarded as hack!
>> As far as I have used it with the CPMAC driver, the fixed PHY is a
>> specific PHY device and there is no specific handling to be done by the
>> Ethernet MAC driver but eventually changing its MII bus id so that it is
>> named "fixed-0" to allow the fixed PHY driver to bind. Put differently,
> There is special handling for the fixed link, e.g. here:
>
> http://lxr.linux.no/#linux+v3.7.4/drivers/net/ethernet/freescale/gianfar.c#L1462
>
> This could be hidden in the PHY layer allowing all ethernet drivers
> using the "fixed-link" property.

Ok, so in the end you could have potentially an ethernet PHY node 
containing the following properties:
- fixed-link
- fixed-speed
- fixed-duplex

and treat it as a fixed-phy. If so, this would be pretty handy.

>
>> using the fixed PHY driver is a kind of "last" resort thing to cope with
>> situations like:
>>
>> - switch not providing a consistent PHY-like interface on the MDC/MDIO bus
>> - switches not connected to the MDC/MDIO bus of the Ethernet MAC they
>> forward to
>>
>> What exactly do you mean by "as it currently is implemented"? that you
>> do not like?
> As Sascha pointed out, the implementation is labeled as "hack", which
> should be fixed sooner than later. It's just not clear why ;).
>
> Wolfgang.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox