* [PATCH 2/4] ARM: i.MX53 EVK: add spi device
From: yong.shen at freescale.com @ 2011-01-11 12:45 UTC (permalink / raw)
To: linux-arm-kernel
From: Yong Shen <yong.shen@freescale.com>
1. add platform data for spi device
2. Kconfig change
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/Kconfig | 1 +
arch/arm/mach-mx5/board-mx53_evk.c | 21 +++++++++++++++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 23b0e3f..777740b 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -126,6 +126,7 @@ config MACH_MX53_EVK
select IMX_HAVE_PLATFORM_IMX_UART
select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
+ select IMX_HAVE_PLATFORM_SPI_IMX
help
Include support for MX53 EVK platform. This includes specific
configurations for the board and its peripherals.
diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
index 4043451..739bc62 100644
--- a/arch/arm/mach-mx5/board-mx53_evk.c
+++ b/arch/arm/mach-mx5/board-mx53_evk.c
@@ -33,6 +33,8 @@
#include <mach/iomux-mx53.h>
#define SMD_FEC_PHY_RST IMX_GPIO_NR(7, 6)
+#define EVK_ECSPI1_CS0 IMX_GPIO_NR(2, 30)
+#define EVK_ECSPI1_CS1 IMX_GPIO_NR(3, 19)
#include "crm_regs.h"
#include "devices-imx53.h"
@@ -52,6 +54,13 @@ static iomux_v3_cfg_t mx53_evk_pads[] = {
MX53_PAD_ATA_CS_1__UART3_RXD,
MX53_PAD_ATA_DA_1__UART3_CTS,
MX53_PAD_ATA_DA_2__UART3_RTS,
+
+ MX53_PAD_EIM_D16__GPIO_3_16,
+ MX53_PAD_EIM_D17__GPIO_3_17,
+ MX53_PAD_EIM_D18__GPIO_3_18,
+
+ MX53_PAD_EIM_EB2__GPIO_2_30,
+ MX53_PAD_EIM_D19__GPIO_3_19,
};
static const struct imxuart_platform_data mx53_evk_uart_pdata __initconst = {
@@ -89,6 +98,16 @@ static struct fec_platform_data mx53_evk_fec_pdata = {
.phy = PHY_INTERFACE_MODE_RMII,
};
+static int mx53_evk_spi_cs[] = {
+ EVK_ECSPI1_CS0,
+ EVK_ECSPI1_CS1,
+};
+
+static const struct spi_imx_master mx53_evk_spi_data __initconst = {
+ .chipselect = mx53_evk_spi_cs,
+ .num_chipselect = ARRAY_SIZE(mx53_evk_spi_cs),
+};
+
static void __init mx53_evk_board_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx53_evk_pads,
@@ -102,6 +121,8 @@ static void __init mx53_evk_board_init(void)
imx53_add_sdhci_esdhc_imx(0, NULL);
imx53_add_sdhci_esdhc_imx(1, NULL);
+
+ imx53_add_ecspi(0, &mx53_evk_spi_data);
}
static void __init mx53_evk_timer_init(void)
--
1.7.1
^ permalink raw reply related
* [PATCH 16/16] w1: mxc_w1: don't treat NULL clk as an error
From: Jamie Iles @ 2011-01-11 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294749833-32019-1-git-send-email-jamie@jamieiles.com>
clk_get() returns a struct clk cookie to the driver and some platforms
may return NULL if they only support a single clock. clk_get() has only
failed if it returns a ERR_PTR() encoded pointer.
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
drivers/w1/masters/mxc_w1.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c
index a3b6a74..67ea082 100644
--- a/drivers/w1/masters/mxc_w1.c
+++ b/drivers/w1/masters/mxc_w1.c
@@ -21,6 +21,7 @@
#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <linux/clk.h>
+#include <linux/err.h>
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/io.h>
@@ -118,8 +119,8 @@ static int __devinit mxc_w1_probe(struct platform_device *pdev)
return -ENOMEM;
mdev->clk = clk_get(&pdev->dev, "owire");
- if (!mdev->clk) {
- err = -ENODEV;
+ if (IS_ERR(mdev->clk)) {
+ err = PTR_ERR(mdev->clk);
goto failed_clk;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 09/16] ARM: pxa: don't treat NULL clk as an error
From: Jamie Iles @ 2011-01-11 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294749833-32019-1-git-send-email-jamie@jamieiles.com>
clk_get() returns a struct clk cookie to the driver and some platforms
may return NULL if they only support a single clock. clk_get() has only
failed if it returns a ERR_PTR() encoded pointer.
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
drivers/pcmcia/pxa2xx_base.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pcmcia/pxa2xx_base.c b/drivers/pcmcia/pxa2xx_base.c
index 3755e7c..6e5b55e 100644
--- a/drivers/pcmcia/pxa2xx_base.c
+++ b/drivers/pcmcia/pxa2xx_base.c
@@ -16,6 +16,7 @@
======================================================================*/
+#include <linux/err.h>
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/init.h>
@@ -297,8 +298,8 @@ static int pxa2xx_drv_pcmcia_probe(struct platform_device *dev)
}
clk = clk_get(&dev->dev, NULL);
- if (!clk)
- return -ENODEV;
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
pxa2xx_drv_pcmcia_ops(ops);
--
1.7.3.4
^ permalink raw reply related
* [PATCH 08/16] ARM: samsung: serial: don't treat NULL clk as an error
From: Jamie Iles @ 2011-01-11 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294749833-32019-1-git-send-email-jamie@jamieiles.com>
clk_get() returns a struct clk cookie to the driver and some platforms
may return NULL if they only support a single clock. clk_get() has only
failed if it returns a ERR_PTR() encoded pointer.
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
drivers/serial/samsung.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/samsung.c b/drivers/serial/samsung.c
index 7ac2bf5..be93d2f 100644
--- a/drivers/serial/samsung.c
+++ b/drivers/serial/samsung.c
@@ -42,6 +42,7 @@
#include <linux/serial.h>
#include <linux/delay.h>
#include <linux/clk.h>
+#include <linux/err.h>
#include <linux/cpufreq.h>
#include <asm/irq.h>
@@ -522,7 +523,7 @@ static int s3c24xx_serial_calcbaud(struct baud_calc *calc,
unsigned long rate;
calc->src = clk_get(port->dev, clksrc->name);
- if (calc->src == NULL || IS_ERR(calc->src))
+ if (IS_ERR(calc->src))
return 0;
rate = clk_get_rate(calc->src);
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2 v1] davinci: support disabling modem status interrupts on SOC UARTS
From: Michael Williamson @ 2011-01-11 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024829BCD4@dbde02.ent.ti.com>
On 1/11/2011 3:17 AM, Manjunathappa, Prakash wrote:
> Hi Michael,
>
> On Wed, Jan 05, 2011 at 17:56:31, Michael Williamson wrote:
>> On the da850/omap-l138/am18x family of SoCs, up to three on chip UARTS may be
>> configured. These peripherals support the standard Tx/Rx signals as well as
>> CTS/RTS hardware flow control signals. The pins on these SOC's associated with
>> these signals are multiplexed; e.g., the pin providing UART0_TXD capability
>> also provides SPI0 chip select line 5 output capability. The configuration of
>> the pin multiplexing occurs during platform initialization (or by earlier
>> bootloader operations).
>>
>> There is a problem with the multiplexing implementation on these SOCs. Only
>> the output and output enable portions of the I/O section of the pin are
>> multiplexed. All peripheral input functions remain connected to a given pin
>> regardless of configuration.
>>
>> In many configurations of these parts, providing a UART with Tx/Rx capability
>> is needed, but the HW flow control capability is not. Furthermore, the pins
>> associated with the CTS inputs on these UARTS are often configured to support
>> a different peripheral, and they may be active/toggling during runtime. This
>> can result in false modem status (CTS) interrupts being asserted to the 8250
>> driver controlling the associated Tx/Rx pins, and will impact system
>> performance.
>>
>> The 8250 serial driver platform data does not provide a direct mechanism to
>> tell the driver to disable modem status (i.e., CTS) interrupts for a given
>> port. As a work-around, intercept register writes to the IER and disable
>> modem status interrupts.
>>
>> This patch was tested using a MityDSP-L138 SOM having UART1 enabled with the
>> associated CTS pin connected to a clock (configured for the AHCLKX function).
>>
>> Background / problem reports related to this issue are captured in the links
>> below:
>> http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/36701.aspx
>> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg19524.html
>>
>> Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
>> Tested-by: Michael Williamson <michael.williamson@criticallink.com>
>> ---
>> This is against the linux-davinci tree.
>>
>> Changes from original proposed patch:
>> - instead of overriding set_termios, now override serial_out driver hook
>> and intercept writes to the MSR.
>>
>> An alternate patch was proposed that modified the serial core driver and added a UPF_NO_MSR
>> flag. There was resistance to this patch. The reasoning is that the core 8250 driver code
>> should not continue to get muddied by platform hacks.
>>
>> I'm wondering, given this and the original proposed patch, if the set_termios
>> override might be better? This patch incurs a test penalty every time the UART
>> is accessed; whereas the original patch only incurs a penalty on IOCTL calls. The
>> set_termios would at least report the proper IOCTL information for CRTSCTS
>> when probed, I think, instead of just quietly lying about it...
>>
>> arch/arm/mach-davinci/include/mach/serial.h | 2 ++
>> arch/arm/mach-davinci/serial.c | 19 +++++++++++++++++++
>> 2 files changed, 21 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h
>> index 8051110..8f7f5e5 100644
>> --- a/arch/arm/mach-davinci/include/mach/serial.h
>> +++ b/arch/arm/mach-davinci/include/mach/serial.h
>> @@ -49,6 +49,8 @@
>> struct davinci_uart_config {
>> /* Bit field of UARTs present; bit 0 --> UART1 */
>> unsigned int enabled_uarts;
>> + /* Bit field of modem status interrupt disables; bit 0 -> UART1 */
>> + unsigned int disable_msi;
>> };
>>
>> extern int davinci_serial_init(struct davinci_uart_config *);
>> diff --git a/arch/arm/mach-davinci/serial.c b/arch/arm/mach-davinci/serial.c
>> index 1875740..83d44c0 100644
>> --- a/arch/arm/mach-davinci/serial.c
>> +++ b/arch/arm/mach-davinci/serial.c
>> @@ -31,6 +31,22 @@
>> #include <mach/serial.h>
>> #include <mach/cputype.h>
>>
>> +static void davinci_serial_out_nomsi(struct uart_port *p, int offset, int value)
>> +{
>> + int lcr, lcr_off;
>> +
>> + if (offset == UART_IER) {
>> + lcr_off = UART_LCR << p->regshift;
>> + lcr = readb(p->membase + lcr_off);
>> + /* don't override DLM setting, or probing operations */
>> + if (!(lcr & UART_LCR_DLAB) && p->type != PORT_UNKNOWN)
>> + value &= ~UART_IER_MSI;
>> + }
>> +
>> + offset <<= p->regshift;
>> + writeb(value, p->membase + offset);
>> +}
>> +
>> static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
>> int offset)
>> {
>> @@ -109,6 +125,9 @@ int __init davinci_serial_init(struct davinci_uart_config *info)
>>
>> if (p->membase && p->type != PORT_AR7)
>> davinci_serial_reset(p);
>> +
>> + if (info->disable_msi & (1 << i))
>> + p->serial_out = davinci_serial_out_nomsi;
>> }
>>
>> return platform_device_register(soc_info->serial_dev);
>> --
>> 1.7.0.4
>>
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>>
> When status of CTS input is wrong, why can't we say flow control not
> supported on particular port and return an error to application trying to
> enable hardware flow control(i.e. set CRTSCTS). I am assuming you are seeing
> the spurious interrupts only on enabling hardware flow control(as modem
> status interrupt is enabled on setting the CRTSCTS).
>
This was pretty much what the original patch I had proposed did. There are
actually two termios flags that cause MS interrupts to be enabled by the
driver, CLOCAL (disabled) or CRTSCTS (enabled). I observed that some
process after the kernel had completed booting (getty, I think)
was calling set_termios with CLOCAL disabled (not CRTSCTS enabled). I could
probably alter the getty args to work around it, but it's a bit of a hole to
not have something in the kernel to preclude sending the OS to "interrupt
hell".
Is there another way to accomplish what you are suggesting that is different
from the original patch?
Thanks for the comments.
-Mike
Background: The original patch (not accepted) is here
https://patchwork.kernel.org/patch/442671/
This kicked a second email thread:
http://marc.info/?l=linux-serial&m=129409970003827&w=4
^ permalink raw reply
* [PATCH] ARM: nommu: avoid mapping vectors page when !CONFIG_MMU
From: Greg Ungerer @ 2011-01-11 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294747337-18238-1-git-send-email-will.deacon@arm.com>
Hi Will,
On 11/01/11 22:02, Will Deacon wrote:
> When running without an MMU, we do not need to install a mapping for the
> vectors page. Attempting to do so causes a compile-time error because
> install_special_mapping is not defined.
>
> This patch adds compile-time guards to the vector mapping functions
> so that we can build nommu configurations once more.
>
> Cc: Greg Ungerer<gerg@uclinux.org>
> Signed-off-by: Will Deacon<will.deacon@arm.com>
I hit this a couple of days ago too, looks good.
Acked-by: Greg Ungerer <gerg@uclinux.org>
Regards
Greg
> arch/arm/kernel/process.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index e76fcaa..94bbedb 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -483,6 +483,7 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
> return randomize_range(mm->brk, range_end, 0) ? : mm->brk;
> }
>
> +#ifdef CONFIG_MMU
> /*
> * The vectors page is always readable from user space for the
> * atomic helpers and the signal restart code. Let's declare a mapping
> @@ -503,3 +504,4 @@ const char *arch_vma_name(struct vm_area_struct *vma)
> {
> return (vma->vm_start == 0xffff0000) ? "[vectors]" : NULL;
> }
> +#endif
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close, FAX: +61 7 3891 3630
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* [PATCH v4 05/10] net/fec: add dual fec support for mx28
From: Greg Ungerer @ 2011-01-11 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111102717.GG26617@pengutronix.de>
On 11/01/11 20:27, Sascha Hauer wrote:
> On Thu, Jan 06, 2011 at 03:13:13PM +0800, Shawn Guo wrote:
>> This patch is to add mx28 dual fec support. Here are some key notes
>> for mx28 fec controller.
>>
>> - The mx28 fec controller naming ENET-MAC is a different IP from FEC
>> used on other i.mx variants. But they are basically compatible
>> on software interface, so it's possible to share the same driver.
>> - ENET-MAC design on mx28 made an improper assumption that it runs
>> on a big-endian system. As the result, driver has to swap every
>> frame going to and coming from the controller.
>> - The external phys can only be configured by fec0, which means fec1
>> can not work independently and both phys need to be configured by
>> mii_bus attached on fec0.
>> - ENET-MAC reset will get mac address registers reset too.
>> - ENET-MAC MII/RMII mode and 10M/100M speed are configured
>> differently FEC.
>> - ETHER_EN bit must be set to get ENET-MAC interrupt work.
>>
>> Signed-off-by: Shawn Guo<shawn.guo@freescale.com>
>> ---
>> Changes for v4:
>> - Use #ifndef CONFIG_ARM to include ColdFire header files
>> - Define quirk bits in id_entry.driver_data to handle controller
>> difference, which is more scalable than using device name
>> - Define fec0_mii_bus as a static function in fec_enet_mii_init
>> to fold the mii_bus instance attached on fec0
>> - Use cpu_to_be32 over __swab32 in function swap_buffer
>>
>> Changes for v3:
>> - Move v2 changes into patch #3
>> - Use device name to check if it's running on ENET-MAC
>>
>> drivers/net/Kconfig | 7 ++-
>> drivers/net/fec.c | 148 +++++++++++++++++++++++++++++++++++++++++++++------
>> drivers/net/fec.h | 5 +-
>> 3 files changed, 139 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
>> index 4f1755b..f34629b 100644
>> --- a/drivers/net/Kconfig
>> +++ b/drivers/net/Kconfig
>> @@ -1944,18 +1944,19 @@ config 68360_ENET
>> config FEC
>> bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
>> depends on M523x || M527x || M5272 || M528x || M520x || M532x || \
>> - MACH_MX27 || ARCH_MX35 || ARCH_MX25 || ARCH_MX5
>> + MACH_MX27 || ARCH_MX35 || ARCH_MX25 || ARCH_MX5 || SOC_IMX28
>> select PHYLIB
>> help
>> Say Y here if you want to use the built-in 10/100 Fast ethernet
>> controller on some Motorola ColdFire and Freescale i.MX processors.
>>
>> config FEC2
>> - bool "Second FEC ethernet controller (on some ColdFire CPUs)"
>> + bool "Second FEC ethernet controller"
>> depends on FEC
>> help
>> Say Y here if you want to use the second built-in 10/100 Fast
>> - ethernet controller on some Motorola ColdFire processors.
>> + ethernet controller on some Motorola ColdFire and Freescale
>> + i.MX processors.
>
> This option is used nowhere and should be removed. Certainly it does not
> have the effect of enabling the second ethernet controller.
It does for a ColdFire platform...
grep -r CONFIG_FEC2 *
arch/m68knommu/configs/m5275evb_defconfig:CONFIG_FEC2=y
arch/m68knommu/platform/527x/config.c:#ifdef CONFIG_FEC2
arch/m68knommu/platform/527x/config.c:#ifdef CONFIG_FEC2
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close, FAX: +61 7 3891 3630
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Locking in the clk API
From: Paul Mundt @ 2011-01-11 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101111830.18597.jeremy.kerr@canonical.com>
On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:
> Hi Paul,
>
> > No, the sleeping clock case is and always will be a corner case, and I
> > have no interest in pretending otherwise. On SH we have hundreds of
> > clocks that are all usable in the atomic context and perhaps less than a
> > dozen that aren't (and even in those cases much of the PLL negotiation is
> > handled in hardware so there's never any visibility for the lock-down
> > from the software side, other architectures also have similar behaviour).
>
> I'm not too worried about the corner-cases on the *implementation* side, more
> the corner-cases on the API side: are we seeing more users of the API that
> require an atomic clock, or more that don't care?
>
Again, you are approaching it from the angle that an atomic clock is a
special requirement rather than the default behaviour. Sleeping for
lookup, addition, and deletion are all quite acceptable, but
enable/disable pairs have always been intended to be usable from atomic
context. Anyone that doesn't count on that fact is either dealing with
special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
implementing any sort of fine grained runtime power management for their
platform.
It's unfortunate that you managed to pick one of the three or so
platforms with broken semantics to base your implementation off of, but
rest assured, everyone else did infact get it right, at least so far.
^ permalink raw reply
* [PATCH] ARM: nommu: avoid mapping vectors page when !CONFIG_MMU
From: Russell King - ARM Linux @ 2011-01-11 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294747337-18238-1-git-send-email-will.deacon@arm.com>
On Tue, Jan 11, 2011 at 12:02:17PM +0000, Will Deacon wrote:
> When running without an MMU, we do not need to install a mapping for the
> vectors page. Attempting to do so causes a compile-time error because
> install_special_mapping is not defined.
>
> This patch adds compile-time guards to the vector mapping functions
> so that we can build nommu configurations once more.
I had a similar patch a few days ago doing the same thing... when Greg's
acked it, please submit to the patch system, thanks.
^ permalink raw reply
* [PATCH 2/3] ARM i.MX53 enable spi on EVK board
From: Yong Shen @ 2011-01-11 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111104328.GI26617@pengutronix.de>
Hi Sascha and Uwe,
Your comments are acked.
thanks
Yong
2011/1/11 Sascha Hauer <s.hauer@pengutronix.de>:
> On Tue, Jan 11, 2011 at 10:15:49AM +0100, Uwe Kleine-K?nig wrote:
>> Hello,
>>
>> I'd prefer to have the following subject:
>>
>> ? ? ? ARM: mx5/mx53_evk: add spi device
>>
>> On Mon, Jan 10, 2011 at 08:08:53PM +0800, yong.shen at freescale.com wrote:
>> > From: Yong Shen <yong.shen@freescale.com>
>> >
>> > 1. some macro definitions fix
>> > 2. add platform data for spi device
>> > 3. register spi clocks
>> >
>> > Signed-off-by: Yong Shen <yong.shen@freescale.com>
>> > ---
>> > ?arch/arm/mach-mx5/Kconfig ? ? ? ? ? ? ? ? ? ?| ? ?1 +
>> > ?arch/arm/mach-mx5/board-mx53_evk.c ? ? ? ? ? | ? 14 ++++++++++++++
>> > ?arch/arm/mach-mx5/clock-mx51-mx53.c ? ? ? ? ?| ? ?3 +++
>> > ?arch/arm/mach-mx5/devices-imx53.h ? ? ? ? ? ?| ? ?4 ++++
>> > ?arch/arm/plat-mxc/devices/platform-spi_imx.c | ? 12 ++++++++++++
>> > ?arch/arm/plat-mxc/include/mach/mx53.h ? ? ? ?| ? 10 +++++-----
>> > ?6 files changed, 39 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
>> > index 23b0e3f..777740b 100644
>> > --- a/arch/arm/mach-mx5/Kconfig
>> > +++ b/arch/arm/mach-mx5/Kconfig
>> > @@ -126,6 +126,7 @@ config MACH_MX53_EVK
>> > ? ? select IMX_HAVE_PLATFORM_IMX_UART
>> > ? ? select IMX_HAVE_PLATFORM_IMX_I2C
>> > ? ? select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
>> > + ? select IMX_HAVE_PLATFORM_SPI_IMX
>> > ? ? help
>> > ? ? ? Include support for MX53 EVK platform. This includes specific
>> > ? ? ? configurations for the board and its peripherals.
>> > diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
>> > index 4043451..8017d68 100644
>> > --- a/arch/arm/mach-mx5/board-mx53_evk.c
>> > +++ b/arch/arm/mach-mx5/board-mx53_evk.c
>> > @@ -33,6 +33,8 @@
>> > ?#include <mach/iomux-mx53.h>
>> >
>> > ?#define SMD_FEC_PHY_RST ? ? ? ? ? ?IMX_GPIO_NR(7, 6)
>> > +#define EVK_ECSPI1_CS0 ? ? ? ? ? ? IMX_GPIO_NR(3, 19)
>> > +#define EVK_ECSPI1_CS1 ? ? ? ? ? ? IMX_GPIO_NR(2, 30)
>> >
>> > ?#include "crm_regs.h"
>> > ?#include "devices-imx53.h"
>> > @@ -89,6 +91,16 @@ static struct fec_platform_data mx53_evk_fec_pdata = {
>> > ? ? .phy = PHY_INTERFACE_MODE_RMII,
>> > ?};
>> >
>> > +static int mx53_evk_spi_cs[] = {
>> > + ? EVK_ECSPI1_CS0,
>> > + ? EVK_ECSPI1_CS1,
>> don't you need to setup some pinmuxing to make this work?
>>
>> > +};
>> > +
>> > +static const struct spi_imx_master mx53_evk_spi_data __initconst = {
>> > + ? .chipselect ? ? = mx53_evk_spi_cs,
>> > + ? .num_chipselect = ARRAY_SIZE(mx53_evk_spi_cs),
>> > +};
>> > +
>> > ?static void __init mx53_evk_board_init(void)
>> > ?{
>> > ? ? mxc_iomux_v3_setup_multiple_pads(mx53_evk_pads,
>> > @@ -102,6 +114,8 @@ static void __init mx53_evk_board_init(void)
>> >
>> > ? ? imx53_add_sdhci_esdhc_imx(0, NULL);
>> > ? ? imx53_add_sdhci_esdhc_imx(1, NULL);
>> > +
>> > + ? imx53_add_ecspi(0, &mx53_evk_spi_data);
>> > ?}
>> >
>> > ?static void __init mx53_evk_timer_init(void)
>> > diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
>> > index d0f58a3..a20d0c0 100644
>> > --- a/arch/arm/mach-mx5/clock-mx51-mx53.c
>> > +++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
>> > @@ -1330,6 +1330,9 @@ static struct clk_lookup mx53_lookups[] = {
>> > ? ? _REGISTER_CLOCK("imx-i2c.1", NULL, i2c2_clk)
>> > ? ? _REGISTER_CLOCK("sdhci-esdhc-imx.0", NULL, esdhc1_clk)
>> > ? ? _REGISTER_CLOCK("sdhci-esdhc-imx.1", NULL, esdhc2_clk)
>> > + ? _REGISTER_CLOCK("imx53-ecspi.0", NULL, ecspi1_clk)
>> > + ? _REGISTER_CLOCK("imx53-ecspi.1", NULL, ecspi2_clk)
>> > + ? _REGISTER_CLOCK("imx53-cspi.0", NULL, cspi_clk)
>> maybe this should better go into a seperate patch? ?(i.e.
>>
>> ? ? ? ARM: mx53: add support to dynamically register imx-spi devices
>
> Yes. We should not add mix architecture support and board support in a
> single patch.
>
> Sascha
>
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 ? ?|
> Amtsgericht Hildesheim, HRA 2686 ? ? ? ? ? | Fax: ? +49-5121-206917-5555 |
>
^ permalink raw reply
* Locking in the clk API
From: Jassi Brar @ 2011-01-11 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111091607.GI12552@n2100.arm.linux.org.uk>
On Tue, Jan 11, 2011 at 2:46 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>> At present, we can satisfy these with:
>>
>> * clk_enable: may sleep
>
> I object to this as one of the purposes behind the clk API is to allow
> power savings to be made, and unless we can perform clk enable/disable
> from atomic contexts, the best you can do is enable the clock when the
> device is probed and disable it when it's released.
>
> For a lot of systems, modules are loaded at boot, and devices are probed
> at boot time. ?They're never unloaded.
>
> This means that clocks will be enabled at boot time and never turned off.
>
> If you're lucky, there may be open/release methods which can be used to
> enable/disable the clock, which reduces the 'clock on' period down to
> the point where userspace opens/closes the device. ?That's still
> insufficient and in some cases there aren't calls for this.
>
> Sometimes the only point that you know you need the clock enabled is when
> your driver has already been called in an atomic context.
>
> If such a requirement is imposed, it means that a driver would either have
> to leave the clock always on, or would have to drop such calls if the
> clock wasn't already enabled.
Perhaps we should factor the conventional clk_enable into two parts (say) :-
a) clk_setup : Which does exactly what can't be done in atomic context.
Like setting PLLs i.e, if that needs to sleep.
b) clk_enable : Everything else that gets the clock signals running.
The drivers could do clk_setup in probe/open and clk_enable right before the
the actual need of the clock. That way, drivers don't have to bother
with platform/clock
peculiarities while trying their best to save power.
Of course, power that can't be saved now, won't be saved then.
^ permalink raw reply
* [PATCH v5] ARM: mx28: add the second fec device registration
From: Shawn Guo @ 2011-01-11 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294297998-26930-1-git-send-email-shawn.guo@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
Changes for v5:
- Do not use CONFIG_FEC2 which is a fec driver configration
arch/arm/mach-mxs/mach-mx28evk.c | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
index d162e95..8e2c597 100644
--- a/arch/arm/mach-mxs/mach-mx28evk.c
+++ b/arch/arm/mach-mxs/mach-mx28evk.c
@@ -57,6 +57,19 @@ static const iomux_cfg_t mx28evk_pads[] __initconst = {
(MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
MX28_PAD_ENET_CLK__CLKCTRL_ENET |
(MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ /* fec1 */
+ MX28_PAD_ENET0_CRS__ENET1_RX_EN |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_ENET0_RXD2__ENET1_RXD0 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_ENET0_RXD3__ENET1_RXD1 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_ENET0_COL__ENET1_TX_EN |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_ENET0_TXD2__ENET1_TXD0 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+ MX28_PAD_ENET0_TXD3__ENET1_TXD1 |
+ (MXS_PAD_8MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
/* phy power line */
MX28_PAD_SSP1_DATA3__GPIO_2_15 |
(MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
@@ -106,8 +119,14 @@ static void __init mx28evk_fec_reset(void)
gpio_set_value(MX28EVK_FEC_PHY_RESET, 1);
}
-static const struct fec_platform_data mx28_fec_pdata __initconst = {
- .phy = PHY_INTERFACE_MODE_RMII,
+static struct fec_platform_data mx28_fec_pdata[] = {
+ {
+ /* fec0 */
+ .phy = PHY_INTERFACE_MODE_RMII,
+ }, {
+ /* fec1 */
+ .phy = PHY_INTERFACE_MODE_RMII,
+ },
};
static void __init mx28evk_init(void)
@@ -117,7 +136,8 @@ static void __init mx28evk_init(void)
mx28_add_duart();
mx28evk_fec_reset();
- mx28_add_fec(0, &mx28_fec_pdata);
+ mx28_add_fec(0, &mx28_fec_pdata[0]);
+ mx28_add_fec(1, &mx28_fec_pdata[1]);
}
static void __init mx28evk_timer_init(void)
--
1.7.1
^ permalink raw reply related
* [PATCH] net/fec: remove config FEC2 as it's used nowhere
From: Shawn Guo @ 2011-01-11 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294297998-26930-1-git-send-email-shawn.guo@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
drivers/net/Kconfig | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f34629b..24b1b33 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1950,14 +1950,6 @@ config FEC
Say Y here if you want to use the built-in 10/100 Fast ethernet
controller on some Motorola ColdFire and Freescale i.MX processors.
-config FEC2
- bool "Second FEC ethernet controller"
- depends on FEC
- help
- Say Y here if you want to use the second built-in 10/100 Fast
- ethernet controller on some Motorola ColdFire and Freescale
- i.MX processors.
-
config FEC_MPC52xx
tristate "MPC52xx FEC driver"
depends on PPC_MPC52xx && PPC_BESTCOMM
--
1.7.1
^ permalink raw reply related
* [PATCH] ARM: nommu: avoid mapping vectors page when !CONFIG_MMU
From: Will Deacon @ 2011-01-11 12:02 UTC (permalink / raw)
To: linux-arm-kernel
When running without an MMU, we do not need to install a mapping for the
vectors page. Attempting to do so causes a compile-time error because
install_special_mapping is not defined.
This patch adds compile-time guards to the vector mapping functions
so that we can build nommu configurations once more.
Cc: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/process.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index e76fcaa..94bbedb 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -483,6 +483,7 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
return randomize_range(mm->brk, range_end, 0) ? : mm->brk;
}
+#ifdef CONFIG_MMU
/*
* The vectors page is always readable from user space for the
* atomic helpers and the signal restart code. Let's declare a mapping
@@ -503,3 +504,4 @@ const char *arch_vma_name(struct vm_area_struct *vma)
{
return (vma->vm_start == 0xffff0000) ? "[vectors]" : NULL;
}
+#endif
--
1.7.0.4
^ permalink raw reply related
* [PATCH] TWD: enable one-shot mode
From: Russell King - ARM Linux @ 2011-01-11 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2BE6C4.4040806@codeaurora.org>
On Mon, Jan 10, 2011 at 09:12:36PM -0800, Stephen Boyd wrote:
> 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?
You're right - so it's not actually required. It should probably be
reverted, though it does no damage...
^ permalink raw reply
* [PATCH v4 07/10] ARM: mx28: add the second fec device registration
From: Sascha Hauer @ 2011-01-11 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111113951.GB2888@freescale.com>
On Tue, Jan 11, 2011 at 07:39:52PM +0800, Shawn Guo wrote:
> Hi Sascha,
>
> On Tue, Jan 11, 2011 at 11:29:09AM +0100, Sascha Hauer wrote:
> > On Thu, Jan 06, 2011 at 03:13:15PM +0800, Shawn Guo wrote:
> > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > ---
> > > arch/arm/mach-mxs/mach-mx28evk.c | 28 +++++++++++++++++++++++++---
> > > 1 files changed, 25 insertions(+), 3 deletions(-)
> > >
> > >
> > > static void __init mx28evk_init(void)
> > > @@ -117,7 +136,10 @@ static void __init mx28evk_init(void)
> > > mx28_add_duart();
> > >
> > > mx28evk_fec_reset();
> > > - mx28_add_fec(0, &mx28_fec_pdata);
> > > + mx28_add_fec(0, &mx28_fec_pdata[0]);
> > > +#ifdef CONFIG_FEC2
> > > + mx28_add_fec(1, &mx28_fec_pdata[1]);
> > > +#endif
> >
> > Please don't do this. If you really want to make this configurable with
> > kconfig use a board specific option, not a driver specific option. I
> > think this should be made unconditional though.
> >
> I will resend this patch as v5 than the whole patch set, if you
> do not mind.
ok
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v4 07/10] ARM: mx28: add the second fec device registration
From: Shawn Guo @ 2011-01-11 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111102909.GH26617@pengutronix.de>
Hi Sascha,
On Tue, Jan 11, 2011 at 11:29:09AM +0100, Sascha Hauer wrote:
> On Thu, Jan 06, 2011 at 03:13:15PM +0800, Shawn Guo wrote:
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > ---
> > arch/arm/mach-mxs/mach-mx28evk.c | 28 +++++++++++++++++++++++++---
> > 1 files changed, 25 insertions(+), 3 deletions(-)
> >
> >
> > static void __init mx28evk_init(void)
> > @@ -117,7 +136,10 @@ static void __init mx28evk_init(void)
> > mx28_add_duart();
> >
> > mx28evk_fec_reset();
> > - mx28_add_fec(0, &mx28_fec_pdata);
> > + mx28_add_fec(0, &mx28_fec_pdata[0]);
> > +#ifdef CONFIG_FEC2
> > + mx28_add_fec(1, &mx28_fec_pdata[1]);
> > +#endif
>
> Please don't do this. If you really want to make this configurable with
> kconfig use a board specific option, not a driver specific option. I
> think this should be made unconditional though.
>
I will resend this patch as v5 than the whole patch set, if you
do not mind.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v4 05/10] net/fec: add dual fec support for mx28
From: Shawn Guo @ 2011-01-11 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111102717.GG26617@pengutronix.de>
On Tue, Jan 11, 2011 at 11:27:17AM +0100, Sascha Hauer wrote:
> On Thu, Jan 06, 2011 at 03:13:13PM +0800, Shawn Guo wrote:
> > This patch is to add mx28 dual fec support. Here are some key notes
> > for mx28 fec controller.
> >
> > - The mx28 fec controller naming ENET-MAC is a different IP from FEC
> > used on other i.mx variants. But they are basically compatible
> > on software interface, so it's possible to share the same driver.
> > - ENET-MAC design on mx28 made an improper assumption that it runs
> > on a big-endian system. As the result, driver has to swap every
> > frame going to and coming from the controller.
> > - The external phys can only be configured by fec0, which means fec1
> > can not work independently and both phys need to be configured by
> > mii_bus attached on fec0.
> > - ENET-MAC reset will get mac address registers reset too.
> > - ENET-MAC MII/RMII mode and 10M/100M speed are configured
> > differently FEC.
> > - ETHER_EN bit must be set to get ENET-MAC interrupt work.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > ---
> > Changes for v4:
> > - Use #ifndef CONFIG_ARM to include ColdFire header files
> > - Define quirk bits in id_entry.driver_data to handle controller
> > difference, which is more scalable than using device name
> > - Define fec0_mii_bus as a static function in fec_enet_mii_init
> > to fold the mii_bus instance attached on fec0
> > - Use cpu_to_be32 over __swab32 in function swap_buffer
> >
> > Changes for v3:
> > - Move v2 changes into patch #3
> > - Use device name to check if it's running on ENET-MAC
> >
> > drivers/net/Kconfig | 7 ++-
> > drivers/net/fec.c | 148 +++++++++++++++++++++++++++++++++++++++++++++------
> > drivers/net/fec.h | 5 +-
> > 3 files changed, 139 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index 4f1755b..f34629b 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
> > @@ -1944,18 +1944,19 @@ config 68360_ENET
> > config FEC
> > bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
> > depends on M523x || M527x || M5272 || M528x || M520x || M532x || \
> > - MACH_MX27 || ARCH_MX35 || ARCH_MX25 || ARCH_MX5
> > + MACH_MX27 || ARCH_MX35 || ARCH_MX25 || ARCH_MX5 || SOC_IMX28
> > select PHYLIB
> > help
> > Say Y here if you want to use the built-in 10/100 Fast ethernet
> > controller on some Motorola ColdFire and Freescale i.MX processors.
> >
> > config FEC2
> > - bool "Second FEC ethernet controller (on some ColdFire CPUs)"
> > + bool "Second FEC ethernet controller"
> > depends on FEC
> > help
> > Say Y here if you want to use the second built-in 10/100 Fast
> > - ethernet controller on some Motorola ColdFire processors.
> > + ethernet controller on some Motorola ColdFire and Freescale
> > + i.MX processors.
>
> This option is used nowhere and should be removed. Certainly it does not
> have the effect of enabling the second ethernet controller.
>
As David has merged it, I would send a follow-up patch to remove it.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH 1/2] Add a common struct clk
From: Sascha Hauer @ 2011-01-11 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101111827.12291.jeremy.kerr@canonical.com>
On Tue, Jan 11, 2011 at 06:27:11PM +0800, Jeremy Kerr wrote:
> Hi Sascha,
>
> > The i.MX clk implementation disables the old parent if clk is enabled
> > and enables the new parent if clk is enabled (modulo bugs). Shouldn't
> > we do this here aswell?
>
> Sounds reasonable, yes.
>
> > I thought about returning -EBUSY if clk_set_parent is called for an
> > enabled clk, but this way we could never reparent the cpu clock which I
> > think is done in the Freescale BSP for power saving.
>
> I think that the possibility for changing the parent really depends on the
> implementation; in some cases we may want to disallow it, in others it might
> be fine.
>
> Related: do we really need globally-accessible clk_{get,set}_parent in the clk
> API? For cases where we need to set the parent, we probably need details about
> the platform clock configuration (eg, which clocks are possible parents). In
> this case, we could just call into the clock driver directly.
I agree that drivers have no business calling clk_{get,set}_parent, this
is purely platform specific.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Locking in the clk API
From: Richard Zhao @ 2011-01-11 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111103929.GN24920@pengutronix.de>
2011/1/11 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Hi,
>
> On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
>> > I object to this as one of the purposes behind the clk API is to allow
>> > power savings to be made, and unless we can perform clk enable/disable
>> > from atomic contexts, the best you can do is enable the clock when the
>> > device is probed and disable it when it's released.
>> >
>> > [...]
>> >
>> > Sometimes the only point that you know you need the clock enabled is when
>> > your driver has already been called in an atomic context.
>>
>> .. provided that the enable (and subsequent things that depend on the clock
>> signal to be valid) can't be deferred; I'm not sure how often this will be
>> possible.
>>
>> So, it sounds like the best approach is to provide an atomic clk_enable. I
>> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the
>> most sense, so how about:
>>
>> int clk_enable(struct clk *clk)
>> {
>> ? ? ? might_sleep();
>>
>> ? ? ? [...]
>> }
>>
>> int clk_enable_atomic(struct clk *clk)
>> {
>> ? ? ? BUG_ON(!(clk->flags & CLK_ATOMIC));
>>
>> ? ? ? [...]
>> }
>>
>> Paul: even though you mention that the atomic clocks are the usual case, I
>> think that this way around illustrates the atomic 'restriction' at the call
>> site more clearly. When the drivers don't care about the atomicity,
>> clk_enable() is fine. When drivers do need an atomic clock,
>> clk_enable_atomic() shows this requirement.
> I agree that we should try to make the clk api easy and consistent. ?So
> if we can go the atomic way we should in my opinion.
>
> On i.mx the roots in the clk hierarchy are plls, so it would be nice to
> know how long it takes to enable these.
>
> Back when I implemented clk support for ns921x I had a clock that made
> me think that a sleeping implementation would be the way to go. ?I don't
> remember the exact details. ?(It was the rtc clk.)
>
> A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> something I suggested earlier here:
>
> ? ? ? ?static int clk_enable_haslocknchange(struct clk *clk)
> ? ? ? ?{
> ? ? ? ? ? ? ? ?int ret = 0;
>
> ? ? ? ? ? ? ? ?assert_spin_locked(&clk_lock);
> ? ? ? ? ? ? ? ?BUG_ON(!test_bit(CLK_FLAG_CHANGESTATE, &clk->flags));
>
> ? ? ? ? ? ? ? ?if (clk->usage++ == 0) {
> ? ? ? ? ? ? ? ? ? ? ? ?if (clk->parent) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ret = clk_enable_haslock(clk->parent);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?if (ret)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?goto err_enable_parent;
> ? ? ? ? ? ? ? ? ? ? ? ?}
>
> ? ? ? ? ? ? ? ? ? ? ? ?spin_unlock(&clk_lock);
>
> ? ? ? ? ? ? ? ? ? ? ? ?if (clk->endisable)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ret = clk->endisable(clk, 1);
>
> ? ? ? ? ? ? ? ? ? ? ? ?spin_lock(&clk_lock);
>
> ? ? ? ? ? ? ? ? ? ? ? ?if (ret) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?clk_disable_parent_haslock(clk);
> ? ? ? ?err_enable_parent:
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?clk->usage = 0;
> ? ? ? ? ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?}
>
> ? ? ? ? ? ? ? ?return ret;
> ? ? ? ?}
>
> ? ? ? ?static int clk_enable_haslock(struct clk *clk)
> ? ? ? ?{
> ? ? ? ? ? ? ? ?int ret;
> ? ? ? ? ? ? ? ?assert_spin_locked(&clk_lock);
> ? ? ? ? ? ? ? ?if (__test_and_set_bit(CLK_FLAG_CHANGESTATE, &clk->flags))
> ? ? ? ? ? ? ? ? ? ? ? ?return -EBUSY;
>
> ? ? ? ? ? ? ? ?ret = clk_enable_haslocknchange(clk);
>
> ? ? ? ? ? ? ? ?clear_bit(CLK_FLAG_CHANGESTATE, &clk->flags);
>
> ? ? ? ? ? ? ? ?return ret;
> ? ? ? ?}
>
> ? ? ? ?int clk_enable(struct clk *clk)
> ? ? ? ?{
> ? ? ? ? ? ? ? ?...
> ? ? ? ? ? ? ? ?spin_lock_irqsave(&clk_lock, flags);
> ? ? ? ? ? ? ? ?ret = clk_enable_haslock(clk);
> ? ? ? ? ? ? ? ?spin_unlock_irqrestore(&clk_lock, flags);
> ? ? ? ? ? ? ? ?return ret;
> ? ? ? ?}
>
>
> I think the idea is nice. ?At least it allows with a single lock to
> implement both, sleeping and atomic clks without the need to mark the
> atomicity in a global flag.
>
> In the meantime Sascha checked on mx51 how long it takes to enable one
> of the three PLLs: 50us. ?Is this fast enough to accept disabled irqs
> that long?
A well running board will not enable/disable PLLs frequently. It don't
make sense. PLLs are normally disabled on request to enter low power
mode, rather not because all their child clocks are disabled. So we
don't have to consider the time here.
Thanks
Richard
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | Uwe Kleine-K?nig ? ? ? ? ? ?|
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* BUG: spinlock recursion (sys_chdir, user_path_at, do_path_lookup ...)
From: Uwe Kleine-König @ 2011-01-11 11:05 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
when testing yesterday's Linus' master branch
(a08948812b30653eb2c536ae613b635a989feb6f + some arch support including
Trond's latest nfsfix[1]) I hit the following reproducibly:
[ 5.580000] BUG: spinlock recursion on CPU#0, init/1
[ 5.580000] lock: c7487e10, .magic: dead4ead, .owner: init/1, .owner_cpu: 0
[ 5.590000] Backtrace:
[ 5.590000] [<c0037c2c>] (dump_backtrace+0x0/0x110) from [<c028240c>] (dump_stack+0x1c/0x20)
[ 5.600000] r7:c7487e10 r6:c0321368 r5:c7487e10 r4:c7848000
[ 5.610000] [<c02823f0>] (dump_stack+0x0/0x20) from [<c01b516c>] (spin_bug+0x90/0xa4)
[ 5.620000] [<c01b50dc>] (spin_bug+0x0/0xa4) from [<c01b52d4>] (do_raw_spin_lock+0x50/0x154)
[ 5.620000] r6:c7487e10 r5:c7487e10 r4:00000000
[ 5.630000] [<c01b5284>] (do_raw_spin_lock+0x0/0x154) from [<c028524c>] (_raw_spin_lock_nested+0x40/0x48)
[ 5.640000] [<c028520c>] (_raw_spin_lock_nested+0x0/0x48) from [<c00f436c>] (nameidata_dentry_drop_rcu+0x90/0x1a4)
[ 5.650000] r5:c7843efc r4:c7487dc0
[ 5.650000] [<c00f42dc>] (nameidata_dentry_drop_rcu+0x0/0x1a4) from [<c00f44c0>] (d_revalidate+0x40/0x68)
[ 5.660000] [<c00f4480>] (d_revalidate+0x0/0x68) from [<c00f6ed4>] (link_path_walk+0xb84/0xbf0)
[ 5.670000] r6:c7843efc r5:c7843efc r4:00000000
[ 5.680000] [<c00f6350>] (link_path_walk+0x0/0xbf0) from [<c00f7164>] (do_path_lookup+0x48/0xd4)
[ 5.680000] [<c00f711c>] (do_path_lookup+0x0/0xd4) from [<c00f7c08>] (user_path_at+0x64/0x9c)
[ 5.690000] [<c00f7ba4>] (user_path_at+0x0/0x9c) from [<c00e9614>] (sys_chdir+0x2c/0x78)
[ 5.700000] r8:c0034108 r7:0000000c r6:be961ee4 r5:c7843f88 r4:00063015
[ 5.710000] [<c00e95e8>] (sys_chdir+0x0/0x78) from [<c0033e80>] (ret_fast_syscall+0x0/0x44)
[ 5.720000] r5:be961ee4 r4:00063015
[ 11.720000] BUG: spinlock lockup on CPU#0, init/1, c7487e10
[ 11.730000] Backtrace:
[ 11.730000] [<c0037c2c>] (dump_backtrace+0x0/0x110) from [<c028240c>] (dump_stack+0x1c/0x20)
[ 11.740000] r7:c7842000 r6:c7487e10 r5:00000000 r4:00000000
[ 11.740000] [<c02823f0>] (dump_stack+0x0/0x20) from [<c01b539c>] (do_raw_spin_lock+0x118/0x154)
[ 11.750000] [<c01b5284>] (do_raw_spin_lock+0x0/0x154) from [<c028524c>] (_raw_spin_lock_nested+0x40/0x48)
[ 11.760000] [<c028520c>] (_raw_spin_lock_nested+0x0/0x48) from [<c00f436c>] (nameidata_dentry_drop_rcu+0x90/0x1a4)
[ 11.770000] r5:c7843efc r4:c7487dc0
[ 11.780000] [<c00f42dc>] (nameidata_dentry_drop_rcu+0x0/0x1a4) from [<c00f44c0>] (d_revalidate+0x40/0x68)
[ 11.790000] [<c00f4480>] (d_revalidate+0x0/0x68) from [<c00f6ed4>] (link_path_walk+0xb84/0xbf0)
[ 11.790000] r6:c7843efc r5:c7843efc r4:00000000
[ 11.800000] [<c00f6350>] (link_path_walk+0x0/0xbf0) from [<c00f7164>] (do_path_lookup+0x48/0xd4)
[ 11.810000] [<c00f711c>] (do_path_lookup+0x0/0xd4) from [<c00f7c08>] (user_path_at+0x64/0x9c)
[ 11.820000] [<c00f7ba4>] (user_path_at+0x0/0x9c) from [<c00e9614>] (sys_chdir+0x2c/0x78)
[ 11.820000] r8:c0034108 r7:0000000c r6:be961ee4 r5:c7843f88 r4:00063015
[ 11.830000] [<c00e95e8>] (sys_chdir+0x0/0x78) from [<c0033e80>] (ret_fast_syscall+0x0/0x44)
[ 11.840000] r5:be961ee4 r4:00063015
[ 75.280000] BUG: soft lockup - CPU#0 stuck for 64s! [init:1]
[ 75.280000] Modules linked in:
[ 75.280000] irq event stamp: 113662
[ 75.280000] hardirqs last enabled at (113662): [<c0285a7c>] _raw_spin_unlock_irqrestore+0x48/0x50
[ 75.280000] hardirqs last disabled at (113661): [<c0285398>] _raw_spin_lock_irqsave+0x30/0x64
[ 75.280000] softirqs last enabled at (113509): [<c026447c>] rpc_wake_up_next+0x1b0/0x1c4
[ 75.280000] softirqs last disabled at (113507): [<c02854f0>] _raw_spin_lock_bh+0x20/0x58
[ 75.280000]
[ 75.280000] Pid: 1, comm: init
[ 75.280000] CPU: 0 Not tainted (2.6.37-04021-gb8b018c-dirty #41)
[ 75.280000] PC is at do_raw_spin_lock+0xac/0x154
[ 75.280000] LR is at do_raw_spin_lock+0xc0/0x154
[ 75.280000] pc : [<c01b5330>] lr : [<c01b5344>] psr: 20000013
[ 75.280000] sp : c7843dd0 ip : c7843cd4 fp : c7843e04
[ 75.280000] r10: 06bd0000 r9 : 00000000 r8 : 00000000
[ 75.280000] r7 : c7842000 r6 : c7487e10 r5 : 00000000 r4 : 03dd5aca
[ 75.280000] r3 : 00000000 r2 : 00000001 r1 : c0285a74 r0 : 00000001
[ 75.280000] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 75.280000] Control: 0005317f Table: 479a8000 DAC: 00000015
[ 75.280000] [<c00356c4>] (show_regs+0x0/0x54) from [<c0089dac>] (watchdog_timer_fn+0x13c/0x1a4)
[ 75.280000] r4:c7842000
[ 75.280000] [<c0089c70>] (watchdog_timer_fn+0x0/0x1a4) from [<c006cb58>] (__run_hrtimer+0x114/0x1f0)
[ 75.280000] [<c006ca44>] (__run_hrtimer+0x0/0x1f0) from [<c006ced8>] (hrtimer_interrupt+0x154/0x338)
[ 75.280000] [<c006cd84>] (hrtimer_interrupt+0x0/0x338) from [<c003e36c>] (mxs_timer_interrupt+0x28/0x34)
[ 75.280000] [<c003e344>] (mxs_timer_interrupt+0x0/0x34) from [<c008a408>] (handle_IRQ_event+0x7c/0x1a8)
[ 75.280000] [<c008a38c>] (handle_IRQ_event+0x0/0x1a8) from [<c008c948>] (handle_level_irq+0xc8/0x148)
[ 75.280000] [<c008c880>] (handle_level_irq+0x0/0x148) from [<c002d320>] (asm_do_IRQ+0x80/0xa4)
[ 75.280000] r7:c7842000 r6:c7487e10 r5:00000000 r4:00000030
[ 75.280000] [<c002d2a0>] (asm_do_IRQ+0x0/0xa4) from [<c0033ab8>] (__irq_svc+0x38/0x80)
[ 75.280000] Exception stack(0xc7843d88 to 0xc7843dd0)
[ 75.280000] 3d80: 00000001 c0285a74 00000001 00000000 03dd5aca 00000000
[ 75.280000] 3da0: c7487e10 c7842000 00000000 00000000 06bd0000 c7843e04 c7843cd4 c7843dd0
[ 75.280000] 3dc0: c01b5344 c01b5330 20000013 ffffffff
[ 75.280000] r5:f5000000 r4:ffffffff
[ 75.280000] [<c01b5284>] (do_raw_spin_lock+0x0/0x154) from [<c028524c>] (_raw_spin_lock_nested+0x40/0x48)
[ 75.280000] [<c028520c>] (_raw_spin_lock_nested+0x0/0x48) from [<c00f436c>] (nameidata_dentry_drop_rcu+0x90/0x1a4)
[ 75.280000] r5:c7843efc r4:c7487dc0
[ 75.280000] [<c00f42dc>] (nameidata_dentry_drop_rcu+0x0/0x1a4) from [<c00f44c0>] (d_revalidate+0x40/0x68)
[ 75.280000] [<c00f4480>] (d_revalidate+0x0/0x68) from [<c00f6ed4>] (link_path_walk+0xb84/0xbf0)
[ 75.280000] r6:c7843efc r5:c7843efc r4:00000000
[ 75.280000] [<c00f6350>] (link_path_walk+0x0/0xbf0) from [<c00f7164>] (do_path_lookup+0x48/0xd4)
[ 75.280000] [<c00f711c>] (do_path_lookup+0x0/0xd4) from [<c00f7c08>] (user_path_at+0x64/0x9c)
[ 75.280000] [<c00f7ba4>] (user_path_at+0x0/0x9c) from [<c00e9614>] (sys_chdir+0x2c/0x78)
[ 75.280000] r8:c0034108 r7:0000000c r6:be961ee4 r5:c7843f88 r4:00063015
[ 75.280000] [<c00e95e8>] (sys_chdir+0x0/0x78) from [<c0033e80>] (ret_fast_syscall+0x0/0x44)
[ 75.280000] r5:be961ee4 r4:00063015
I started to bisect, but already the first test case showed a different
error (my getty dying every few seconds).
Does this ring a bell for someone?
If you have questions don't hesitate to ask.
Hardware: mxs-based arm9
Best regards
Uwe
[1] http://mid.gmane.org/1294528551.4181.19.camel at heimdal.trondhjem.org
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Locking in the clk API
From: Uwe Kleine-König @ 2011-01-11 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111104709.GB11039@n2100.arm.linux.org.uk>
Hello Russell,
On Tue, Jan 11, 2011 at 10:47:09AM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 11, 2011 at 11:39:29AM +0100, Uwe Kleine-K?nig wrote:
> > A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> > something I suggested earlier here:
> >
> > [...]
> >
> >
> > I think the idea is nice. At least it allows with a single lock to
> > implement both, sleeping and atomic clks without the need to mark the
> > atomicity in a global flag.
>
> It doesn't. clk_enable() here can still end up trying to sleep when
> it's called from IRQ context - the code doesn't solve that. All it
> means is that the intermediate code doesn't care whether clk->endisable
> ends up sleeping or not.
Obviousley you're right and your last sentence is all I intended to
claim.
> What it does do is return -EBUSY if there are two concurrent attempts
> to enable the same clock. How many drivers today deal sanely with
> such an error from clk_enable(), and how many would just fail their
> probe() call on such an occurance?
Yes, that's the ugly part.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Locking in the clk API
From: Russell King - ARM Linux @ 2011-01-11 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111103929.GN24920@pengutronix.de>
On Tue, Jan 11, 2011 at 11:39:29AM +0100, Uwe Kleine-K?nig wrote:
> A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> something I suggested earlier here:
>
> static int clk_enable_haslocknchange(struct clk *clk)
> {
> int ret = 0;
>
> assert_spin_locked(&clk_lock);
> BUG_ON(!test_bit(CLK_FLAG_CHANGESTATE, &clk->flags));
>
> if (clk->usage++ == 0) {
> if (clk->parent) {
> ret = clk_enable_haslock(clk->parent);
> if (ret)
> goto err_enable_parent;
> }
>
> spin_unlock(&clk_lock);
>
> if (clk->endisable)
> ret = clk->endisable(clk, 1);
>
> spin_lock(&clk_lock);
>
> if (ret) {
> clk_disable_parent_haslock(clk);
> err_enable_parent:
> clk->usage = 0;
> }
> }
>
> return ret;
> }
>
> static int clk_enable_haslock(struct clk *clk)
> {
> int ret;
> assert_spin_locked(&clk_lock);
> if (__test_and_set_bit(CLK_FLAG_CHANGESTATE, &clk->flags))
> return -EBUSY;
>
> ret = clk_enable_haslocknchange(clk);
>
> clear_bit(CLK_FLAG_CHANGESTATE, &clk->flags);
>
> return ret;
> }
>
> int clk_enable(struct clk *clk)
> {
> ...
> spin_lock_irqsave(&clk_lock, flags);
> ret = clk_enable_haslock(clk);
> spin_unlock_irqrestore(&clk_lock, flags);
> return ret;
> }
>
>
> I think the idea is nice. At least it allows with a single lock to
> implement both, sleeping and atomic clks without the need to mark the
> atomicity in a global flag.
It doesn't. clk_enable() here can still end up trying to sleep when
it's called from IRQ context - the code doesn't solve that. All it
means is that the intermediate code doesn't care whether clk->endisable
ends up sleeping or not.
What it does do is return -EBUSY if there are two concurrent attempts
to enable the same clock. How many drivers today deal sanely with
such an error from clk_enable(), and how many would just fail their
probe() call on such an occurance?
^ permalink raw reply
* [PATCH 2/3] ARM i.MX53 enable spi on EVK board
From: Sascha Hauer @ 2011-01-11 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111091549.GL24920@pengutronix.de>
On Tue, Jan 11, 2011 at 10:15:49AM +0100, Uwe Kleine-K?nig wrote:
> Hello,
>
> I'd prefer to have the following subject:
>
> ARM: mx5/mx53_evk: add spi device
>
> On Mon, Jan 10, 2011 at 08:08:53PM +0800, yong.shen at freescale.com wrote:
> > From: Yong Shen <yong.shen@freescale.com>
> >
> > 1. some macro definitions fix
> > 2. add platform data for spi device
> > 3. register spi clocks
> >
> > Signed-off-by: Yong Shen <yong.shen@freescale.com>
> > ---
> > arch/arm/mach-mx5/Kconfig | 1 +
> > arch/arm/mach-mx5/board-mx53_evk.c | 14 ++++++++++++++
> > arch/arm/mach-mx5/clock-mx51-mx53.c | 3 +++
> > arch/arm/mach-mx5/devices-imx53.h | 4 ++++
> > arch/arm/plat-mxc/devices/platform-spi_imx.c | 12 ++++++++++++
> > arch/arm/plat-mxc/include/mach/mx53.h | 10 +++++-----
> > 6 files changed, 39 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> > index 23b0e3f..777740b 100644
> > --- a/arch/arm/mach-mx5/Kconfig
> > +++ b/arch/arm/mach-mx5/Kconfig
> > @@ -126,6 +126,7 @@ config MACH_MX53_EVK
> > select IMX_HAVE_PLATFORM_IMX_UART
> > select IMX_HAVE_PLATFORM_IMX_I2C
> > select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
> > + select IMX_HAVE_PLATFORM_SPI_IMX
> > help
> > Include support for MX53 EVK platform. This includes specific
> > configurations for the board and its peripherals.
> > diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
> > index 4043451..8017d68 100644
> > --- a/arch/arm/mach-mx5/board-mx53_evk.c
> > +++ b/arch/arm/mach-mx5/board-mx53_evk.c
> > @@ -33,6 +33,8 @@
> > #include <mach/iomux-mx53.h>
> >
> > #define SMD_FEC_PHY_RST IMX_GPIO_NR(7, 6)
> > +#define EVK_ECSPI1_CS0 IMX_GPIO_NR(3, 19)
> > +#define EVK_ECSPI1_CS1 IMX_GPIO_NR(2, 30)
> >
> > #include "crm_regs.h"
> > #include "devices-imx53.h"
> > @@ -89,6 +91,16 @@ static struct fec_platform_data mx53_evk_fec_pdata = {
> > .phy = PHY_INTERFACE_MODE_RMII,
> > };
> >
> > +static int mx53_evk_spi_cs[] = {
> > + EVK_ECSPI1_CS0,
> > + EVK_ECSPI1_CS1,
> don't you need to setup some pinmuxing to make this work?
>
> > +};
> > +
> > +static const struct spi_imx_master mx53_evk_spi_data __initconst = {
> > + .chipselect = mx53_evk_spi_cs,
> > + .num_chipselect = ARRAY_SIZE(mx53_evk_spi_cs),
> > +};
> > +
> > static void __init mx53_evk_board_init(void)
> > {
> > mxc_iomux_v3_setup_multiple_pads(mx53_evk_pads,
> > @@ -102,6 +114,8 @@ static void __init mx53_evk_board_init(void)
> >
> > imx53_add_sdhci_esdhc_imx(0, NULL);
> > imx53_add_sdhci_esdhc_imx(1, NULL);
> > +
> > + imx53_add_ecspi(0, &mx53_evk_spi_data);
> > }
> >
> > static void __init mx53_evk_timer_init(void)
> > diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
> > index d0f58a3..a20d0c0 100644
> > --- a/arch/arm/mach-mx5/clock-mx51-mx53.c
> > +++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
> > @@ -1330,6 +1330,9 @@ static struct clk_lookup mx53_lookups[] = {
> > _REGISTER_CLOCK("imx-i2c.1", NULL, i2c2_clk)
> > _REGISTER_CLOCK("sdhci-esdhc-imx.0", NULL, esdhc1_clk)
> > _REGISTER_CLOCK("sdhci-esdhc-imx.1", NULL, esdhc2_clk)
> > + _REGISTER_CLOCK("imx53-ecspi.0", NULL, ecspi1_clk)
> > + _REGISTER_CLOCK("imx53-ecspi.1", NULL, ecspi2_clk)
> > + _REGISTER_CLOCK("imx53-cspi.0", NULL, cspi_clk)
> maybe this should better go into a seperate patch? (i.e.
>
> ARM: mx53: add support to dynamically register imx-spi devices
Yes. We should not add mix architecture support and board support in a
single patch.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
From: Russell King - ARM Linux @ 2011-01-11 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111015409.18291.87166.stgit@localhost6.localdomain6>
On Mon, Jan 10, 2011 at 07:15:53PM -0700, Grant Likely wrote:
> 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
Don't forget to update the comments as well - there's two of them.
^ 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