* [PATCH v4 00/10] net/fec: add dual fec support for i.MX28
From: Shawn Guo @ 2011-01-11 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110109.154409.242134862.davem@davemloft.net>
Hi Sascha,
On Sun, Jan 09, 2011 at 03:44:09PM -0800, David Miller wrote:
> From: Shawn Guo <shawn.guo@freescale.com>
> Date: Thu, 6 Jan 2011 15:13:08 +0800
>
> > This patch series is to add dual fec support for mx28, which is
> > a mxs-based soc. Some code changes related to the following commits
> > are also made in this patch set for some reasons.
> >
> > e6b043d512fa8d9a3801bf5d72bfa3b8fc3b3cc8
> > netdev/fec.c: add phylib supporting to enable carrier detection (v2)
> >
> > e3fe8558c7fc182972c3d947d88744482111f304
> > net/fec: fix pm to survive to suspend/resume
> >
> > It's been tested on mx28 evk and mx51 babbage. For mx28, it has
> > to work against the tree
> >
> > git://git.pengutronix.de/git/imx/linux-2.6.git imx-for-2.6.38
> >
> > plus patch
> >
> > [PATCH v4] ARM: mxs: Change duart device to use amba-pl011
> >
> > The 3 patches below preceding with * have changes since v3, and
> > the detailed change log can be found in individual patch.
>
> I've applied all of the "net/fec:" patches (#1 to #5) to net-2.6,
> please push the ARM changes via the appropriate ARM tree.
>
Is there anything needs to be done to get the following patches
merged?
[PATCH v4] ARM: mxs: Change duart device to use amba-pl011
[PATCH v4 00/10] net/fec: add dual fec support for i.MX28, #6 to #10.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH 0/2] ARM i.MX53 enable SMD and LOCO board bootup
From: Yong Shen @ 2011-01-11 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111072301.GA19168@jasper.tkos.co.il>
Hi Baruch,
So far they are similar, but as more code and features are added in,
they are going to be different. We had registered different mach id to
distinguish these two boards.
Thanks
Yong
On Tue, Jan 11, 2011 at 3:23 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Yong,
>
> On Tue, Jan 11, 2011 at 02:23:16PM +0800, yong.shen at freescale.com wrote:
>> SMD and LOCO are newly developed boards of i.MX53. LOCO means "low cost",
>> which is supposed to be widespread soon.
>
> These two patches seem almost identical. Can't both board support code share
> the same file?
>
> baruch
>
> --
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ~. .~ ? Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> ? - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
>
^ permalink raw reply
* [patch 2/5] ulpi: handle ULPI_OTG_CTRL_CHRGVBUS
From: Igor Grinberg @ 2011-01-11 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878vys7saf.fsf@lechat.rtp-net.org>
On 01/10/11 16:22, Arnaud Patard (Rtp) wrote:
> Igor Grinberg <grinberg@compulab.co.il> writes:
>> Can you, please, send patches inline and not as attachments next time?
>> It is very inconvenient to review and comment on attached patches.
> This patch a quick rewrite&test. It was more meant to understand if the
> direction was right rather than a formal submission. (I use quilt to
> send patches and not my mailer). There are some comment in the code
> needed and I've not put them.
Well, I also have got all other patches in the series as attachments...
Why not use git send-email?
>> On 01/07/11 11:02, Arnaud Patard (Rtp) wrote:
>>> What about the following patch ?
>>> ulpi: provide start_srp
>>>
>>> Add support for setting CHRGVBUS thanks to start_srp and use it
>>> to workaround a hardware bug on efika mx/sb boards.
>>> See http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/037341.html
>>>
>>> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
>>> Index: linux-2.6-submit/drivers/usb/otg/ulpi.c
>>> ===================================================================
>>> --- linux-2.6-submit.orig/drivers/usb/otg/ulpi.c 2011-01-04 17:12:26.000000000 +0100
>>> +++ linux-2.6-submit/drivers/usb/otg/ulpi.c 2011-01-06 14:44:50.000000000 +0100
>>> @@ -247,6 +247,14 @@
>>> return otg_io_write(otg, flags, ULPI_OTG_CTRL);
>>> }
>>>
>>> +static int ulpi_start_srp(struct otg_transceiver *otg, bool on)
>>> +{
>>> + unsigned int flags = otg_io_read(otg, ULPI_OTG_CTRL);
>>> +
>>> + flags |= ULPI_OTG_CTRL_CHRGVBUS;
>>> + return otg_io_write(otg, flags, ULPI_OTG_CTRL);
>>> +}
>>> +
>> I went through the OTG spec. and found that there are much more things
>> should be done for the start_srp() function to be implemented properly.
>> For example, it says that we should make sure that the Vbus is discharged
>> (means, the previous session has finished) before attempting to start a new
>> session, but that is only a half of the problem. The real problem for you, is that
>> the duration of the SRP should be no more then 100ms.
> oops. That's really annoying. (fwiw, I think that original code from fsl
> doesn't take care of that 100ms delay otherwise I guess I would have
> detected it too).
>>> struct otg_transceiver *
>>> otg_ulpi_create(struct otg_io_access_ops *ops,
>>> unsigned int flags)
>>> @@ -263,6 +271,7 @@
>>> otg->init = ulpi_init;
>>> otg->set_host = ulpi_set_host;
>>> otg->set_vbus = ulpi_set_vbus;
>>> + otg->start_srp = ulpi_start_srp;
>>>
>>> return otg;
>>> }
>>> Index: linux-2.6-submit/drivers/usb/host/ehci-mxc.c
>>> ===================================================================
>>> --- linux-2.6-submit.orig/drivers/usb/host/ehci-mxc.c 2011-01-06 14:45:14.000000000 +0100
>>> +++ linux-2.6-submit/drivers/usb/host/ehci-mxc.c 2011-01-06 15:48:16.000000000 +0100
>>> @@ -25,6 +25,8 @@
>>>
>>> #include <mach/mxc_ehci.h>
>>>
>>> +#include <asm/mach-types.h>
>>> +
>>> #define ULPI_VIEWPORT_OFFSET 0x170
>>>
>>> struct ehci_mxc_priv {
>>> @@ -239,6 +241,13 @@
>>> dev_err(dev, "unable to enable vbus on transceiver\n");
>>> goto err_add;
>>> }
>>> + if (machine_is_mx51_efikamx() || machine_is_mx51_efikasb()) {
>>> + ret = otg_start_srp(pdata->otg);
>>> + if (ret) {
>>> + dev_err(dev, "unable to start srp\n");
>>> + goto err_add;
>>> + }
>>> + }
>> In light of the problem described above, here you will need to write directly
>> to the view port instead of calling the otg_start_srp() function.
> ok. I don't think it's a problem. Looks otg_io_(read|write) are
> available here.
yeah, otg_io_(read|write) should do.
>> I'd recommend to move this to the machine (board) specific code.
>> May be to platform init (pdata->init) call back?
> oh, no. I've put this call in this place for some good reasons. This
> trick is working only if it's done _after_ add_hcd. Any other place
> won't work. For instance, pdata->init is meant to be called before
> mxc_initialise_usb_hw iirc which is _before_ add_hcd.
I see. The reason, I'd like to move it to the board code is a possibility that h/w will
change (hopefully even fixed) and then you will not have to violate the spec
anymore, but to deal with the h/w revision checking. ehci-mxc.c doesn't look
like a good place to deal with h/w revision checking of the board, so may be it is
worth to introduce some kind of another platform hook, like pdata->late_init?
I don't insist, it is up to you and Sascha to decide what's the best choice here.
>> IMHO, the explanation of the h/w bug workaround in the commit message
>> is not enough - in-code comment regarding the bug workaround should be added.
> I know. As I said this patch was not the final submission. It was
> probably not clear enough.
>
> Arnaud
--
Regards,
Igor.
^ permalink raw reply
* [PATCH 0/2] ARM i.MX53 enable SMD and LOCO board bootup
From: Baruch Siach @ 2011-01-11 7:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294726998-20830-1-git-send-email-yong.shen@freescale.com>
Hi Yong,
On Tue, Jan 11, 2011 at 02:23:16PM +0800, yong.shen at freescale.com wrote:
> SMD and LOCO are newly developed boards of i.MX53. LOCO means "low cost",
> which is supposed to be widespread soon.
These two patches seem almost identical. Can't both board support code share
the same file?
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH 2/2] ARM i.MX53 enable LOCO board bootup
From: yong.shen at freescale.com @ 2011-01-11 6:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294726998-20830-1-git-send-email-yong.shen@freescale.com>
From: Yong Shen <yong.shen@freescale.com>
1. Add Kconfig and Makefile entries
2. Add board definition
3. enable uart and fec for LOCO board
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/Kconfig | 8 +++
arch/arm/mach-mx5/Makefile | 1 +
arch/arm/mach-mx5/board-mx53_loco.c | 112 +++++++++++++++++++++++++++++++++++
3 files changed, 121 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mx5/board-mx53_loco.c
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 09ac525..982f798 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -138,6 +138,14 @@ config MACH_MX53_SMD
Include support for MX53 SMD platform. This includes specific
configurations for the board and its peripherals.
+config MACH_MX53_LOCO
+ bool "Support MX53 LOCO platforms"
+ select SOC_IMX53
+ select IMX_HAVE_PLATFORM_IMX_UART
+ help
+ Include support for MX53 LOCO platform. This includes specific
+ configurations for the board and its peripherals.
+
config MACH_MX50_RDP
bool "Support MX50 reference design platform"
depends on BROKEN
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index 895bfe3..0d43be9 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_MACH_MX51_BABBAGE) += board-mx51_babbage.o
obj-$(CONFIG_MACH_MX51_3DS) += board-mx51_3ds.o
obj-$(CONFIG_MACH_MX53_EVK) += board-mx53_evk.o
obj-$(CONFIG_MACH_MX53_SMD) += board-mx53_smd.o
+obj-$(CONFIG_MACH_MX53_LOCO) += board-mx53_loco.o
obj-$(CONFIG_MACH_EUKREA_CPUIMX51) += board-cpuimx51.o
obj-$(CONFIG_MACH_EUKREA_MBIMX51_BASEBOARD) += eukrea_mbimx51-baseboard.o
obj-$(CONFIG_MACH_EUKREA_CPUIMX51SD) += board-cpuimx51sd.o
diff --git a/arch/arm/mach-mx5/board-mx53_loco.c b/arch/arm/mach-mx5/board-mx53_loco.c
new file mode 100644
index 0000000..76896cc
--- /dev/null
+++ b/arch/arm/mach-mx5/board-mx53_loco.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include <linux/init.h>
+#include <linux/clk.h>
+#include <linux/fec.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+
+#include <mach/common.h>
+#include <mach/hardware.h>
+#include <mach/imx-uart.h>
+#include <mach/iomux-mx53.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/time.h>
+
+#include "crm_regs.h"
+#include "devices-imx53.h"
+
+#define LOCO_FEC_PHY_RST IMX_GPIO_NR(7, 6)
+
+static iomux_v3_cfg_t mx53_loco_pads[] = {
+ MX53_PAD_CSI0_D10__UART1_TXD,
+ MX53_PAD_CSI0_D11__UART1_RXD,
+ MX53_PAD_ATA_DIOW__UART1_TXD,
+ MX53_PAD_ATA_DMACK__UART1_RXD,
+
+ MX53_PAD_ATA_BUFFER_EN__UART2_RXD,
+ MX53_PAD_ATA_DMARQ__UART2_TXD,
+ MX53_PAD_ATA_DIOR__UART2_RTS,
+ MX53_PAD_ATA_INTRQ__UART2_CTS,
+
+ MX53_PAD_ATA_CS_0__UART3_TXD,
+ MX53_PAD_ATA_CS_1__UART3_RXD,
+ MX53_PAD_ATA_DA_1__UART3_CTS,
+ MX53_PAD_ATA_DA_2__UART3_RTS,
+};
+
+static const struct imxuart_platform_data mx53_loco_uart_data __initconst = {
+ .flags = IMXUART_HAVE_RTSCTS,
+};
+
+static inline void mx53_loco_init_uart(void)
+{
+ imx53_add_imx_uart(0, &mx53_loco_uart_data);
+ imx53_add_imx_uart(1, &mx53_loco_uart_data);
+ imx53_add_imx_uart(2, &mx53_loco_uart_data);
+}
+
+static inline void mx53_loco_fec_reset(void)
+{
+ int ret;
+
+ /* reset FEC PHY */
+ ret = gpio_request(LOCO_FEC_PHY_RST, "fec-phy-reset");
+ if (ret) {
+ printk(KERN_ERR"failed to get GPIO_FEC_PHY_RESET: %d\n", ret);
+ return;
+ }
+ gpio_direction_output(LOCO_FEC_PHY_RST, 0);
+ gpio_set_value(LOCO_FEC_PHY_RST, 0);
+ msleep(1);
+ gpio_set_value(LOCO_FEC_PHY_RST, 1);
+}
+
+static struct fec_platform_data mx53_loco_fec_data = {
+ .phy = PHY_INTERFACE_MODE_RMII,
+};
+
+static void __init mx53_loco_board_init(void)
+{
+ mxc_iomux_v3_setup_multiple_pads(mx53_loco_pads,
+ ARRAY_SIZE(mx53_loco_pads));
+ mx53_loco_init_uart();
+ mx53_loco_fec_reset();
+ imx53_add_fec(&mx53_loco_fec_data);
+}
+
+static void __init mx53_loco_timer_init(void)
+{
+ mx53_clocks_init(32768, 24000000, 0, 0);
+}
+
+static struct sys_timer mx53_loco_timer = {
+ .init = mx53_loco_timer_init,
+};
+
+MACHINE_START(MX53_LOCO, "Freescale MX53 LOCO Board")
+ .map_io = mx53_map_io,
+ .init_irq = mx53_init_irq,
+ .init_machine = mx53_loco_board_init,
+ .timer = &mx53_loco_timer,
+MACHINE_END
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] ARM i.MX53 enable SMD board bootup
From: yong.shen at freescale.com @ 2011-01-11 6:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294726998-20830-1-git-send-email-yong.shen@freescale.com>
From: Yong Shen <yong.shen@freescale.com>
1. Add Kconfig and Makefile entries
2. Add board definition
3. enable uart and fec for SMD board
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/Kconfig | 7 ++
arch/arm/mach-mx5/Makefile | 1 +
arch/arm/mach-mx5/board-mx53_smd.c | 112 ++++++++++++++++++++++++++++++++++++
3 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mx5/board-mx53_smd.c
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 23b0e3f..09ac525 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -130,6 +130,13 @@ config MACH_MX53_EVK
Include support for MX53 EVK platform. This includes specific
configurations for the board and its peripherals.
+config MACH_MX53_SMD
+ bool "Support MX53 SMD platforms"
+ select SOC_IMX53
+ select IMX_HAVE_PLATFORM_IMX_UART
+ help
+ Include support for MX53 SMD platform. This includes specific
+ configurations for the board and its peripherals.
config MACH_MX50_RDP
bool "Support MX50 reference design platform"
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index 0c398ba..895bfe3 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_CPU_FREQ_IMX) += cpu_op-mx51.o
obj-$(CONFIG_MACH_MX51_BABBAGE) += board-mx51_babbage.o
obj-$(CONFIG_MACH_MX51_3DS) += board-mx51_3ds.o
obj-$(CONFIG_MACH_MX53_EVK) += board-mx53_evk.o
+obj-$(CONFIG_MACH_MX53_SMD) += board-mx53_smd.o
obj-$(CONFIG_MACH_EUKREA_CPUIMX51) += board-cpuimx51.o
obj-$(CONFIG_MACH_EUKREA_MBIMX51_BASEBOARD) += eukrea_mbimx51-baseboard.o
obj-$(CONFIG_MACH_EUKREA_CPUIMX51SD) += board-cpuimx51sd.o
diff --git a/arch/arm/mach-mx5/board-mx53_smd.c b/arch/arm/mach-mx5/board-mx53_smd.c
new file mode 100644
index 0000000..2d36348
--- /dev/null
+++ b/arch/arm/mach-mx5/board-mx53_smd.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include <linux/init.h>
+#include <linux/clk.h>
+#include <linux/fec.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+
+#include <mach/common.h>
+#include <mach/hardware.h>
+#include <mach/imx-uart.h>
+#include <mach/iomux-mx53.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/time.h>
+
+#include "crm_regs.h"
+#include "devices-imx53.h"
+
+#define SMD_FEC_PHY_RST IMX_GPIO_NR(7, 6)
+
+static iomux_v3_cfg_t mx53_smd_pads[] = {
+ MX53_PAD_CSI0_D10__UART1_TXD,
+ MX53_PAD_CSI0_D11__UART1_RXD,
+ MX53_PAD_ATA_DIOW__UART1_TXD,
+ MX53_PAD_ATA_DMACK__UART1_RXD,
+
+ MX53_PAD_ATA_BUFFER_EN__UART2_RXD,
+ MX53_PAD_ATA_DMARQ__UART2_TXD,
+ MX53_PAD_ATA_DIOR__UART2_RTS,
+ MX53_PAD_ATA_INTRQ__UART2_CTS,
+
+ MX53_PAD_ATA_CS_0__UART3_TXD,
+ MX53_PAD_ATA_CS_1__UART3_RXD,
+ MX53_PAD_ATA_DA_1__UART3_CTS,
+ MX53_PAD_ATA_DA_2__UART3_RTS,
+};
+
+static const struct imxuart_platform_data mx53_smd_uart_data __initconst = {
+ .flags = IMXUART_HAVE_RTSCTS,
+};
+
+static inline void mx53_smd_init_uart(void)
+{
+ imx53_add_imx_uart(0, &mx53_smd_uart_data);
+ imx53_add_imx_uart(1, &mx53_smd_uart_data);
+ imx53_add_imx_uart(2, &mx53_smd_uart_data);
+}
+
+static inline void mx53_smd_fec_reset(void)
+{
+ int ret;
+
+ /* reset FEC PHY */
+ ret = gpio_request(SMD_FEC_PHY_RST, "fec-phy-reset");
+ if (ret) {
+ printk(KERN_ERR"failed to get GPIO_FEC_PHY_RESET: %d\n", ret);
+ return;
+ }
+ gpio_direction_output(SMD_FEC_PHY_RST, 0);
+ gpio_set_value(SMD_FEC_PHY_RST, 0);
+ msleep(1);
+ gpio_set_value(SMD_FEC_PHY_RST, 1);
+}
+
+static struct fec_platform_data mx53_smd_fec_data = {
+ .phy = PHY_INTERFACE_MODE_RMII,
+};
+
+static void __init mx53_smd_board_init(void)
+{
+ mxc_iomux_v3_setup_multiple_pads(mx53_smd_pads,
+ ARRAY_SIZE(mx53_smd_pads));
+ mx53_smd_init_uart();
+ mx53_smd_fec_reset();
+ imx53_add_fec(&mx53_smd_fec_data);
+}
+
+static void __init mx53_smd_timer_init(void)
+{
+ mx53_clocks_init(32768, 24000000, 22579200, 0);
+}
+
+static struct sys_timer mx53_smd_timer = {
+ .init = mx53_smd_timer_init,
+};
+
+MACHINE_START(MX53_SMD, "Freescale MX53 SMD Board")
+ .map_io = mx53_map_io,
+ .init_irq = mx53_init_irq,
+ .init_machine = mx53_smd_board_init,
+ .timer = &mx53_smd_timer,
+MACHINE_END
--
1.7.1
^ permalink raw reply related
* [PATCH 0/2] ARM i.MX53 enable SMD and LOCO board bootup
From: yong.shen at freescale.com @ 2011-01-11 6:23 UTC (permalink / raw)
To: linux-arm-kernel
SMD and LOCO are newly developed boards of i.MX53. LOCO means "low cost", which is supposed to be widespread soon.
^ permalink raw reply
* [PATCH V3 42/63] ST SPEAr: replace readl, writel with __raw_readl, __raw_writel in uncompress.h
From: viresh kumar @ 2011-01-11 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D26DF03.6050805@windriver.com>
On 01/07/2011 03:08 PM, stanley.miao wrote:
> With this in mind, I think readl_relaxed() should be better here.
Stanley,
Actually we never thought of endianness while coding it, and
followed the most generic approach taken by other archs.
Yes, i do accept *_relaxed() should be used instead.
I will do that in V4.
--
viresh
^ permalink raw reply
* [PATCH 1/2] stackprotector: add stack smashing protector generic implementation
From: Mike Frysinger @ 2011-01-11 5:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D245D16.5010702@st.com>
what are you using to test this ? is there a simple strcpy or similar
code you run as a kernel module that'll allow me to verify ?
-mike
^ permalink raw reply
* [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
From: Grant Likely @ 2011-01-11 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101102211370.12076@xanadu.home>
On Mon, Jan 10, 2011 at 8:19 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 10 Jan 2011, Grant Likely wrote:
>
>> Since the debug macros no longer depend on the machine type
>> information, both the machine type lookup and the atags vetting can be
>> deferred to setup_arch() in setup.c which simplifies the code
>> somewhat.
>>
>> This patch removes both __machine_type_lookup and __vet_atags() from
>> head.S. ?The atags vetting is moved to setup_arch(). ?machine_type
>> lookup is already called from setup_machine() in addition to where it
>> was called from head.S.
>
> While at it, you could also remove the code for __lookup_machine_type,
> lookup_machine_type and __error_a, replacing that with a C
> implementation living in setup.c instead. ?If this code is not called
> from head.S anymore, there is no reason to keep it there any longer.
Certainly. I'll draft that up as a separate patch and post it tomorrow.
g.
^ permalink raw reply
* [PATCH] TWD: enable one-shot mode
From: Stephen Boyd @ 2011-01-11 5:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101224191855.GJ20587@n2100.arm.linux.org.uk>
On 12/24/2010 11:18 AM, Russell King - ARM Linux wrote:
> Allow one shot timer mode to be used with the TWD. This allows
> NOHZ mode to be used on SMP systems using the TWD localtimer.
>
> Tested on Versatile Express.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> Acks/Tested-by's would be appreciated, thanks.
>
I see this patch was already tested and merged but can you elaborate on
why this was done? From what I understand, NOHZ selects one-shot (like
is done in this patch), so why don't the machines with a TWD choose NOHZ
or high res timers?
Putting it another way, if my machine supports a oneshot capable
clockevent device should I be selecting oneshot regardless of the NOHZ
and high res config option being chosen?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH] arm: mm: Poison freed init memory
From: Stephen Boyd @ 2011-01-11 5:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106090741.GQ8638@n2100.arm.linux.org.uk>
On 01/06/2011 01:07 AM, Russell King - ARM Linux wrote:
> On Wed, Jan 05, 2011 at 09:25:55PM -0800, Stephen Boyd wrote:
>> On 01/05/2011 12:26 PM, Russell King - ARM Linux wrote:
>>> On Wed, Jan 05, 2011 at 11:47:25AM -0800, Stephen Boyd wrote:
>>>> Poisoning __init marked memory can be useful when tracking down
>>>> obscure memory corruption bugs. When a pointer is 0xCCCCCCCC in an
>>>
>>> That's a bad idea for a value. With a 3GB page offset and 256MB or
>>> more memory, accesses to such an address will always succeed.
>>>
>>> There's two things to be considered when selecting a possible poison
>>> value:
>>>
>>> 1. what value is guaranteed to provoke an undefined instruction exception?
>>> 2. what value when used as an address and dereferenced is mostly always
>>> going to abort?
>>>
>>> 1 for ARM mode implies an 0xe7fXXXfX value. For Thumb mode 0xdeXX. We
>>> use this space for breakpoints.
>>>
>>> 2 unfortunately depends on the platform.
>>
>> A coworker proposed we use a SWI instruction. We could do that if the
>> poison is 0xEF and then do something in the SWI handler where that
>> number causes us to blow up?
>
> Doesn't work with EABI - the comment field in the SWI instruction is
> ignored on EABI.
>
>> If I'm following correctly, point 1 is about __init functions and point
>> 2 is about __initdata. I'm more concerned about __initdata because
>> __init functions called from non __init marked functions are usually
>> caught with section mismatch checks. Also, if we're jumping to
>> 0xCCCCCCCC we're probably not in the text section of the kernel with a
>
> But, as I pointed out, you don't know that 0xCCCCCCCC isn't a valid
> address _and_ on modern platforms it won't fault. So it's pointless
> to use it as a poison value.
Ok it seems that 0xcc was chosen by Pavel since it's a breakpoint
instruction (sorry for not noticing that earlier [1]). There was some
discussion about handling initdata with Pavel's patch but it seems that
nothing came of it? I assume that's because we don't differentiate
between the two types of init markings.
How about we use 0xe7fddef0? This seems to satisfy at least your first
point for both ARM and Thumb mode (Thumb will branch to the 0xdef0
instruction).
[1] http://lkml.indiana.edu/hypermail/linux/kernel/0410.0/2040.html for
those interested
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Locking in the clk API
From: Paul Mundt @ 2011-01-11 4:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101111211.30172.jeremy.kerr@canonical.com>
Hi Jeremy,
On Tue, Jan 11, 2011 at 12:11:29PM +0800, Jeremy Kerr wrote:
> > This looks like a complete disaster, and is also completely inconsistent
> > with how the API is being used by the vast majority of users today.
>
> I've been basing this on the mxc clock code, which acquires a mutex for all
> clk_enable()s. This may not be representative of the majority of clock usage.
>
> From a quick search there are a few other cases of non-atomic clock usage:
>
> tcc: clk_enable() acquires a global clocks_mutex
> tegra: has a clk_enable_cansleep()
> davinci: clk_set_parent() aquires a global clocks_mutex
>
> Excluding the davinci code (we won't worry about set_parent for now...), if we
> can port mxc and tcc to a sleepable clk_enable, perhaps we could just go with
> purely atomic operations.
>
> We'd still need some method of using sleeping clocks though. How about making
> clk_enable() BUG if the clock is not atomic, and add clk_enable_cansleep() for
> the cases where clk->ops.enable may sleep.
>
Yes, that sounds reasonable. I don't particularly care for the atomic
flag on the clock however since that's really the default behaviour for
almost everyone at the moment. On the other hand, the mutex API will
already blow up if someone tries to grab it within atomic context (with
the _trylock exception). Still, making the API explicit and tossing in a
might_sleep() or so will at least help figure out which assumptions are
being made and/or violated.
> Do we need something similar for other parts of the API? (clk_set_rate?)
>
I suppose that's an inevitable thing at least in terms of keeping the API
balanced and consistent.
One other thing to be aware of is that the clkdev code maintains its own
list mutex, so the addition and deletion of clkdev lookups in addition to
the clkdev-backed clk_get() will all be sleepable. It would however be
possible to back a one-shot atomic-safe clk_get() with a mutex_trylock()
for the common cases, but it's not entirely obvious that it would be
worth the complexity it would introduce.
If you're going to do this work it would also be helpful to spell out the
locking semantics within linux/clk.h at the same time (it might even be
worthwhile doing this incrementally and getting all of the platforms
in-line before attempting to consolidate things too aggressively), as
it's apparent from the cases you cite there are at least a couple of
boards that aren't quite in line with what everyone else is doing.
In general we have to accept that the dynamic creation, deletion, and
looking up of clocks is going to be a sleepable case, and the rest will
likely have to be split out in to _cansleep and default atomic-safe
variants.
set_rate/parent and friends likewise are done atomically for some and
sleepable for others, so it doesn't seem like there's going to be much
choice other than simply splitting out the API for these cases.
Also, I'm not sure if you've noticed yet or not, but note that there is
now a drivers/clk due to the shuffling of the clkdev code, so you may
want to piggyback on top of this instead of using the top-level kernel/
^ permalink raw reply
* Locking in the clk API
From: Jeremy Kerr @ 2011-01-11 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111031552.GJ3760@linux-sh.org>
Hi Paul,
> This looks like a complete disaster, and is also completely inconsistent
> with how the API is being used by the vast majority of users today.
I've been basing this on the mxc clock code, which acquires a mutex for all
clk_enable()s. This may not be representative of the majority of clock usage.
>From a quick search there are a few other cases of non-atomic clock usage:
tcc: clk_enable() acquires a global clocks_mutex
tegra: has a clk_enable_cansleep()
davinci: clk_set_parent() aquires a global clocks_mutex
Excluding the davinci code (we won't worry about set_parent for now...), if we
can port mxc and tcc to a sleepable clk_enable, perhaps we could just go with
purely atomic operations.
We'd still need some method of using sleeping clocks though. How about making
clk_enable() BUG if the clock is not atomic, and add clk_enable_cansleep() for
the cases where clk->ops.enable may sleep.
Do we need something similar for other parts of the API? (clk_set_rate?)
Cheers,
Jeremy
^ permalink raw reply
* [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
From: Nicolas Pitre @ 2011-01-11 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111015409.18291.87166.stgit@localhost6.localdomain6>
On Mon, 10 Jan 2011, Grant Likely wrote:
> Since the debug macros no longer depend on the machine type
> information, both the machine type lookup and the atags vetting can be
> deferred to setup_arch() in setup.c which simplifies the code
> somewhat.
>
> This patch removes both __machine_type_lookup and __vet_atags() from
> head.S. The atags vetting is moved to setup_arch(). machine_type
> lookup is already called from setup_machine() in addition to where it
> was called from head.S.
While at it, you could also remove the code for __lookup_machine_type,
lookup_machine_type and __error_a, replacing that with a C
implementation living in setup.c instead. If this code is not called
from head.S anymore, there is no reason to keep it there any longer.
Nicolas
^ permalink raw reply
* Locking in the clk API
From: Paul Mundt @ 2011-01-11 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101111016.42819.jeremy.kerr@canonical.com>
On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
> * clk_enable: may sleep
>
> * clk_disable: may not sleep, but it's possible to make the global
> clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
> non-atomic context.
>
> * clk_get_rate: may not sleep
>
> * clk_set_rate: may sleep
>
> As we build up our requirements, we can adjust as suitable.
>
This looks like a complete disaster, and is also completely inconsistent
with how the API is being used by the vast majority of users today. You
have an API that can or can not sleep with no indication as to which is
which based off of the API naming, which is just asking for trouble.
As it is today, most users expect that these are all usable from atomic
context, and as far as I can tell the only special case you have are for
some crap busses with insane latencies. In this case you should simply
pile on _cansleep() versions of the API and make it apparent that those
drivers are the special cases, not the other way around.
Having half of the API sleepable and the other not with no indication of
which is which simply makes it completely unusable and error prone for
both atomic and non-atomic contexts.
^ permalink raw reply
* Locking in the clk API
From: Jeremy Kerr @ 2011-01-11 2:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I'd like to define some locking semantics for the clk API, so that device
driver can have some assurance about when it is safe to call various clk_
functions from atomic contexts.
Vincent - you mentioned in a conversation that your code had some specific
requirements for clock enable/disable at interrupt time - could you reply with
an outline of this? Also, Sascha and Uwe: do you have any thoughts from your
work with the common struct clk?
== Requirements ==
To get things started, here are some basic requirements from the external API
side:
1) clk_enable: the clock should be outputting a valid clock signal before
returning from this function.
- drivers may require valid clock signal to be present for subsequent
device interactions.
3) clk_disable: may be called from atomic context
- Vincent: this is what I recall from our conversation, is it still true?
4) clk_set_rate: clock should change to the new rate before this returns
5) clk_get_rate: may be called from atomic context
6) in general, drivers shouldn't require details about the clock
implementation
And from the clock implementation side:
7) interactions with clock hardware may require sleeping (eg, clocks on an i2c
bus)
8) clk_enable() may require enabling a parent, which may also require
sleeping. Ideally, we shouldn't have to care about the parent's
implementation.
I'm sure there are others, please feel free to add to this list.
== Implementation ==
At present, we can satisfy these with:
* clk_enable: may sleep
* clk_disable: may not sleep, but it's possible to make the global
clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
non-atomic context.
* clk_get_rate: may not sleep
* clk_set_rate: may sleep
As we build up our requirements, we can adjust as suitable.
I'm excluding clk_{get,set}_parent at present, as I'm not sure we want these
as part of the device-driver API (ie, they require knowledge of the platform
clock infrastructure).
Thanks,
Jeremy
^ permalink raw reply
* [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
From: Grant Likely @ 2011-01-11 2:15 UTC (permalink / raw)
To: linux-arm-kernel
Since the debug macros no longer depend on the machine type
information, both the machine type lookup and the atags vetting can be
deferred to setup_arch() in setup.c which simplifies the code
somewhat.
This patch removes both __machine_type_lookup and __vet_atags() from
head.S. The atags vetting is moved to setup_arch(). machine_type
lookup is already called from setup_machine() in addition to where it
was called from head.S.
I've tried to preserve the existing behaviour in this patch so the
extra atags vetting is only using when CONFIG_MMU is selected. I may
be being overly cautious, and if so then it is probably possible to
simplify the code further.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Hi Russell,
I'm not sure if this is a valid change or not, but from what I can
tell it looks like machine and atag processing no longer needs
to be handled as early as head.S. Please take a look and let me know
what you think.
I've boot tested this on Tegra and versatile qemu, but that's about
it.
Thanks,
g.
arch/arm/kernel/head-common.S | 35 -----------------------------------
arch/arm/kernel/head.S | 5 -----
arch/arm/kernel/setup.c | 16 ++++++++++++++++
3 files changed, 16 insertions(+), 40 deletions(-)
diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index bbecaac..7956a48 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -11,10 +11,6 @@
*
*/
-#define ATAG_CORE 0x54410001
-#define ATAG_CORE_SIZE ((2*4 + 3*4) >> 2)
-#define ATAG_CORE_SIZE_EMPTY ((2*4) >> 2)
-
/*
* Exception handling. Something went wrong and we can't proceed. We
* ought to tell the user, but since we don't have any guarantee that
@@ -101,37 +97,6 @@ __lookup_machine_type_data:
.long __arch_info_end
.size __lookup_machine_type_data, . - __lookup_machine_type_data
-/* Determine validity of the r2 atags pointer. The heuristic requires
- * that the pointer be aligned, in the first 16k of physical RAM and
- * that the ATAG_CORE marker is first and present. Future revisions
- * of this function may be more lenient with the physical address and
- * may also be able to move the ATAGS block if necessary.
- *
- * r8 = machinfo
- *
- * Returns:
- * r2 either valid atags pointer, or zero
- * r5, r6 corrupted
- */
-__vet_atags:
- tst r2, #0x3 @ aligned?
- bne 1f
-
- ldr r5, [r2, #0] @ is first tag ATAG_CORE?
- cmp r5, #ATAG_CORE_SIZE
- cmpne r5, #ATAG_CORE_SIZE_EMPTY
- bne 1f
- ldr r5, [r2, #4]
- ldr r6, =ATAG_CORE
- cmp r5, r6
- bne 1f
-
- mov pc, lr @ atag pointer is ok
-
-1: mov r2, #0
- mov pc, lr
-ENDPROC(__vet_atags)
-
/*
* The following fragment of code is executed with the MMU on in MMU mode,
* and uses absolute addresses; this is not position independent.
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 6bd82d2..9c0e938 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -87,11 +87,6 @@ ENTRY(stext)
movs r10, r5 @ invalid processor (r5=0)?
THUMB( it eq ) @ force fixup-able long branch encoding
beq __error_p @ yes, error 'p'
- bl __lookup_machine_type @ r5=machinfo
- movs r8, r5 @ invalid machine (r5=0)?
- THUMB( it eq ) @ force fixup-able long branch encoding
- beq __error_a @ yes, error 'a'
- bl __vet_atags
#ifdef CONFIG_SMP_ON_UP
bl __fixup_smp
#endif
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 336f14e..cd28089 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -814,6 +814,22 @@ void __init setup_arch(char **cmdline_p)
if (mdesc->soft_reboot)
reboot_setup("s");
+#if defined(CONFIG_MMU)
+ /*
+ * Determine validity of the atags pointer. The heuristic requires
+ * that the pointer be aligned, and that the ATAG_CORE marker is
+ * first and present.
+ */
+ if (__atags_pointer & 0x3)
+ __atags_pointer = 0;
+ if (__atags_pointer) {
+ struct tag *t = phys_to_virt(__atags_pointer);
+ if ((t->hdr.size != tag_size(tag_core)) &&
+ (t->hdr.size != sizeof(struct tag_header)) &&
+ (t->hdr.tag != ATAG_CORE))
+ __atags_pointer = 0;
+ }
+#endif
if (__atags_pointer)
tags = phys_to_virt(__atags_pointer);
else if (mdesc->boot_params)
^ permalink raw reply related
* [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
From: Kevin Hilman @ 2011-01-11 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1101101214430.5731@utopia.booyaka.com>
Paul Walmsley <paul@pwsan.com> writes:
> On Fri, 7 Jan 2011, Kevin Hilman wrote:
>
>> Rajendra Nayak <rnayak@ti.com> writes:
>>
>> [...]
>>
>> > Just another trivial fix.
>> >
>> > From bb46b74d2b0ab3d35e72b760da7e123a891e6813 Mon Sep 17 00:00:00 2001
>> > From: Rajendra Nayak <rnayak@ti.com>
>> > Date: Fri, 7 Jan 2011 14:07:25 +0530
>> > Subject: [PATCH] OMAP: powerdomain: remove unused func declaration
>> >
>> > Trivial fix to remove the unused function declaration
>> > from the powerdomain header.
>> >
>> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> > ---
>> > arch/arm/mach-omap2/powerdomain.h | 1 -
>> > 1 files changed, 0 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-omap2/powerdomain.h
>> > b/arch/arm/mach-omap2/powerdomain.h
>> > index c66431e..0b7a357 100644
>> > --- a/arch/arm/mach-omap2/powerdomain.h
>> > +++ b/arch/arm/mach-omap2/powerdomain.h
>> > @@ -165,7 +165,6 @@ struct pwrdm_ops {
>> > int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
>> > };
>> >
>> > -void pwrdm_fw_init(void);
>> > void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_ops
>> > *custom_funcs);
>>
>> Note this is line-wrapped.
>>
>> Looks like you need to get get-send-email setup so you can avoid having
>> the patch sending problems.
>>
>> >
>> > struct powerdomain *pwrdm_lookup(const char *name);
>>
>> In any case, with Paul's ack, I can queue this with the others.
>
> Normally I would wait for the .39 merge window with something like this,
> but you're welcome to queue it for the -rc fixes if you feel it's
> appropriate:
Yeah, I agree. I'll let you queue this one for .39 as it's not really a
fix.
Kevin
^ permalink raw reply
* [PATCH 2/3] perf: add OMAP support for the new power events
From: Kevin Hilman @ 2011-01-11 1:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101101514.32355.trenn@suse.de>
Thomas Renninger <trenn@suse.de> writes:
> On Wednesday 05 January 2011 12:05:18 Jean Pihet wrote:
>> Hi Paul,
>>
>> On Tue, Jan 4, 2011 at 7:48 PM, Paul Walmsley <paul@pwsan.com> wrote:
>> > Hello Jean,
>> >
>> > On Tue, 4 Jan 2011, jean.pihet at newoldbits.com wrote:
>> >
>> >> From: Jean Pihet <j-pihet@ti.com>
>> >>
>> >> The patch adds the new power management trace points for
>> >> the OMAP architecture.
>> >>
>> >> The trace points are for:
>> >> - default idle handler. Since the cpuidle framework is
>> >> instrumented in the generic way there is no need to
>> >> add trace points in the OMAP specific cpuidle handler;
>> >> - cpufreq (DVFS),
>> >> - clocks changes (enable, disable, set_rate),
>> >
>> > A question about these. Are these only meant to track calls to these
>> > functions from outside the clock code? Or meant to track actual hardware
>> > clock changes?
>> The former: this is used to track the clock requests from outside the
>> clock framework.
>>
>> > If the latter, then it might make sense to put these
>> > trace points into the functions that actually change the hardware
>> > registers, e.g., omap2_dflt_clk_{enable,disable}(), etc., since a
>> > clk_enable() on a leaf clock may result in many internal system clocks
>> > being enabled up the clock tree.
>> I agree with you it is better to track the actual clock changes instead.
>> I propose to move the tracepoints to omap2_clk_{enable...} which
>> enables all the clocks irrespectively of the installed handler.
>> Note about the clock handlers: omap2_dflt_clk_enable happens to be the
>> handler for all controllable clocks but could that change in the
>> future?
> Looks like there is cpuidle34xx using cpuidle framework on specific
> boards only. And pm34xx.c and others override pm_idle and use the
> same low level functions to reduce power consumption as cpuidle34xx.
> Ideally pm34xx.c (and others) would not override pm_idle, but register as
> a cpuidle driver. Then the idle events would be tracked by the
> cpuidle subsystem automatically (with my latest patches).
> But this would be a more intrusive change (are there efforts to do that?).
Whenever CPUidle is enabled though, the cpuidle34xx code is used so the
pm_idle in pm34xx is not used. This allows us to have a way to do PM
with and without CPUidle, so without CPUidle, we can still get some
basic PM in idle.
> Even if it should happen at some point, adding some additional events for
> people to better debug/monitor the stuff now does not hurt.
I agree, as the two both very useful.
Tracking CPUidle transitions gives us some high-level information on PM
transitions, but what is most interesting for real PM analysis on OMAP
is exactly which powerdomains, clockdomains and clocks transitions (or
didn't transition) for a given state.
Kevin
^ permalink raw reply
* [PATCH 1/2] Add a common struct clk
From: Jeremy Kerr @ 2011-01-11 0:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110110110028.GB12552@n2100.arm.linux.org.uk>
Hi Russell,
> Unless the locking problems can be resolved, the patches aren't ready.
>
> From what I've seen there's still quite a problem with what kind of
> lock to use in the clock - mutex or spinlock.
Yes, the clock driver may either use a spinlock or mutex.
However, this exactly the same as the current clock code, my patches do not
alter what we currently have.
I do agree that we should define some specific semantics for the clock API
with regards to sleeping, and I'll start a new thread about that. But we
should definitely separate that issue from the problem of having multiple
definitions for struct clk, which is what these patches address.
Cheers,
Jeremy
^ permalink raw reply
* [PATCH 4/4] ARM: support for Thumb-2 instructions with CONFIG_ARM_PATCH_PHYS_VIRT
From: Nicolas Pitre @ 2011-01-10 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110110232435.GF12552@n2100.arm.linux.org.uk>
On Mon, 10 Jan 2011, Russell King - ARM Linux wrote:
> On Mon, Jan 10, 2011 at 05:45:44PM -0500, Nicolas Pitre wrote:
> > I need to rework this part entirely now anyway to go on top of Russell's
> > latest version.
>
> I've made a few changes recently to it to fix a few quirks. Once the
> merge window is over, I'll push out new patches and tree. Until then
> it wouldn't be fair on SFR/linux-next to push new code stuff out during
> the merge window.
Maybe you could push those into a branch which is not pulled into
linux-next?
Nicolas
^ permalink raw reply
* [PATCH 1/1] ARM i.MX50: Rename devices-mx50.h
From: Richard Zhao @ 2011-01-10 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294695869-6653-1-git-send-email-r64343@freescale.com>
On Tue, Jan 11, 2011 at 5:44 AM, Jason Liu <r64343@freescale.com> wrote:
> There are devices-imx51.h and devices-imx53.h under
> arch/arm/mach-mx5 directory. So, had better rename
> devices-mx50.h to devices-imx50.h to follow the same
> naming convention with imx51 and imx53 part.
I noticed that too. Sometimes we use imx as part of file name or macro
name, but other times we use mx . We'd better make some rule that when
and where we suppose to use what.
I suggest we move all to mx for short. Reasons:
- For freescale internal, starting from mx5, we all use mx.
- macros in soc header files all use mx.
- soc header file name all use mx too.
- mach-types all use mx. (count in freescale board only)
Thanks
Richard
>
> Signed-off-by: Jason Liu <r64343@freescale.com>
> ---
> ?arch/arm/mach-mx5/board-mx50_rdp.c ? ? ? ? ? ? ? ? | ? ?2 +-
> ?.../mach-mx5/{devices-mx50.h => devices-imx50.h} ? | ? ?0
> ?2 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-mx5/board-mx50_rdp.c b/arch/arm/mach-mx5/board-mx50_rdp.c
> index fd32e4c..e5bb600 100644
> --- a/arch/arm/mach-mx5/board-mx50_rdp.c
> +++ b/arch/arm/mach-mx5/board-mx50_rdp.c
> @@ -35,7 +35,7 @@
> ?#include <asm/mach/arch.h>
> ?#include <asm/mach/time.h>
>
> -#include "devices-mx50.h"
> +#include "devices-imx50.h"
>
> ?static iomux_v3_cfg_t mx50_rdp_pads[] __initdata = {
> ? ? ? ?/* SD1 */
> diff --git a/arch/arm/mach-mx5/devices-mx50.h b/arch/arm/mach-mx5/devices-imx50.h
> similarity index 100%
> rename from arch/arm/mach-mx5/devices-mx50.h
> rename to arch/arm/mach-mx5/devices-imx50.h
> --
> 1.7.0.4
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 4/5 v2] ARM: pxa: Fix suspend/resume array index miscalculation
From: Marek Vasut @ 2011-01-10 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=+0M_j0r8sy_RbVrJ3fufm7E-tREm8TepAwdzq@mail.gmail.com>
On Tuesday 11 January 2011 00:41:26 Eric Miao wrote:
> On Mon, Jan 10, 2011 at 4:53 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> > ---
> > v2: Fix loop condition as proposed by Sergei
> >
> > arch/arm/mach-pxa/irq.c | 8 ++++----
> > 1 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
> > index 78f0e0c..a7deff5 100644
> > --- a/arch/arm/mach-pxa/irq.c
> > +++ b/arch/arm/mach-pxa/irq.c
> > @@ -156,7 +156,7 @@ static inline void __iomem *irq_base(int i)
> > 0x40d00130,
> > };
> >
> > - return (void __iomem *)io_p2v(phys_base[i >> 5]);
> > + return (void __iomem *)io_p2v(phys_base[i]);
> > }
> >
> > void __init pxa_init_irq(int irq_nr, set_wake_t fn)
> > @@ -168,7 +168,7 @@ void __init pxa_init_irq(int irq_nr, set_wake_t fn)
> > pxa_internal_irq_nr = irq_nr;
> >
> > for (n = 0; n < irq_nr; n += 32) {
> > - void __iomem *base = irq_base(n);
> > + void __iomem *base = irq_base(n >> 5);
> >
> > __raw_writel(0, base + ICMR); /* disable all IRQs */
> > __raw_writel(0, base + ICLR); /* all IRQs are IRQ, not
> > FIQ */ @@ -200,7 +200,7 @@ static int pxa_irq_suspend(struct sys_device
> > *dev, pm_message_t state) {
> > int i;
> >
> > - for (i = 0; i < pxa_internal_irq_nr; i += 32) {
> > + for (i = 0; i < pxa_internal_irq_nr / 32; i++) {
> > void __iomem *base = irq_base(i);
>
> I prefer it to be IRQ number based instead of IRQ bank based,
>
> in other word, I'd rather to change the statement below:
> > saved_icmr[i] = __raw_readl(base + ICMR);
>
> to something:
>
> saved_icmr[i / 32] = __raw_read(base + ICMR);
Exactly what I wanted to avoid ... won't you be doing a division "# of bank"-
times instead of once there ?
>
> > @@ -219,7 +219,7 @@ static int pxa_irq_resume(struct sys_device *dev)
> > {
> > int i;
> >
> > - for (i = 0; i < pxa_internal_irq_nr; i += 32) {
> > + for (i = 0; i < pxa_internal_irq_nr / 32; i++) {
> > void __iomem *base = irq_base(i);
> >
> > __raw_writel(saved_icmr[i], base + ICMR);
> > --
> > 1.7.2.3
^ permalink raw reply
* [PATCH] spi: tegra: don't treat NULL clk as an error
From: Grant Likely @ 2011-01-10 23:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110110233033.GG12552@n2100.arm.linux.org.uk>
On Mon, Jan 10, 2011 at 11:30:33PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 10, 2011 at 04:24:17PM -0700, Grant Likely wrote:
> > I was actually looking at the implementation of clk_enable() which is
> > called by the driver and doesn't do any NULL checking. But I suppose
> > that it then becomes the clock-code's own fault if it returns NULL and
> > then oopses on a NULL being passed to it. Okay, I'll apply it.
>
> Yes absolutely. The clk API must eat whatever cookies it produces,
> even if they contain dead flies rather than currants. ;)
nice analogy. :-)
g.
^ 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