* [PATCH 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Catalin Marinas @ 2013-01-25 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125043039.GN13691@verge.net.au>
On Fri, Jan 25, 2013 at 04:30:39AM +0000, Simon Horman wrote:
> On Wed, Jan 23, 2013 at 05:59:34PM +0000, Catalin Marinas wrote:
> > All the calls to gic_secondary_init() pass 0 as the first argument.
> > Since this function is called on each CPU when starting, it can be done
> > in a platform-independent way via a CPU notifier registered by the GIC
> > code.
> >
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Kukjin Kim <kgene.kim@samsung.com>
> > Cc: Rob Herring <rob.herring@calxeda.com>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: David Brown <davidb@codeaurora.org>
> > Cc: Daniel Walker <dwalker@fifo99.com>
> > Cc: Bryan Huntsman <bryanh@codeaurora.org>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Simon Horman <horms@verge.net.au>
> > Cc: Magnus Damm <magnus.damm@gmail.com>
> > Cc: Dinh Nguyen <dinguyen@altera.com>
> > Cc: Viresh Kumar <viresh.linux@gmail.com>
> > Cc: Shiraz Hashim <shiraz.hashim@st.com>
> > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
>
> mach-shmobile portion:
>
> Acked-by: Simon Horman <horms+renesas@verge.net.au>
>
> For the record, I tested this on the kzm9g, kzm9d and marzen boards
> which use the r8a7779, EMEV2 and r8a7779 SoCs respectively.
Thanks. Can I add a Tested-by as well?
--
Catalin
^ permalink raw reply
* [PATCH 0/3] ARM: shmobile: sh-eth pins in DT for armadillo800eva
From: Simon Horman @ 2013-01-25 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1301250856040.17518@axis700.grange>
On Fri, Jan 25, 2013 at 09:09:54AM +0100, Guennadi Liakhovetski wrote:
> Hi Simon
>
> On Fri, 25 Jan 2013, Simon Horman wrote:
>
> > On Thu, Jan 24, 2013 at 05:07:30PM +0100, Guennadi Liakhovetski wrote:
> > > This patch series gets rid of gpio_request()-style ethernet pin
> > > configuration on armadillo800eva in reference implementation.
> >
> > Hi Guennadi,
> >
> > these changes seem to be reasonable to me.
> >
> > Are there any dependencies for the sh_eth patch?
> > I assume this will be handled by David Miller through the net-next tree.
> > Are there any dependencies? The last time I checked the DT bindings
> > for sh_eth had not been merged.
>
> Obviously, it can only be applied, if the
> Documentation/devicetree/bindings/net/sh_ether.txt file and the
> sh_eth_parse_dt() function exist. Also, if there are no objections against
> the new phy-reset-gpios DT property. Otherwise there are no dependencies -
> as long as the phy-reset-gpios property isn't found in DT, the patch
> doesn't affect the driver.
Thanks, I'm slightly concerned that the other patch(es) relating
to Documentation/devicetree/bindings/net/sh_ether.txt have gone missing in
action.
Do you have an interest in chasing them down or would you like me to?
> > For the remaining two patches, which I assume will go through my renesas
> > tree:
> > * Are there any dependencies that aren't satisfied by the of-intc branch?
>
> AFAICS, that your branch doesn't contain Laurent's pinctrl patches, which
> are needed for patch 1 to apply and for patch 3 to make sense. My earlier
> MMC DT / pinctrl patches aren't required for these patches to function,
> but these patches won't apply cleanly without them, since they touch the
> same code fragments. So, it would be easier to merge them in the order of
> submission.
>
> > * Could you get some Acks. At least from Laurent?
>
> Sure, let's give reviewers some more time :)
Indeed.
Laurent, if there are patches ready for me to take into the renesas tree
please let me know. I'm reluctant to add any more pinmux changes for 3.9.
But if a topic branch would help let me know.
^ permalink raw reply
* [PATCHv2] ARM: mxs: dt: Add Crystalfontz CFA-10037 device tree support
From: Maxime Ripard @ 2013-01-25 9:00 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/Makefile | 1 +
arch/arm/boot/dts/imx28-cfa10037.dts | 77 ++++++++++++++++++++++++++++++++++
arch/arm/mach-mxs/mach-mxs.c | 8 ++++
3 files changed, 86 insertions(+)
create mode 100644 arch/arm/boot/dts/imx28-cfa10037.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e44da40..f9912f6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -95,6 +95,7 @@ dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
imx28-apf28dev.dtb \
imx28-apx4devkit.dtb \
imx28-cfa10036.dtb \
+ imx28-cfa10037.dtb \
imx28-cfa10049.dtb \
imx28-evk.dtb \
imx28-m28evk.dtb \
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 = <®_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/3] ARM: dts: mxs: Add the LCD to the 10049 board
From: Maxime Ripard @ 2013-01-25 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359104048-26823-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-25 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359104048-26823-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-25 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359104048-26823-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
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..00925c0
--- /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_MODE 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 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_OUT_INIT_LOW, "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 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 = 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
* [PATCHv2 0/3] Add framebuffer support to the CFA-10049
From: Maxime Ripard @ 2013-01-25 8:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
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
Changes from v1:
- Fixed typos and minor changes
- Removed the __devinit/__devexit
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
* [BUG] panda board locks up on boot
From: Russell King - ARM Linux @ 2013-01-25 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359082886.21576.199.camel@gandalf.local.home>
On Thu, Jan 24, 2013 at 10:01:26PM -0500, Steven Rostedt wrote:
> I've recently started testing my work on arm boards and have found that
> they both don't boot under the latest kernel anymore. I already posted
> about my snowball board, but my panda board also locks up.
You need to enable DMA engine and the OMAP DMA engine driver. I believe
someone was going to work on adding PIO-mode support to the driver but
I suspect as TI's OMAP division is being reorganized, all that is now
uncertain.
^ permalink raw reply
* [PATCH v3 2/3] gpio: pca953x: add support for pca9505
From: Linus Walleij @ 2013-01-25 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51024422.2060503@free-electrons.com>
On Fri, Jan 25, 2013 at 9:36 AM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Well, at the beginning I thought adding support for pca9505 was just a matter
> of a couple of lines to add. Then I realized that I need to handle the 40 bits
> case, and I ended up refactoring all access to the registers. So now I am on it,
> it seems I am volunteer to continue to improve this driver.
I like the sound of this ;-)
To get you started I just sent out two other patches you can consider
as RFC, they're regrettably not even compile-tested. I mainly wanted
to indicate what needs to be done so we can throw them away, just
wanted to give a hint.
> However I won't be able to test it, the only PXA based platform I have is a
> Zaurus SL-C3100 which embeds a PXA270 if I remember well, but I doubt it come
> with gpio expander on i2c.
Well I guess if there is nobody testing it, then nobody cares.
The world must be full of people with PXA platforms doing nothing
but regression testing...
Actually just days ago I asked Haoijan to help me testing a set of
patches for the PXA SPI controller, and he kindly helped out, so there
are some people booting these platforms, sometimes :-)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 1/4] drivers: usb: phy: add a new driver for usb part of control module
From: kishon @ 2013-01-25 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125084501.GI15886@arwen.pp.htv.fi>
On Friday 25 January 2013 02:15 PM, Felipe Balbi wrote:
> hi,
>
> On Fri, Jan 25, 2013 at 02:12:41PM +0530, kishon wrote:
>> On Friday 25 January 2013 01:18 PM, Felipe Balbi wrote:
>>> On Thu, Jan 24, 2013 at 09:32:46PM -0800, Stephen Warren wrote:
>>>> On 01/24/2013 06:19 PM, Kishon Vijay Abraham I wrote:
>>>>> Added a new driver for the usb part of control module. This has an API
>>>>> to power on the USB2 phy and an API to write to the mailbox depending on
>>>>> whether MUSB has to act in host mode or in device mode.
>>>>>
>>>>> Writing to control module registers for doing the above task which was
>>>>> previously done in omap glue and in omap-usb2 phy will be removed.
>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
>>>>
>>>> This file seems to be specific to the TI USB PHYs, not all USB PHYs;
>>>> shouldn't it be renamed ti-usb-phy.txt, or even better renamed to match
>>>> the compatible value it documents, giving ti,omap-usb2.txt?
>>>
>>> could be, but that can be done as a separate patch. It's not part of
>>> $SUBJECT.
>>>
>>>>> add the address of control module dev conf register until a driver for
>>>>> control module is added
>>>>>
>>>>> +Optional properties:
>>>>> + - ctrl_module : phandle of the control module used by PHY driver to power on
>>>>> + the PHY.
>>>>
>>>> DT property names generally use - not _ as the word separator.
>>>
>>> fair enough, Kishon, can you fix this up ?
>>
>> Sure. Will post a patch..
>
> Great, notice that I've already applied some of your patches to my tree.
>
Cool. Thanks :-)
Regards
Kishon
^ permalink raw reply
* [PATCH v3 1/4] drivers: usb: phy: add a new driver for usb part of control module
From: Felipe Balbi @ 2013-01-25 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51024581.6020301@ti.com>
hi,
On Fri, Jan 25, 2013 at 02:12:41PM +0530, kishon wrote:
> On Friday 25 January 2013 01:18 PM, Felipe Balbi wrote:
> >On Thu, Jan 24, 2013 at 09:32:46PM -0800, Stephen Warren wrote:
> >>On 01/24/2013 06:19 PM, Kishon Vijay Abraham I wrote:
> >>>Added a new driver for the usb part of control module. This has an API
> >>>to power on the USB2 phy and an API to write to the mailbox depending on
> >>>whether MUSB has to act in host mode or in device mode.
> >>>
> >>>Writing to control module registers for doing the above task which was
> >>>previously done in omap glue and in omap-usb2 phy will be removed.
> >>
> >>>diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
> >>
> >>This file seems to be specific to the TI USB PHYs, not all USB PHYs;
> >>shouldn't it be renamed ti-usb-phy.txt, or even better renamed to match
> >>the compatible value it documents, giving ti,omap-usb2.txt?
> >
> >could be, but that can be done as a separate patch. It's not part of
> >$SUBJECT.
> >
> >>> add the address of control module dev conf register until a driver for
> >>> control module is added
> >>>
> >>>+Optional properties:
> >>>+ - ctrl_module : phandle of the control module used by PHY driver to power on
> >>>+ the PHY.
> >>
> >>DT property names generally use - not _ as the word separator.
> >
> >fair enough, Kishon, can you fix this up ?
>
> Sure. Will post a patch..
Great, notice that I've already applied some of your patches to my tree.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130125/e0bd2cfb/attachment.sig>
^ permalink raw reply
* [PATCH 2/4] ARM: OMAP2+: dpll: am335x - avoid freqsel
From: Paul Walmsley @ 2013-01-25 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0be0227b6b07a8c16b13a06fe500694c751827c.1358871018.git.afzal@ti.com>
On Tue, 22 Jan 2013, Afzal Mohammed wrote:
> am335x does not have freqsel, avoid it.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
Thanks, queued for 3.9.
- Paul
^ permalink raw reply
* [BUG] panda board locks up on boot
From: Mats Liljegren @ 2013-01-25 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51022FD2.8090101@compulab.co.il>
Hi Steven,
Do you have CONFIG_CPU_FREQ enabled? As I posted earlier in linux-kernel forum ("Failed booting PandaBoard ES with Linux 3.8 RC4" two days ago) my PandaBoard ES hangs while booting with this option enabled. It works fine without it. I have not bisected it down to a single commit though.
/Mats
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner at vger.kernel.org] On Behalf Of Igor Grinberg
Sent: den 25 januari 2013 08:10
To: Steven Rostedt
Cc: LKML; linux-arm-kernel; Tony Lindgren; Russell King; Venkatraman S
Subject: Re: [BUG] panda board locks up on boot
Hi Steven,
On 01/25/13 05:01, Steven Rostedt wrote:
> I've recently started testing my work on arm boards and have found
> that they both don't boot under the latest kernel anymore. I already
> posted about my snowball board, but my panda board also locks up.
>
> I've bisected it down to this commit:
>
> commit 26b88520b80695a6fa5fd95b5d97c03f4daf87e0
> Author: Russell King <rmk+kernel@arm.linux.org.uk>
> Date: Fri Apr 13 12:27:37 2012 +0100
>
> mmc: omap_hsmmc: remove private DMA API implementation
>
> Remove the private DMA API implementation from omap_hsmmc, making it
> use entirely the DMA engine API.
>
> Tested-by: Tony Lindgren <tony@atomide.com>
> Tested-by: Venkatraman S <svenkatr@ti.com>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
>
> The commit before boots fine, when adding this commit, it locks up.
>
> I reverted the commit (with tweaks) against 3.8-rc4 and was able to
> get my board booting again. Not sure what to do, but I wanted to let
> people know.
Care to post your kernel config file?
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH v3 1/4] drivers: usb: phy: add a new driver for usb part of control module
From: kishon @ 2013-01-25 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125074818.GF15886@arwen.pp.htv.fi>
On Friday 25 January 2013 01:18 PM, Felipe Balbi wrote:
> On Thu, Jan 24, 2013 at 09:32:46PM -0800, Stephen Warren wrote:
>> On 01/24/2013 06:19 PM, Kishon Vijay Abraham I wrote:
>>> Added a new driver for the usb part of control module. This has an API
>>> to power on the USB2 phy and an API to write to the mailbox depending on
>>> whether MUSB has to act in host mode or in device mode.
>>>
>>> Writing to control module registers for doing the above task which was
>>> previously done in omap glue and in omap-usb2 phy will be removed.
>>
>>> diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
>>
>> This file seems to be specific to the TI USB PHYs, not all USB PHYs;
>> shouldn't it be renamed ti-usb-phy.txt, or even better renamed to match
>> the compatible value it documents, giving ti,omap-usb2.txt?
>
> could be, but that can be done as a separate patch. It's not part of
> $SUBJECT.
>
>>> add the address of control module dev conf register until a driver for
>>> control module is added
>>>
>>> +Optional properties:
>>> + - ctrl_module : phandle of the control module used by PHY driver to power on
>>> + the PHY.
>>
>> DT property names generally use - not _ as the word separator.
>
> fair enough, Kishon, can you fix this up ?
Sure. Will post a patch..
Thanks
Kishon
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Paul Walmsley @ 2013-01-25 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433ECFA0FC@DBDE01.ent.ti.com>
Hi,
On Thu, 24 Jan 2013, Bedia, Vaibhav wrote:
> Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK or
> just skip earlyprintk option in the bootargs for now?
I'll give this a try over the next few days.
If EARLY_PRINTK is known to be broken for DT boots, could you please put
together a Kconfig patch that prevents either EARLY_PRINTK from being
selected when a DT-only board is selected, or vice-versa?
- Paul
^ permalink raw reply
* [PATCH 2/2] ARM: dts: cfa10049: Change the SPI3 bus to spi-gpio
From: Maxime Ripard @ 2013-01-25 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359103175-26304-1-git-send-email-maxime.ripard@free-electrons.com>
The DAC found on the last chip select requires a word length of 12 bits,
which is not supported by the SSP controller of the iMX28. Use
bitbanging for that bus to support such a length.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/imx28-cfa10049.dts | 78 ++++++++++++++++++----------------
1 file changed, 42 insertions(+), 36 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index 7890acc..dd91244 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -52,48 +52,17 @@
spi3_pins_cfa10049: spi3-cfa10049 at 0 {
reg = <0>;
fsl,pinmux-ids = <
- 0x0181 /* MX28_PAD_GPMI_RDN__SSP3_SCK */
- 0x01c1 /* MX28_PAD_GPMI_RESETN__SSP3_CMD */
- 0x0111 /* MX28_PAD_GPMI_CE1N__SSP3_D3 */
- 0x01a2 /* MX28_PAD_GPMI_ALE__SSP3_D4 */
- 0x01b2 /* MX28_PAD_GPMI_CLE__SSP3_D5 */
+ 0x0183 /* MX28_PAD_GPMI_RDN__GPIO_0_24 */
+ 0x01c3 /* MX28_PAD_GPMI_RESETN__GPIO_0_28 */
+ 0x0113 /* MX28_PAD_GPMI_CE1N__GPIO_0_17 */
+ 0x01a3 /* MX28_PAD_GPMI_ALE__GPIO_0_26 */
+ 0x01b3 /* MX28_PAD_GPMI_CLE__GPIO_0_27 */
>;
fsl,drive-strength = <1>;
fsl,voltage = <1>;
fsl,pull-up = <1>;
};
};
-
- ssp3: ssp at 80016000 {
- compatible = "fsl,imx28-spi";
- pinctrl-names = "default";
- pinctrl-0 = <&spi3_pins_cfa10049>;
- status = "okay";
-
- gpio5: gpio5 at 0 {
- compatible = "fairchild,74hc595";
- gpio-controller;
- #gpio-cells = <2>;
- reg = <0>;
- registers-number = <2>;
- spi-max-frequency = <100000>;
- };
-
- gpio6: gpio6 at 1 {
- compatible = "fairchild,74hc595";
- gpio-controller;
- #gpio-cells = <2>;
- reg = <1>;
- registers-number = <4>;
- spi-max-frequency = <100000>;
- };
-
- dac0: dh2228 at 2 {
- compatible = "rohm,dh2228fv";
- reg = <2>;
- spi-max-frequency = <100000>;
- };
- };
};
apbx at 80040000 {
@@ -177,4 +146,41 @@
status = "okay";
};
};
+
+ spi3 {
+ compatible = "spi-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi3_pins_cfa10049>;
+ status = "okay";
+ gpio-sck = <&gpio0 24 0>;
+ gpio-mosi = <&gpio0 28 0>;
+ cs-gpios = <&gpio0 17 0 &gpio0 26 0 &gpio0 27 0>;
+ num-chipselects = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio5: gpio5 at 0 {
+ compatible = "fairchild,74hc595";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0>;
+ registers-number = <2>;
+ spi-max-frequency = <100000>;
+ };
+
+ gpio6: gpio6 at 1 {
+ compatible = "fairchild,74hc595";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <1>;
+ registers-number = <4>;
+ spi-max-frequency = <100000>;
+ };
+
+ dac0: dh2228 at 2 {
+ compatible = "rohm,dh2228fv";
+ reg = <2>;
+ spi-max-frequency = <100000>;
+ };
+ };
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] spi: spi-gpio: Add checks for the dt properties
From: Maxime Ripard @ 2013-01-25 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359103175-26304-1-git-send-email-maxime.ripard@free-electrons.com>
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.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
drivers/spi/spi-gpio.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index c7cf0b7..9ddef55 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -365,9 +365,26 @@ static int spi_gpio_probe_dt(struct platform_device *pdev)
if (!pdata)
return -ENOMEM;
- pdata->sck = of_get_named_gpio(np, "gpio-sck", 0);
- pdata->miso = of_get_named_gpio(np, "gpio-miso", 0);
- pdata->mosi = of_get_named_gpio(np, "gpio-mosi", 0);
+ ret = of_get_named_gpio(np, "gpio-sck", 0);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "gpio-sck property not found\n");
+ goto error_free;
+ }
+ pdata->sck = ret;
+
+ ret = of_get_named_gpio(np, "gpio-miso", 0);
+ if (ret < 0) {
+ dev_info(&pdev->dev, "gpio-miso property not found, switching to no-rx mode\n");
+ pdata->miso = SPI_GPIO_NO_MISO;
+ } else
+ pdata->miso = ret;
+
+ ret = of_get_named_gpio(np, "gpio-mosi", 0);
+ if (ret < 0) {
+ dev_info(&pdev->dev, "gpio-mosi property not found, switching to no-tx mode\n");
+ pdata->mosi = SPI_GPIO_NO_MOSI;
+ } else
+ pdata->mosi = ret;
ret = of_property_read_u32(np, "num-chipselects", &tmp);
if (ret < 0) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH RESEND 0/2] CFA10036: Switch to SPI Bitbanging
From: Maxime Ripard @ 2013-01-25 8:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is a patchset that moves the spi bus we use to bitbanging. This is needed
because the DAC found on this bus is actually using a 12 bits wordlength, while
the imx28 spi controler can only handle 4, 8 or 16 bits per words.
Thanks,
Maxime
Maxime Ripard (2):
spi: spi-gpio: Add checks for the dt properties
ARM: dts: cfa10049: Change the SPI3 bus to spi-gpio
arch/arm/boot/dts/imx28-cfa10049.dts | 78 ++++++++++++++++++----------------
drivers/spi/spi-gpio.c | 23 ++++++++--
2 files changed, 62 insertions(+), 39 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH v3 2/3] gpio: pca953x: add support for pca9505
From: Gregory CLEMENT @ 2013-01-25 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda-N0GrKOeaz4Hji0ef9pSRNPCxW_jLGR28iX-sk0-=tg@mail.gmail.com>
On 01/25/2013 09:16 AM, Linus Walleij wrote:
> On Tue, Jan 22, 2013 at 10:10 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>
>> Now that pca953x driver can handle GPIO expanders with more than 32
>> bits this patch adds the support for the pca9505 which cam with 40
>> GPIOs.
>>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> Patch applied, thanks.
>
> But guys, this driver contains some horrific stuff, look at this:
>
> static int pxa_gpio_nums(void)
> {
> int count = 0;
>
> #ifdef CONFIG_ARCH_PXA
> if (cpu_is_pxa25x()) {
> #ifdef CONFIG_CPU_PXA26x
> count = 89;
> gpio_type = PXA26X_GPIO;
> #elif defined(CONFIG_PXA25x)
> count = 84;
> gpio_type = PXA26X_GPIO;
> #endif /* CONFIG_CPU_PXA26x */
> } else if (cpu_is_pxa27x()) {
> count = 120;
> gpio_type = PXA27X_GPIO;
> } else if (cpu_is_pxa93x()) {
> count = 191;
> gpio_type = PXA93X_GPIO;
> } else if (cpu_is_pxa3xx()) {
> count = 127;
> gpio_type = PXA3XX_GPIO;
> }
> #endif /* CONFIG_ARCH_PXA */
>
> #ifdef CONFIG_ARCH_MMP
> if (cpu_is_pxa168() || cpu_is_pxa910()) {
> count = 127;
> gpio_type = MMP_GPIO;
> } else if (cpu_is_mmp2()) {
> count = 191;
> gpio_type = MMP_GPIO;
> }
> #endif /* CONFIG_ARCH_MMP */
> return count;
> }
>
> This is totally killing all attempts at a single kernel for multiple
> machines in this family. The above should not be #ifdef's but instead
> use either platform data or the compatible property to figure out which
> one to use.
>
> It's fine to introduce new compatible= strings or device names to
> distinguish between these.
>
> As an example, in pinctrl-nomadik.c we have this:
>
> static const struct of_device_id nmk_pinctrl_match[] = {
> {
> .compatible = "stericsson,nmk_pinctrl",
> .data = (void *)PINCTRL_NMK_DB8500,
> },
> {},
> };
>
> static const struct platform_device_id nmk_pinctrl_id[] = {
> { "pinctrl-stn8815", PINCTRL_NMK_STN8815 },
> { "pinctrl-db8500", PINCTRL_NMK_DB8500 },
> { "pinctrl-db8540", PINCTRL_NMK_DB8540 },
> { }
> };
>
> static struct platform_driver nmk_pinctrl_driver = {
> .driver = {
> .owner = THIS_MODULE,
> .name = "pinctrl-nomadik",
> .of_match_table = nmk_pinctrl_match,
> },
> .probe = nmk_pinctrl_probe,
> .id_table = nmk_pinctrl_id,
> };
>
>
> The first match is for DT boot the latter for using the platform
> device name directly.
>
> Then in the probefunction we do:
>
> static int nmk_pinctrl_probe(struct platform_device *pdev)
> {
> const struct platform_device_id *platid = platform_get_device_id(pdev);
> (...)
> if (platid)
> version = platid->driver_data;
> else if (np) {
> const struct of_device_id *match;
>
> match = of_match_device(nmk_pinctrl_match, &pdev->dev);
> if (!match)
> return -ENODEV;
> version = (unsigned int) match->data;
> }
> (...)
> if (version == PINCTRL_NMK_STN8815)
> nmk_pinctrl_stn8815_init(&npct->soc);
> if (version == PINCTRL_NMK_DB8500)
> nmk_pinctrl_db8500_init(&npct->soc);
> if (version == PINCTRL_NMK_DB8540)
> nmk_pinctrl_db8540_init(&npct->soc);
> }
>
> Surely a scheme like this must be possible to use to distinguish between
> the different versions at runtime rather than using these #ifdefs?
>
Well, at the beginning I thought adding support for pca9505 was just a matter
of a couple of lines to add. Then I realized that I need to handle the 40 bits
case, and I ended up refactoring all access to the registers. So now I am on it,
it seems I am volunteer to continue to improve this driver.
However I won't be able to test it, the only PXA based platform I have is a
Zaurus SL-C3100 which embeds a PXA270 if I remember well, but I doubt it come
with gpio expander on i2c.
Gregory
^ permalink raw reply
* [PATCH 1/2] ARM: dts: omap3-overo: Add support for pwm-leds
From: Peter Ujfalusi @ 2013-01-25 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5101A43D.7080108@epfl.ch>
On 01/24/2013 10:14 PM, Florian Vaussard wrote:
> You are right. But then the pwm core must provide a way to know if the pwm
> access function are callable
> from atomic context or not (the gpio framework provides gpio_cansleep()).
> This implies a good amount of changes to the pwm framework, and currently we
> are the only driver using non-atomic access.
We have two drivers at the moment: pwm-twl and pwm-twl-led. However new out of
SoC PWM drivers might come (for example for palmas). So it worth take a look
at some generic implementation.
--
P?ter
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Paul Walmsley @ 2013-01-25 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358846666.3996.3.camel@coredoba.hi.pengutronix.de>
Hello Jan,
On Tue, 22 Jan 2013, Jan L?bbe wrote:
> Just a guess, but there can be problems when the appended DTB crosses an
> 1MB boundary. See this mail for details and a patch:
> http://www.spinics.net/lists/arm-kernel/msg216898.html
Thanks for the suggestion. That patch didn't fix it for me.
- Paul
^ permalink raw reply
* [PATCH v2 1/4] ARM: OMAP2+: dpll: round rate to closest value
From: Paul Walmsley @ 2013-01-25 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <871e6890897534b6c3669e252f23bef5ff1247b6.1358937533.git.afzal@ti.com>
Hi
On Wed, 23 Jan 2013, Afzal Mohammed wrote:
> Currently round rate function would return proper rate iff requested
> rate exactly matches the PLL lockable rate. This causes set_rate to
> fail if exact rate could not be set. Instead round rate may return
> closest rate possible (less than the requested). And if any user is
> badly in need of exact rate, then return value of round rate could
> be used to decide whether to invoke set rate or not.
>
> Modify round rate so that it return closest possible rate.
This doesn't look like the right approach to me. For some PLLs, an exact
rate is desired.
We removed the rate tolerance code in commit
241d3a8dca239610d3d991bf58d4fe38c2d86fd5, but that was probably premature.
We've encountered several situations now where we could really use it,
like MPU CPUFreq. I'd suggest reverting
241d3a8dca239610d3d991bf58d4fe38c2d86fd5 or using a similar approach.
- Paul
^ permalink raw reply
* [PATCH v3 3/3] arm: mvebu: enable gpio expander over i2c on Mirabox platform
From: Linus Walleij @ 2013-01-25 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358889025-8530-4-git-send-email-gregory.clement@free-electrons.com>
On Tue, Jan 22, 2013 at 10:10 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The Globalscale Mirabox platform can be connected to the JTAG/GPIO box
> through the Multi-IO port. The GPIO box use the NXP PCA9505 I/O port
> expansion IC to provide 40-bit parallel input/output GPIOs. This patch
> enable the use of this expander on the Mirabox.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
So as requested I leave this patch for now, tell me if you want it
applied through pinctrl.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 2/3] gpio: pca953x: add support for pca9505
From: Linus Walleij @ 2013-01-25 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358889025-8530-3-git-send-email-gregory.clement@free-electrons.com>
On Tue, Jan 22, 2013 at 10:10 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Now that pca953x driver can handle GPIO expanders with more than 32
> bits this patch adds the support for the pca9505 which cam with 40
> GPIOs.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied, thanks.
But guys, this driver contains some horrific stuff, look at this:
static int pxa_gpio_nums(void)
{
int count = 0;
#ifdef CONFIG_ARCH_PXA
if (cpu_is_pxa25x()) {
#ifdef CONFIG_CPU_PXA26x
count = 89;
gpio_type = PXA26X_GPIO;
#elif defined(CONFIG_PXA25x)
count = 84;
gpio_type = PXA26X_GPIO;
#endif /* CONFIG_CPU_PXA26x */
} else if (cpu_is_pxa27x()) {
count = 120;
gpio_type = PXA27X_GPIO;
} else if (cpu_is_pxa93x()) {
count = 191;
gpio_type = PXA93X_GPIO;
} else if (cpu_is_pxa3xx()) {
count = 127;
gpio_type = PXA3XX_GPIO;
}
#endif /* CONFIG_ARCH_PXA */
#ifdef CONFIG_ARCH_MMP
if (cpu_is_pxa168() || cpu_is_pxa910()) {
count = 127;
gpio_type = MMP_GPIO;
} else if (cpu_is_mmp2()) {
count = 191;
gpio_type = MMP_GPIO;
}
#endif /* CONFIG_ARCH_MMP */
return count;
}
This is totally killing all attempts at a single kernel for multiple
machines in this family. The above should not be #ifdef's but instead
use either platform data or the compatible property to figure out which
one to use.
It's fine to introduce new compatible= strings or device names to
distinguish between these.
As an example, in pinctrl-nomadik.c we have this:
static const struct of_device_id nmk_pinctrl_match[] = {
{
.compatible = "stericsson,nmk_pinctrl",
.data = (void *)PINCTRL_NMK_DB8500,
},
{},
};
static const struct platform_device_id nmk_pinctrl_id[] = {
{ "pinctrl-stn8815", PINCTRL_NMK_STN8815 },
{ "pinctrl-db8500", PINCTRL_NMK_DB8500 },
{ "pinctrl-db8540", PINCTRL_NMK_DB8540 },
{ }
};
static struct platform_driver nmk_pinctrl_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "pinctrl-nomadik",
.of_match_table = nmk_pinctrl_match,
},
.probe = nmk_pinctrl_probe,
.id_table = nmk_pinctrl_id,
};
The first match is for DT boot the latter for using the platform
device name directly.
Then in the probefunction we do:
static int nmk_pinctrl_probe(struct platform_device *pdev)
{
const struct platform_device_id *platid = platform_get_device_id(pdev);
(...)
if (platid)
version = platid->driver_data;
else if (np) {
const struct of_device_id *match;
match = of_match_device(nmk_pinctrl_match, &pdev->dev);
if (!match)
return -ENODEV;
version = (unsigned int) match->data;
}
(...)
if (version == PINCTRL_NMK_STN8815)
nmk_pinctrl_stn8815_init(&npct->soc);
if (version == PINCTRL_NMK_DB8500)
nmk_pinctrl_db8500_init(&npct->soc);
if (version == PINCTRL_NMK_DB8540)
nmk_pinctrl_db8540_init(&npct->soc);
}
Surely a scheme like this must be possible to use to distinguish between
the different versions at runtime rather than using these #ifdefs?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv1 for soc 4/5] arm: Add v7_invalidate_l1 to cache-v7.S
From: Santosh Shilimkar @ 2013-01-25 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359075633-13502-5-git-send-email-dinguyen@altera.com>
On Friday 25 January 2013 06:30 AM, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen@altera.com>
>
> mach-socfpga is another platform that needs to use
> v7_invalidate_l1 to bringup additional cores. There was a comment that
> the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
>
> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Pavel Machek <pavel@denx.de>
> ---
> arch/arm/mach-imx/headsmp.S | 47 -------------------------------------
> arch/arm/mach-shmobile/headsmp.S | 48 --------------------------------------
> arch/arm/mach-tegra/headsmp.S | 43 ----------------------------------
> arch/arm/mm/cache-v7.S | 47 +++++++++++++++++++++++++++++++++++++
> 4 files changed, 47 insertions(+), 138 deletions(-)
>
Does yor kernel skips the decompresser. Am just curious about
what you describe above since you should see the issue already
at decompresser. Your boot loader is expected to clean and
invalidating the caches before jumping into the kernel.
Regards,
Santosh
^ 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