* [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 1/2 v1] davinci: support disabling modem status interrupts on SOC UARTS
From: Manjunathappa, Prakash @ 2011-01-11 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294230392-29564-1-git-send-email-michael.williamson@criticallink.com>
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).
Thanks,
Prakash
^ permalink raw reply
* [PATCH 0/2] ARM i.MX53 enable SMD and LOCO board bootup
From: Baruch Siach @ 2011-01-11 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikhf7ReDZRt+CRuzupD_oQb7LMfTDa2fvpjayRB@mail.gmail.com>
Hi Yong,
On Tue, Jan 11, 2011 at 03:54:43PM +0800, Yong Shen wrote:
> 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.
Code for two (or more) different machines can be shared in the same file. See
for example the code in arch/arm/mach-at91/board-stamp9g20.c which supports
both taskit PortuxG20 and taskit Stamp9G20, and
arch/arm/mach-at91/board-pcontrol-g20.c which is reusing code from these
boards for a third board (PControl G20).
We should avoid code duplication as much as possible, IMO.
baruch
> On Tue, Jan 11, 2011 at 3:23 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> > 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?
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Change SUEN3 MACH to KMKIRKWOOD
From: Valentin Longchamp @ 2011-01-11 8:32 UTC (permalink / raw)
To: linux-arm-kernel
Hello Russel,
Denx developper Stefan Roese had registered the MACH_SUEN3 with number
2255 when they had ported u-boot for our SUEN3 board.
Our company now has developped several boards with the same architecture
(and thus share quite a lot of code) and the MACH_SUEN3 really is board
specific and while it should define something generic. We have
disscussed with Stefan and have agreed that the best would be to keep
this MACH number but to change its name to something that is common to
all the boards and thus more logical for us.
Could you please change the MACH_SUEN3 (and all the corresponding suen3
occurences) to MACH_KM_KIRKWOOD (respectively km_kirkwood) in the
arch/arm/tools/mach-types file and the corresponding database ?
Thanks and best regards
--
Valentin Longchamp
Embedded Software Engineer
Hardware and Chip Integration
______________________________________
KEYMILE AG
Schwarzenburgstr. 73
CH-3097 Liebefeld
Phone +41 31 377 1318
Fax +41 31 377 1212
valentin.longchamp at keymile.com
www.keymile.com
______________________________________
>>Be the FIRST on the LAST MILE<<
^ permalink raw reply
* Change SUEN3 MACH to KM_KIRKWOOD
From: Valentin Longchamp @ 2011-01-11 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2C1595.50705@keymile.com>
Sorry I made a typo in the subject of the previous mail.
To avoid any confusion, the desired name definitely is KM_KIRKWOOD (and
not KMKIRKWOOD as written in the subject of the previous mail).
Valentin Longchamp wrote:
> Hello Russel,
>
> Denx developper Stefan Roese had registered the MACH_SUEN3 with number
> 2255 when they had ported u-boot for our SUEN3 board.
>
> Our company now has developped several boards with the same architecture
> (and thus share quite a lot of code) and the MACH_SUEN3 really is board
> specific and while it should define something generic. We have
> disscussed with Stefan and have agreed that the best would be to keep
> this MACH number but to change its name to something that is common to
> all the boards and thus more logical for us.
>
> Could you please change the MACH_SUEN3 (and all the corresponding suen3
> occurences) to MACH_KM_KIRKWOOD (respectively km_kirkwood) in the
> arch/arm/tools/mach-types file and the corresponding database ?
>
> Thanks and best regards
>
^ permalink raw reply
* [PATCH 0/2] ARM i.MX53 enable SMD and LOCO board bootup
From: Yong Shen @ 2011-01-11 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111082520.GB22418@jasper.tkos.co.il>
Hi Baruch,
>
> Code for two (or more) different machines can be shared in the same file. See
> for example the code in arch/arm/mach-at91/board-stamp9g20.c which supports
> both taskit PortuxG20 and taskit Stamp9G20, and
> arch/arm/mach-at91/board-pcontrol-g20.c which is reusing code from these
> boards for a third board (PControl G20).
>
> We should avoid code duplication as much as possible, IMO.
>
I agree the rule you mentioned about: avoid code duplication, and I
also know that one file can hold multiple board definitions. However,
in this case, these two boards were designed for different purpose.
For example, SMD is for smart mobile device, while LOCO is more
generic for multiple usage. As time goes on, the code for each boards
are supposed to be much more different than it is now.
So I still stick on my opinion, hope you can understand.
thanks
Yong
^ permalink raw reply
* Locking in the clk API
From: Sascha Hauer @ 2011-01-11 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101111211.30172.jeremy.kerr@canonical.com>
On Tue, Jan 11, 2011 at 12:11:29PM +0800, Jeremy Kerr wrote:
> 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.
For i.MX we can generally turn this into a spinlock. There are some exceptions
though. Most clocks directly visible for drivers are simple clock gates
which can be made atomic. The root clocks are often enough plls which
can't be enabled atomically, but where we have to spin until the pll is
locked. So we we have exactly the case Russell described: Whether we can
enable a clocks atomically depends on the parent (pll) being enabled or
disabled. We can work around this by calling clk_enable to the pll
explicitely from the platform code.
>
> 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.
Quoting Russell:
> I hate the GPIO APIs for doing this _cansleep crap as the decision of
> whether to use the _cansleep or normal APIs normally can't be made at
> the time when the API is used, but sometime later. Many people just use
> the non-_cansleep versions irrespective of the context they're in -
> which is unnecessarily restrictive - consider what happens if you then
> have that driver use a GPIO on an I2C peripheral...
Sounds like we should rather have s sleeping clk_enable and a
clk_enable_atomic. This way people can use standard clk_enable until
a 'scheduling while atomic' gives a hint in the right direction.
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] arm: mm: Poison freed init memory
From: Russell King - ARM Linux @ 2011-01-11 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2BE3E1.5060706@codeaurora.org>
On Mon, Jan 10, 2011 at 09:00:17PM -0800, Stephen Boyd wrote:
> Ok it seems that 0xcc was chosen by Pavel since it's a breakpoint
> instruction (sorry for not noticing that earlier [1]).
It may be on x86, but on ARM:
0: cccccccc stclgt 12, cr12, [ip], {204}
That's a co-processor #12 instruction which will only be executed of
the processor condition codes satisfy 'gt'.
> There was some discussion about handling initdata with Pavel's patch
> but it seems that nothing came of it?
I'm not sure who this Pavel is who you keep referring to - the message
you link to is a discussion between William Irvin and hpa.
> 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).
Yup.
^ permalink raw reply
* [PATCH 1/3] ARM i.MX SPI driver changes for i.MX53 support
From: Sascha Hauer @ 2011-01-11 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294661334-7826-1-git-send-email-yong.shen@freescale.com>
On Mon, Jan 10, 2011 at 08:08:52PM +0800, yong.shen at freescale.com wrote:
> From: Yong Shen <yong.shen@freescale.com>
>
> 1. Change the Kconfig to include i.MX53
> 2. add devtype entry for i.MX53
>
> Signed-off-by: Yong Shen <yong.shen@freescale.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
You should send this to the spi-devel list.
Sascha
> ---
> drivers/spi/Kconfig | 4 ++--
> drivers/spi/spi_imx.c | 6 ++++++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 78f9fd0..04965e2 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -153,10 +153,10 @@ config SPI_IMX_VER_0_4
> def_bool y if ARCH_MX31
>
> config SPI_IMX_VER_0_7
> - def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51
> + def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
>
> config SPI_IMX_VER_2_3
> - def_bool y if ARCH_MX51
> + def_bool y if ARCH_MX51 || ARCH_MX53
>
> config SPI_IMX
> tristate "Freescale i.MX SPI controllers"
> diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c
> index 55a38e2..9b8a733 100644
> --- a/drivers/spi/spi_imx.c
> +++ b/drivers/spi/spi_imx.c
> @@ -747,6 +747,12 @@ static struct platform_device_id spi_imx_devtype[] = {
> .name = "imx51-ecspi",
> .driver_data = SPI_IMX_VER_2_3,
> }, {
> + .name = "imx53-cspi",
> + .driver_data = SPI_IMX_VER_0_7,
> + }, {
> + .name = "imx53-ecspi",
> + .driver_data = SPI_IMX_VER_2_3,
> + }, {
> /* sentinel */
> }
> };
> --
> 1.7.1
>
>
>
--
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 1/3] ARM i.MX SPI driver changes for i.MX53 support
From: Yong Shen @ 2011-01-11 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111090643.GN12078@pengutronix.de>
Thanks, got it.
Yong
On Tue, Jan 11, 2011 at 5:06 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, Jan 10, 2011 at 08:08:52PM +0800, yong.shen at freescale.com wrote:
>> From: Yong Shen <yong.shen@freescale.com>
>>
>> 1. Change the Kconfig to include i.MX53
>> 2. add devtype entry for i.MX53
>>
>> Signed-off-by: Yong Shen <yong.shen@freescale.com>
>
> Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> You should send this to the spi-devel list.
>
> Sascha
>
>> ---
>> ?drivers/spi/Kconfig ? | ? ?4 ++--
>> ?drivers/spi/spi_imx.c | ? ?6 ++++++
>> ?2 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index 78f9fd0..04965e2 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -153,10 +153,10 @@ config SPI_IMX_VER_0_4
>> ? ? ? def_bool y if ARCH_MX31
>>
>> ?config SPI_IMX_VER_0_7
>> - ? ? def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51
>> + ? ? def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
>>
>> ?config SPI_IMX_VER_2_3
>> - ? ? def_bool y if ARCH_MX51
>> + ? ? def_bool y if ARCH_MX51 || ARCH_MX53
>>
>> ?config SPI_IMX
>> ? ? ? tristate "Freescale i.MX SPI controllers"
>> diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c
>> index 55a38e2..9b8a733 100644
>> --- a/drivers/spi/spi_imx.c
>> +++ b/drivers/spi/spi_imx.c
>> @@ -747,6 +747,12 @@ static struct platform_device_id spi_imx_devtype[] = {
>> ? ? ? ? ? ? ? .name = "imx51-ecspi",
>> ? ? ? ? ? ? ? .driver_data = SPI_IMX_VER_2_3,
>> ? ? ? }, {
>> + ? ? ? ? ? ? .name = "imx53-cspi",
>> + ? ? ? ? ? ? .driver_data = SPI_IMX_VER_0_7,
>> + ? ? }, {
>> + ? ? ? ? ? ? .name = "imx53-ecspi",
>> + ? ? ? ? ? ? .driver_data = SPI_IMX_VER_2_3,
>> + ? ? }, {
>> ? ? ? ? ? ? ? /* sentinel */
>> ? ? ? }
>> ?};
>> --
>> 1.7.1
>>
>>
>>
>
> --
> 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 2/3] ARM i.MX53 enable spi on EVK board
From: Uwe Kleine-König @ 2011-01-11 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294661334-7826-2-git-send-email-yong.shen@freescale.com>
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
together with the hunks below.
Best regards
Uwe
> };
>
> static void clk_tree_init(void)
> diff --git a/arch/arm/mach-mx5/devices-imx53.h b/arch/arm/mach-mx5/devices-imx53.h
> index f7c89ef..8639735 100644
> --- a/arch/arm/mach-mx5/devices-imx53.h
> +++ b/arch/arm/mach-mx5/devices-imx53.h
> @@ -25,3 +25,7 @@ extern const struct imx_sdhci_esdhc_imx_data
> imx53_sdhci_esdhc_imx_data[] __initconst;
> #define imx53_add_sdhci_esdhc_imx(id, pdata) \
> imx_add_sdhci_esdhc_imx(&imx53_sdhci_esdhc_imx_data[id], pdata)
> +
> +extern const struct imx_spi_imx_data imx53_ecspi_data[] __initconst;
> +#define imx53_add_ecspi(id, pdata) \
> + imx_add_spi_imx(&imx53_ecspi_data[id], pdata)
> diff --git a/arch/arm/plat-mxc/devices/platform-spi_imx.c b/arch/arm/plat-mxc/devices/platform-spi_imx.c
> index 8ea49ad..013c85f 100644
> --- a/arch/arm/plat-mxc/devices/platform-spi_imx.c
> +++ b/arch/arm/plat-mxc/devices/platform-spi_imx.c
> @@ -81,6 +81,18 @@ const struct imx_spi_imx_data imx51_ecspi_data[] __initconst = {
> };
> #endif /* ifdef CONFIG_SOC_IMX51 */
>
> +#ifdef CONFIG_SOC_IMX53
> +const struct imx_spi_imx_data imx53_cspi_data __initconst =
> + imx_spi_imx_data_entry_single(MX53, CSPI, "imx53-cspi", 0, , SZ_4K);
> +
> +const struct imx_spi_imx_data imx53_ecspi_data[] __initconst = {
> +#define imx53_ecspi_data_entry(_id, _hwid) \
> + imx_spi_imx_data_entry(MX53, ECSPI, "imx53-ecspi", _id, _hwid, SZ_4K)
> + imx53_ecspi_data_entry(0, 1),
> + imx53_ecspi_data_entry(1, 2),
> +};
> +#endif /* ifdef CONFIG_SOC_IMX53 */
> +
> struct platform_device *__init imx_add_spi_imx(
> const struct imx_spi_imx_data *data,
> const struct spi_imx_master *pdata)
> diff --git a/arch/arm/plat-mxc/include/mach/mx53.h b/arch/arm/plat-mxc/include/mach/mx53.h
> index 340937f..d7a8e52 100644
> --- a/arch/arm/plat-mxc/include/mach/mx53.h
> +++ b/arch/arm/plat-mxc/include/mach/mx53.h
> @@ -56,7 +56,7 @@
> #define MX53_ESDHC1_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00004000)
> #define MX53_ESDHC2_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00008000)
> #define MX53_UART3_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x0000C000)
> -#define MX53_CSPI1_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00010000)
> +#define MX53_ECSPI1_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00010000)
> #define MX53_SSI2_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00014000)
> #define MX53_ESDHC3_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00020000)
> #define MX53_ESDHC4_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00024000)
> @@ -117,12 +117,12 @@
> #define MX53_ARM_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000A0000)
> #define MX53_OWIRE_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000A4000)
> #define MX53_FIRI_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000A8000)
> -#define MX53_CSPI2_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000AC000)
> +#define MX53_ECSPI2_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000AC000)
> #define MX53_SDMA_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000B0000)
> #define MX53_SCC_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000B4000)
> #define MX53_ROMCP_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000B8000)
> #define MX53_RTIC_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000BC000)
> -#define MX53_CSPI3_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000C0000)
> +#define MX53_CSPI_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000C0000)
> #define MX53_I2C2_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000C4000)
> #define MX53_I2C1_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000C8000)
> #define MX53_SSI1_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000CC000)
> @@ -264,8 +264,8 @@
> #define MX53_INT_UART3 33
> #define MX53_INT_RESV34 34
> #define MX53_INT_RESV35 35
> -#define MX53_INT_CSPI1 36
> -#define MX53_INT_CSPI2 37
> +#define MX53_INT_ECSPI1 36
> +#define MX53_INT_ECSPI2 37
> #define MX53_INT_CSPI 38
> #define MX53_INT_GPT 39
> #define MX53_INT_EPIT1 40
> --
> 1.7.1
>
>
>
--
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 9:16 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:
> 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.
^ permalink raw reply
* [PATCH 1/3] ARM i.MX SPI driver changes for i.MX53 support
From: Uwe Kleine-König @ 2011-01-11 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294661334-7826-1-git-send-email-yong.shen@freescale.com>
On Mon, Jan 10, 2011 at 08:08:52PM +0800, yong.shen at freescale.com wrote:
> From: Yong Shen <yong.shen@freescale.com>
>
> 1. Change the Kconfig to include i.MX53
> 2. add devtype entry for i.MX53
>
> Signed-off-by: Yong Shen <yong.shen@freescale.com>
Looks good. I'm glad it's that easy to add support for i.MX53. It's
quite obvious there are no ifs that were forgotton to adapt.
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Best regards
Uwe
> ---
> drivers/spi/Kconfig | 4 ++--
> drivers/spi/spi_imx.c | 6 ++++++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 78f9fd0..04965e2 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -153,10 +153,10 @@ config SPI_IMX_VER_0_4
> def_bool y if ARCH_MX31
>
> config SPI_IMX_VER_0_7
> - def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51
> + def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
>
> config SPI_IMX_VER_2_3
> - def_bool y if ARCH_MX51
> + def_bool y if ARCH_MX51 || ARCH_MX53
>
> config SPI_IMX
> tristate "Freescale i.MX SPI controllers"
> diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c
> index 55a38e2..9b8a733 100644
> --- a/drivers/spi/spi_imx.c
> +++ b/drivers/spi/spi_imx.c
> @@ -747,6 +747,12 @@ static struct platform_device_id spi_imx_devtype[] = {
> .name = "imx51-ecspi",
> .driver_data = SPI_IMX_VER_2_3,
> }, {
> + .name = "imx53-cspi",
> + .driver_data = SPI_IMX_VER_0_7,
> + }, {
> + .name = "imx53-ecspi",
> + .driver_data = SPI_IMX_VER_2_3,
> + }, {
> /* sentinel */
> }
> };
> --
> 1.7.1
>
>
>
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* ARM i.MX SPI driver changes for i.MX53 support
From: yong.shen at freescale.com @ 2011-01-11 9:21 UTC (permalink / raw)
To: linux-arm-kernel
resend this to include spi-devel list.
^ permalink raw reply
* [PATCH] ARM i.MX SPI driver changes for i.MX53 support
From: yong.shen at freescale.com @ 2011-01-11 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294737713-24015-1-git-send-email-yong.shen@freescale.com>
From: Yong Shen <yong.shen@freescale.com>
1. Change the Kconfig to include i.MX53
2. add devtype entry for i.MX53
Signed-off-by: Yong Shen <yong.shen@freescale.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/spi/Kconfig | 4 ++--
drivers/spi/spi_imx.c | 6 ++++++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 78f9fd0..04965e2 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -153,10 +153,10 @@ config SPI_IMX_VER_0_4
def_bool y if ARCH_MX31
config SPI_IMX_VER_0_7
- def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51
+ def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
config SPI_IMX_VER_2_3
- def_bool y if ARCH_MX51
+ def_bool y if ARCH_MX51 || ARCH_MX53
config SPI_IMX
tristate "Freescale i.MX SPI controllers"
diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c
index 55a38e2..9b8a733 100644
--- a/drivers/spi/spi_imx.c
+++ b/drivers/spi/spi_imx.c
@@ -747,6 +747,12 @@ static struct platform_device_id spi_imx_devtype[] = {
.name = "imx51-ecspi",
.driver_data = SPI_IMX_VER_2_3,
}, {
+ .name = "imx53-cspi",
+ .driver_data = SPI_IMX_VER_0_7,
+ }, {
+ .name = "imx53-ecspi",
+ .driver_data = SPI_IMX_VER_2_3,
+ }, {
/* sentinel */
}
};
--
1.7.1
^ permalink raw reply related
* Locking in the clk API
From: Russell King - ARM Linux @ 2011-01-11 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111090311.GM12078@pengutronix.de>
On Tue, Jan 11, 2011 at 10:03:11AM +0100, Sascha Hauer wrote:
> Quoting Russell:
>
> > I hate the GPIO APIs for doing this _cansleep crap as the decision of
> > whether to use the _cansleep or normal APIs normally can't be made at
> > the time when the API is used, but sometime later. Many people just use
> > the non-_cansleep versions irrespective of the context they're in -
> > which is unnecessarily restrictive - consider what happens if you then
> > have that driver use a GPIO on an I2C peripheral...
>
> Sounds like we should rather have s sleeping clk_enable and a
> clk_enable_atomic. This way people can use standard clk_enable until
> a 'scheduling while atomic' gives a hint in the right direction.
Well, there's a problem lurking here - lets take the PL011 driver. You
convert the console write calls to use clk_enable_atomic(), leaving the
rest.
The driver will appear to work fine with a sleeping clk, until you get
a console write. Maybe your SoC developer never tried the console on
the particular port you just tried to use? Maybe such a driver should
use the _atomic() versions throughout?
Another solution occurs to me: clk_enable() which returns -EAGAIN if
it's called in an atomic context but needs to sleep, and let the driver
deal with the clock not being enabled when it wants it. The down side
is it requires the driver to have additional code to sort out such a
problem.
Maybe another approach for the time being is to unify in two steps: first
unify the implementations which use a spinlock - and those which can use
a spinlock, and separately those which must use a mutex.
Then this issue can be revisited in the future.
^ permalink raw reply
* Locking in the clk API
From: Jeremy Kerr @ 2011-01-11 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111091607.GI12552@n2100.arm.linux.org.uk>
Hi Russell,
> 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.
Cheers,
Jeremy
^ permalink raw reply
* Locking in the clk API
From: Paul Mundt @ 2011-01-11 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101111744.59712.jeremy.kerr@canonical.com>
On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
> 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.
>
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).
Keep in mind that all users except for the few that you cited were
already quite content with the atomic context use, so this 'restriction'
you speak of is just an artificial limitation introduced by a couple of
new platforms that deviated from what everyone else was already doing.
If you want to go this route, then SH and ARM-based SH-Mobiles will at
least not be making use of the generic struct clk.
^ permalink raw reply
* [PATCH 1/2] Add a common struct clk
From: Sascha Hauer @ 2011-01-11 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294199462.348449.192344022926.1.gpush@pororo>
On Wed, Jan 05, 2011 at 11:51:02AM +0800, Jeremy Kerr wrote:
> diff --git a/kernel/clk.c b/kernel/clk.c
> new file mode 100644
> index 0000000..8de8fe3
> --- /dev/null
> +++ b/kernel/clk.c
> @@ -0,0 +1,102 @@
> +/*
> + * Copyright (C) 2010 Canonical Ltd <jeremy.kerr@canonical.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Standard functionality for the common clock API.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/module.h>
> +
...
> +
> +int clk_set_parent(struct clk *clk, struct clk *parent)
> +{
> + if (clk->ops->set_parent)
> + return clk->ops->set_parent(clk, parent);
> + return -ENOSYS;
> +}
> +EXPORT_SYMBOL_GPL(clk_set_parent);
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? Otherwise at least the enable_count of both the
old and the new parent will be wrong after calling clk_set_parent for an
enabled clk.
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.
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 1/2] Add a common struct clk
From: Jeremy Kerr @ 2011-01-11 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111101636.GF26617@pengutronix.de>
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.
Cheers,
Jeremy
^ permalink raw reply
* [PATCH v4 05/10] net/fec: add dual fec support for mx28
From: Sascha Hauer @ 2011-01-11 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294297998-26930-6-git-send-email-shawn.guo@freescale.com>
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.
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: Sascha Hauer @ 2011-01-11 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294297998-26930-8-git-send-email-shawn.guo@freescale.com>
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.
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: Jeremy Kerr @ 2011-01-11 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111101314.GA774@linux-sh.org>
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?
Cheers,
Jeremy
^ permalink raw reply
* Locking in the clk API
From: Uwe Kleine-König @ 2011-01-11 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101111744.59712.jeremy.kerr@canonical.com>
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?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ 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