* OMAP baseline test results for v3.7-rc2
From: Paul Walmsley @ 2012-10-22 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210221829270.13464@utopia.booyaka.com>
On Mon, 22 Oct 2012, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Jon Hunter wrote:
>
> > and toolchain used for any failures.
>
> This would indeed be useful and will try to figure out a good way to add
> that information.
Just realized that some of this appears in the beginning of the bootlogs:
[ 0.000000] Linux version 3.7.0-rc2-00331-g6f0c058 (paul at nozomi) (gcc
version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Sat Oct 20 14:04:56
MDT 2012
Not the easiest information to find, but maybe it serves your needs?
- Paul
^ permalink raw reply
* [PATCH v3 0/4] make cadence ethernet drivers build on any architecture
From: Joachim Eastwood @ 2012-10-22 18:45 UTC (permalink / raw)
To: linux-arm-kernel
This series makes the at91_ether and macb driver build-able on any architecture.
Patch 1 fixes a integer truncated warning in macb, which will show up when compiling for 64-bit, before enabling macb driver for other architectures.
Patch 2 removes the HAVE_NET_MACB from the cadence Kconfig and this allow macb to be built on any architecture. The macb driver requires no other modifications.
Patch 4 moves a bootloader quirk for CSB337 from at91_ether into platform data as a flag. This allow us to remove the last mach include and build this driver on any architecture. It also make it easier to share the address setup between at91_ether and macb.
The next series will make the at91_ether driver use address setting and statistics from macb. There is also a clean up of print outs plus some comment/style fixes.
Patch log:
v3 - Include integer truncated warning fix for macb
v2 - Use macb platform data to support reversed ethernet address and squash HAVE_NET_MACB removal patches.
Joachim Eastwood (4):
net/macb: fix truncate warnings
net/cadence: get rid of HAVE_NET_MACB
net/at91_ether: select MACB in Kconfig
net/at91_ether: add pdata flag for reverse Eth addr
arch/arm/mach-at91/Kconfig | 4 ----
arch/arm/mach-at91/board-csb337.c | 2 ++
arch/avr32/Kconfig | 1 -
drivers/net/ethernet/cadence/Kconfig | 8 +-------
drivers/net/ethernet/cadence/Makefile | 2 +-
drivers/net/ethernet/cadence/at91_ether.c | 5 ++---
drivers/net/ethernet/cadence/macb.c | 8 ++++----
include/linux/platform_data/macb.h | 1 +
8 files changed, 11 insertions(+), 20 deletions(-)
--
1.7.12.4
^ permalink raw reply
* [PATCH v3 1/4] net/macb: fix truncate warnings
From: Joachim Eastwood @ 2012-10-22 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350931534-8416-1-git-send-email-manabian@gmail.com>
When building macb on x86_64 the following warnings show up:
drivers/net/ethernet/cadence/macb.c: In function macb_interrupt:
drivers/net/ethernet/cadence/macb.c:556:4: warning: large integer implicitly truncated to unsigned type [-Woverflow]
drivers/net/ethernet/cadence/macb.c: In function macb_reset_hw:
drivers/net/ethernet/cadence/macb.c:792:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
drivers/net/ethernet/cadence/macb.c:793:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
drivers/net/ethernet/cadence/macb.c:796:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
Use -1 insted of ~0UL, as done in other places in the driver,
to silence these warnings.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/ethernet/cadence/macb.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 6c84a11..6a4f499 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -553,7 +553,7 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
while (status) {
/* close possible race with dev_close */
if (unlikely(!netif_running(dev))) {
- macb_writel(bp, IDR, ~0UL);
+ macb_writel(bp, IDR, -1);
break;
}
@@ -789,11 +789,11 @@ static void macb_reset_hw(struct macb *bp)
macb_writel(bp, NCR, MACB_BIT(CLRSTAT));
/* Clear all status flags */
- macb_writel(bp, TSR, ~0UL);
- macb_writel(bp, RSR, ~0UL);
+ macb_writel(bp, TSR, -1);
+ macb_writel(bp, RSR, -1);
/* Disable all interrupts */
- macb_writel(bp, IDR, ~0UL);
+ macb_writel(bp, IDR, -1);
macb_readl(bp, ISR);
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH v3 2/4] net/cadence: get rid of HAVE_NET_MACB
From: Joachim Eastwood @ 2012-10-22 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350931534-8416-1-git-send-email-manabian@gmail.com>
macb is a platform driver and there is nothing that prevents
this driver from being built on non-ARM/AVR32 platforms.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/arm/mach-at91/Kconfig | 4 ----
arch/avr32/Kconfig | 1 -
drivers/net/ethernet/cadence/Kconfig | 5 -----
3 files changed, 10 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index d846b6e..72020fb 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -45,7 +45,6 @@ config SOC_AT91RM9200
config SOC_AT91SAM9260
bool "AT91SAM9260, AT91SAM9XE or AT91SAM9G20"
select HAVE_AT91_DBGU0
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9260, AT91SAM9XE
@@ -63,7 +62,6 @@ config SOC_AT91SAM9263
bool "AT91SAM9263"
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
config SOC_AT91SAM9RL
@@ -76,7 +74,6 @@ config SOC_AT91SAM9G45
bool "AT91SAM9G45 or AT91SAM9M10 families"
select HAVE_AT91_DBGU1
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9G45 family SoC.
@@ -86,7 +83,6 @@ config SOC_AT91SAM9X5
bool "AT91SAM9x5 family"
select HAVE_AT91_DBGU0
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
select SOC_AT91SAM9
help
Select this if you are using one of Atmel's AT91SAM9x5 family SoC.
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index 06e73bf..09f9fa8 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -80,7 +80,6 @@ config PLATFORM_AT32AP
select ARCH_REQUIRE_GPIOLIB
select GENERIC_ALLOCATOR
select HAVE_FB_ATMEL
- select HAVE_NET_MACB
#
# CPU types
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index 57f78abe..5d1ea30 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -2,13 +2,9 @@
# Atmel device configuration
#
-config HAVE_NET_MACB
- bool
-
config NET_CADENCE
bool "Cadence devices"
default y
- depends on HAVE_NET_MACB || (ARM && ARCH_AT91RM9200)
---help---
If you have a network (Ethernet) card belonging to this class, say Y.
Make sure you know the name of your card. Read the Ethernet-HOWTO,
@@ -34,7 +30,6 @@ config ARM_AT91_ETHER
config MACB
tristate "Cadence MACB/GEM support"
- depends on HAVE_NET_MACB
select PHYLIB
---help---
The Cadence MACB ethernet interface is found on many Atmel AT32 and
--
1.7.12.4
^ permalink raw reply related
* [PATCH v3 3/4] net/at91_ether: select MACB in Kconfig
From: Joachim Eastwood @ 2012-10-22 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350931534-8416-1-git-send-email-manabian@gmail.com>
Now that HAVE_NET_MACB is gone let's just select MACB to
satisfy the dependecies in at91_ether.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/ethernet/cadence/Kconfig | 2 +-
drivers/net/ethernet/cadence/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index 5d1ea30..f6d0956 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -23,7 +23,7 @@ config ARM_AT91_ETHER
tristate "AT91RM9200 Ethernet support"
depends on ARM && ARCH_AT91RM9200
select NET_CORE
- select PHYLIB
+ select MACB
---help---
If you wish to compile a kernel for the AT91RM9200 and enable
ethernet support, then you should always answer Y to this.
diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
index 798b1e0..9068b83 100644
--- a/drivers/net/ethernet/cadence/Makefile
+++ b/drivers/net/ethernet/cadence/Makefile
@@ -2,5 +2,5 @@
# Makefile for the Atmel network device drivers.
#
-obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o macb.o
+obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
obj-$(CONFIG_MACB) += macb.o
--
1.7.12.4
^ permalink raw reply related
* [PATCH v3 4/4] net/at91_ether: add pdata flag for reverse Eth addr
From: Joachim Eastwood @ 2012-10-22 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350931534-8416-1-git-send-email-manabian@gmail.com>
This will allow us to remove the last mach include from at91_ether
and also make it easier to share address setup with macb.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
arch/arm/mach-at91/board-csb337.c | 2 ++
drivers/net/ethernet/cadence/Kconfig | 1 -
drivers/net/ethernet/cadence/at91_ether.c | 5 ++---
include/linux/platform_data/macb.h | 1 +
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/board-csb337.c b/arch/arm/mach-at91/board-csb337.c
index 3e37437..aa9b320 100644
--- a/arch/arm/mach-at91/board-csb337.c
+++ b/arch/arm/mach-at91/board-csb337.c
@@ -53,6 +53,8 @@ static void __init csb337_init_early(void)
static struct macb_platform_data __initdata csb337_eth_data = {
.phy_irq_pin = AT91_PIN_PC2,
.is_rmii = 0,
+ /* The CSB337 bootloader stores the MAC the wrong-way around */
+ .rev_eth_addr = 1,
};
static struct at91_usbh_data __initdata csb337_usbh_data = {
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index f6d0956..40172d1 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -21,7 +21,6 @@ if NET_CADENCE
config ARM_AT91_ETHER
tristate "AT91RM9200 Ethernet support"
- depends on ARM && ARCH_AT91RM9200
select NET_CORE
select MACB
---help---
diff --git a/drivers/net/ethernet/cadence/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
index 375d272..b92815a 100644
--- a/drivers/net/ethernet/cadence/at91_ether.c
+++ b/drivers/net/ethernet/cadence/at91_ether.c
@@ -32,8 +32,6 @@
#include <linux/phy.h>
#include <linux/io.h>
-#include <asm/mach-types.h>
-
#include "macb.h"
#define DRV_NAME "at91_ether"
@@ -61,9 +59,10 @@
static short __init unpack_mac_address(struct net_device *dev, unsigned int hi, unsigned int lo)
{
+ struct macb *lp = netdev_priv(dev);
char addr[6];
- if (machine_is_csb337()) {
+ if (lp->board_data.rev_eth_addr) {
addr[5] = (lo & 0xff); /* The CSB337 bootloader stores the MAC the wrong-way around */
addr[4] = (lo & 0xff00) >> 8;
addr[3] = (lo & 0xff0000) >> 16;
diff --git a/include/linux/platform_data/macb.h b/include/linux/platform_data/macb.h
index b081c72..044a124 100644
--- a/include/linux/platform_data/macb.h
+++ b/include/linux/platform_data/macb.h
@@ -12,6 +12,7 @@ struct macb_platform_data {
u32 phy_mask;
int phy_irq_pin; /* PHY IRQ */
u8 is_rmii; /* using RMII interface? */
+ u8 rev_eth_addr; /* reverse Ethernet address byte order */
};
#endif /* __MACB_PDATA_H__ */
--
1.7.12.4
^ permalink raw reply related
* [PATCH 5/5] arm: mvebu: Added SMP support for Armada XP
From: Andrew Lunn @ 2012-10-22 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350925368-24243-6-git-send-email-gregory.clement@free-electrons.com>
Hi Gregory
> +void __init set_secondary_cpus_clock(void)
> +{
> + int cpu;
> + unsigned long rate;
> + struct clk *cpu_clk = NULL;
> + struct device_node *np = NULL;
> +
> + cpu = smp_processor_id();
> + np = of_find_node_by_type(np, "cpu");
> + np = NULL;
> + while ((np = of_find_node_by_type(np, "cpu"))) {
> + const u32 *reg;
> + int len;
> + reg = of_get_property(np, "reg", &len);
> + if (!reg || len != 4) {
> + pr_err("%s missing reg property\n", np->full_name);
> + continue;
> + }
> + if (be32_to_cpup(reg) == cpu) {
> + cpu_clk = of_clk_get(np, 0);
> + break;
> + }
> + }
> + WARN_ON(IS_ERR(cpu_clk));
> + rate = clk_get_rate(cpu_clk);
> +
> + /* set all the other CPU clk to the same rate than the boot CPU */
> + np = NULL;
> + while ((np = of_find_node_by_type(np, "cpu"))) {
> + const u32 *reg;
> + int len;
> + reg = of_get_property(np, "reg", &len);
> + if (!reg || len != 4) {
> + pr_err("%s missing reg property\n", np->full_name);
> + continue;
> + }
> + if (be32_to_cpup(reg) != cpu) {
> + cpu_clk = of_clk_get(np, 0);
> + clk_set_rate(cpu_clk, rate);
> + }
Maybe its hiding somewhere, but where is the clk_prepare_enable() for
this cpu_clk clock?
Andrew
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Jon Hunter @ 2012-10-22 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210221829270.13464@utopia.booyaka.com>
On 10/22/2012 01:35 PM, Paul Walmsley wrote:
> (including the lists in my reply this time, oops; also adding some more
> detail)
>
> On Mon, 22 Oct 2012, Jon Hunter wrote:
>
>> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
>>
>>> Failing tests: fixed by posted patches
>>> --------------------------------------
>>>
>>> Boot tests:
>>>
>>> * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
>>> - due to a GPMC bug
>>> - Apparently fixed by http://www.spinics.net/lists/arm-kernel/msg200787.html
>>
>> This is now addressed and I have verified it is booting on v3.7-rc2. The
>> following patch address this boot problem ...
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3
>
> Great, thanks, will update the README. Did you also enable
> CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT, or were you able
> to pass the DTB from the bootloader?
Actually, I built u-boot release 2012.10 for the am335x-evm and that
worked for the bone board too. So that is what I used. I have not
checked with Vaibhav and team if that is what they are using. So with
this u-boot I just passed the dtb to the kernel and did not append.
Cheers
Jon
^ permalink raw reply
* OMAP baseline test results for v3.7-rc2
From: Jon Hunter @ 2012-10-22 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210221835520.13464@utopia.booyaka.com>
On 10/22/2012 01:36 PM, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Paul Walmsley wrote:
>
>> On Mon, 22 Oct 2012, Jon Hunter wrote:
>>
>>> and toolchain used for any failures.
>>
>> This would indeed be useful and will try to figure out a good way to add
>> that information.
>
> Just realized that some of this appears in the beginning of the bootlogs:
>
> [ 0.000000] Linux version 3.7.0-rc2-00331-g6f0c058 (paul at nozomi) (gcc
> version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #1 SMP Sat Oct 20 14:04:56
> MDT 2012
>
> Not the easiest information to find, but maybe it serves your needs?
Yes, it does. The boot log has all the info we need :-)
Cheers
Jon
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-22 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508586ED.1010106@wwwdotorg.org>
On Mon, 22 Oct 2012, Stephen Warren wrote:
> >>> +- has-tt : controller has transaction translator(s).
> >>> +- has-synopsys-hc-bug : controller has the synopsys hc bug
> >>
> >> That would normally be determined by the driver based on the particular
> >> compatible value that is in device tree.
> >
> > I don't understand this comment. Isn't "has-synopsys-hc-bug" the
> > compatible value in question?
>
> "compatible value" in this context means that value of the property
> named "compatible".
I see. But why would it be done this way instead having a separate
property?
And doesn't the same reasoning apply to has-tt? Doesn't that mean the
driver would have to match four different hardware types? What happens
if a third characteristic like these comes around; would the driver
then have to check against eight different types?
> >>> +- big-endian : descriptors and registers are both big endian. This
> >>> + is the equivalent of specifying big-endian-desc and big-endian-regs.
> >>> +OR
> >>> +- big-endian-desc : descriptors are in big-endian format
> >>> +- big-endian-regs : mmio is in big-endian format
> >>
> >> Hmmm. That looks odd. Presumably if those properties aren't specified,
> >> the default is little-endian? Shouldn't this be a tri-state: big,
> >> little, native, with default native? I don't know what the EHCI
> >> specification mandates here (and if it does mandate something, the
> >> default should match the specification). Isn't this something that
> >> readl/writel would take care of, or are there cases where the register
> >> endianness of just this one HW block mismatches all other HW blocks?
> >
> > The EHCI spec assumes a PCI implementation; it doesn't consider other
> > sorts. And it doesn't say anything about the endianness of multi-byte
> > descriptors in memory.
>
> OK, so does this binding default to assuming little-endian (which I
> assume matches PCI), unless the big-endian properties are given?
Yes, that is the intention. The ehci-hcd driver works the same way; it
assumes little-endian unless USB_EHCI_BIG_ENDIAN_DESC or
USB_EHCI_BIG_ENDIAN_MMIO is set. (That will have to change in the
future, though.)
> Is the
> case of little-endian EHCI registers on a big-endian CPU a common enough
> thing that adding a third state native-endian wouldn't be useful?
I'm not sure how to answer. Little-endian EHCI registers are very
common, even among big-endian CPUs (they are probably the majority, in
fact). I don't see how adding native-endian would help; the readl()
function always assumes the values it reads are little-endian, so in
that sense little-endian _is_ the native state.
Also, as far as I know there aren't any examples of big-endian EHCI
registers on systems with little-endian CPUs.
Alan Stern
^ permalink raw reply
* [PATCH 3/5] arm: mvebu: Added IPI support via doorbells
From: Gregory CLEMENT @ 2012-10-22 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022173028.GM21046@lunn.ch>
On 10/22/2012 07:30 PM, Andrew Lunn wrote:
> On Mon, Oct 22, 2012 at 07:02:45PM +0200, Gregory CLEMENT wrote:
>> From: Yehuda Yitschak <yehuday@marvell.com>
>>
>> Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> arch/arm/boot/dts/armada-xp.dtsi | 2 +-
>> arch/arm/mach-mvebu/armada-370-xp.h | 10 ++++
>> arch/arm/mach-mvebu/irq-armada-370-xp.c | 92 +++++++++++++++++++++++++++++--
>> 3 files changed, 97 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
>> index f521ed8..531619f 100644
>> --- a/arch/arm/boot/dts/armada-xp.dtsi
>> +++ b/arch/arm/boot/dts/armada-xp.dtsi
>> @@ -24,7 +24,7 @@
>>
>> mpic: interrupt-controller at d0020000 {
>> reg = <0xd0020a00 0x1d0>,
>> - <0xd0021870 0x58>;
>> + <0xd0021070 0x58>;
>> };
>
> Hi Gregory
>
> Is this a bug fix needed for 3.7?
>
> Andrew
>
I don't think so.
We extended the reg map to be able to use registers only used for SMP.
When we didn't have SMP support the mapping was correct, and now by
introducing SMP we extend it.
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] pinctrl: reserve pins when states are activated
From: Tony Lindgren @ 2012-10-22 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZazjMoSzkr5t15-GeCnQKCJDsZyvT=KVMyw5XhjDybGQ@mail.gmail.com>
* Linus Walleij <linus.walleij@linaro.org> [121022 01:22]:
> On Fri, Oct 19, 2012 at 8:10 PM, Tony Lindgren <tony@atomide.com> wrote:
> > [Me]
> >> Instead: let use reserve the pins when the state is activated
> >> and drop them when the state is disabled, i.e. when we move to
> >> another state. This way different devices/functions can use the
> >> same pins at different times.
> >
> > Hmm doesn't this mean that we are now doing lots of extra
> > reserving and dropping of pins? Performance is important from
> > latency point of view for cases where we need to remux pins
> > constantly runtime PM.
>
> It is only done in case the pinmux state is switched in runtime
> suspend/resume, so it's e.g. possible to just alter the pin config.
>
> But in general what you say is true.
>
> We used to to the same thing by having drivers call
> pinctrl_get()/pinctrl_put() in this case instead, but that went
> away with the introduction of states, so we cannot encode
> different pin sets with say
> pinctrl_get(dev, "foo")/pinctrl_get(dev, "bar")
> anymore since there is only one pinctrl handle per device,
> but multiple states.
OK
> If this turns out to be a severe performance bottleneck, I
> suggest to add some additional constraint API, like
> pinctrl_set_pinmux_homegeneous_pinsets(true) that will
> at runtime select whether the pin allocation is done when
> getting the pinctrl handle instead.
Or maybe you could release + reserve the pins only if the
pins change?
Regards,
Tony
^ permalink raw reply
* [PATCH 1/7] ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod
From: Mark A. Greer @ 2012-10-22 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210201934550.27264@utopia.booyaka.com>
On Sat, Oct 20, 2012 at 07:40:19PM +0000, Paul Walmsley wrote:
> Hi
Hi Paul.
> a few comments:
>
> On Fri, 19 Oct 2012, Mark A. Greer wrote:
>
> > From: "Mark A. Greer" <mgreer@animalcreek.com>
> >
> > Convert the device data for the OMAP2 SHAM crypto IP from
> > explicit platform_data to hwmod. When bit 1 (OMAP24XX_ST_SHA_MASK)
> > of the CM_IDLEST4_CORE register is set, the SHA IP is present.
> >
> > CC: Paul Walmsley <paul@pwsan.com>
> > Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
>
> ...
>
> >
> > diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-omap2/clock2420_data.c
> > index c3cde1a..a09603c 100644
> > --- a/arch/arm/mach-omap2/clock2420_data.c
> > +++ b/arch/arm/mach-omap2/clock2420_data.c
> > @@ -1905,6 +1905,7 @@ static struct omap_clk omap2420_clks[] = {
> > CLK(NULL, "vlynq_ick", &vlynq_ick, CK_242X),
> > CLK(NULL, "vlynq_fck", &vlynq_fck, CK_242X),
> > CLK(NULL, "des_ick", &des_ick, CK_242X),
> > + CLK(NULL, "sha_ick", &sha_ick, CK_242X),
>
> This isn't needed; this alias already exists two lines below.
Umm, yeah. Oops. :)
> > CLK("omap-sham", "ick", &sha_ick, CK_242X),
> > CLK(NULL, "sha_ick", &sha_ick, CK_242X),
> > CLK("omap_rng", "ick", &rng_ick, CK_242X),
> > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > index c8c2117..5b613fa 100644
> > --- a/arch/arm/mach-omap2/devices.c
> > +++ b/arch/arm/mach-omap2/devices.c
> > @@ -500,17 +484,27 @@ static struct platform_device sham_device = {
> >
> > static void omap_init_sham(void)
> > {
> > - if (cpu_is_omap24xx()) {
> > - sham_device.resource = omap2_sham_resources;
> > - sham_device.num_resources = omap2_sham_resources_sz;
> > + if (cpu_is_omap24xx() &&
> > + (omap2_cm_read_mod_reg(CORE_MOD, OMAP24XX_CM_IDLEST4) &
> > + OMAP24XX_ST_SHA_MASK)) {
>
> Hmm. Not sure I understand the purpose of this CM read. Don't we want to
> initialize this device unconditionally?
No, the device doesn't exist on all parts. This is the only way
to tell if its there (AFAIK).
> Also we're trying to get rid of all of the direct CM/PRM accesses outside
> of the prm*.c/cm*.c code. If we need something like this, we should add
> some support for it in hwmod & CM code, since that's where the data lives.
Okay.
Mark
--
^ permalink raw reply
* [PATCH 2/7] ARM: OMAP2xxx: hwmod: Add DMA information for SHAM module
From: Mark A. Greer @ 2012-10-22 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210201940260.27264@utopia.booyaka.com>
On Sat, Oct 20, 2012 at 07:40:44PM +0000, Paul Walmsley wrote:
> On Fri, 19 Oct 2012, Mark A. Greer wrote:
>
> > From: "Mark A. Greer" <mgreer@animalcreek.com>
> >
> > Add the DMA information for the OMAP2 SHA module.
> >
> > CC: Paul Walmsley <paul@pwsan.com>
> > Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
>
> This can probably be combined with the first patch.
I made it a separate patch because the original omap2xxx code didn't
support DMA and I wanted to keep the first patch an apples-apples
conversion and _add_ functionality in this, separate, patch.
I prefer 2 patches but if you still want me to combine them, let me know.
Mark
--
^ permalink raw reply
* [PATCH 0/7] crypto: omap-sham updates
From: Mark A. Greer @ 2012-10-22 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210201930440.27264@utopia.booyaka.com>
On Sat, Oct 20, 2012 at 07:34:51PM +0000, Paul Walmsley wrote:
> On Fri, 19 Oct 2012, Mark A. Greer wrote:
>
> > From: "Mark A. Greer" <mgreer@animalcreek.com>
> >
> > This series updates the crypto omap-sham driver and supporting
> > infrastructure.
>
> Looks pretty good; this will make it easier for us to migrate the
> omap_hwmod code to a LDM bus. Will reply to the original patches with a
> few comments and questions.
>
> One general comment - for us to merge these through the OMAP tree, we'll
> need acks from the hardware crypto folks. AFAIK they are:
>
> CRYPTO API
> M: Herbert Xu <herbert@gondor.apana.org.au>
> M: "David S. Miller" <davem@davemloft.net>
> L: linux-crypto at vger.kernel.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
> S: Maintained
> F: Documentation/crypto/
> F: arch/*/crypto/
> F: crypto/
> F: drivers/crypto/
> F: include/crypto/
>
> So it would be helpful if you could send those patches along to those
> people and lists too, and ask them for acks.
I will do that. Thanks for your feedback.
Mark
--
^ permalink raw reply
* [PATCH 1/7] ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod
From: Paul Walmsley @ 2012-10-22 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022193336.GA1708@animalcreek.com>
On Mon, 22 Oct 2012, Mark A. Greer wrote:
> On Sat, Oct 20, 2012 at 07:40:19PM +0000, Paul Walmsley wrote:
>
> > > static void omap_init_sham(void)
> > > {
> > > - if (cpu_is_omap24xx()) {
> > > - sham_device.resource = omap2_sham_resources;
> > > - sham_device.num_resources = omap2_sham_resources_sz;
> > > + if (cpu_is_omap24xx() &&
> > > + (omap2_cm_read_mod_reg(CORE_MOD, OMAP24XX_CM_IDLEST4) &
> > > + OMAP24XX_ST_SHA_MASK)) {
> >
> > Hmm. Not sure I understand the purpose of this CM read. Don't we want to
> > initialize this device unconditionally?
>
> No, the device doesn't exist on all parts.
It should exist on all OMAP2xxx, AFAIK. (Whether some bootloader
firewalled it off is another matter, of course.)
> This is the only way to tell if its there (AFAIK).
Hmm. I don't think the CM_IDLEST bits work that way, in the general case.
They just indicate whether the PRCM considers that IP block to be
currently accessible. So for example if the clocks are disabled to an IP
block, the CM_IDLEST bit would indicate that it's not accessible. The
software could then enable the clocks, and the CM_IDLEST bit would
indicate that it is accessible. We use this in the clock framework and
hwmod code after enabling clocks to wait until the system considers the IP
block accessible. See for example
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/mach-omap2/clock.c;h=961ac8f7e13d8c84a1cbb4587255ea685520bd18;hb=HEAD#l80
...
Now it's possible that on some TI chips, the CM_IDLEST bit is tied to the
SIdleAck signal originating from the IP block. (I've been told that on
other OMAPs, CM_IDLEST is actually tied to the SIdleReq signal originating
from the PRCM, which is not terribly useful...) So if it's tied to the
SIdleAck signal, and the PRCM clocks are enabled, then it might provide an
indication of whether the IP block exists on that chip. But ultimately
the IP block might still be firewalled off even if it appears to exist to
the PRCM. So for 3xxx, I'd suggest just adding it to the appropriate
GP-specific hwmod init lists, such as omap3xxx_gp_hwmod_ocp_ifs.
- Paul
^ permalink raw reply
* [PATCH 0/4] OMAP-GPMC generic timing migration
From: Daniel Mack @ 2012-10-22 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50817307.50509@ti.com>
On 19.10.2012 17:34, Afzal Mohammed wrote:
> Hi Daniel,
>
> On Thursday 11 October 2012 05:15 PM, Daniel Mack wrote:
>
>> Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
>> would like to augment this to make GPMC attached NAND probable in DT, in
>> case this is still an open topic.
>
> In case you can help on making gpmc nand dt probable, please
> proceed. I would be on vacation next week, may be we can
> discuss after I am back.
Enjoy your vacation :)
> am335x based boards like beagle bone should be booting on
> l-o master and it has gpmc header cleanup changes with
> minimal driver support.
>
> As I don't have the sufficient time to explain in detail, some
> pointers. Discussion between us [1] hopefully explains it in brief.
> It would be like peripherals connected to gpmc being represented
> as child nodes in dt. gpmc driver probably in probe would have to
> invoke of_platform_populate to create child nodes (for devices like
> nand). And driver would have to be enhanced to configure gpmc
> based on information passed through dt for each child nodes.
> Or roughly have a dt equivalent of driver as in [2].
Hmm, not sure if I follow all your thought here, but I cooked up
something that is straight-forward and works well for me. I'll post them
now, so we at least have a base for discussions ...
Daniel
^ permalink raw reply
* [PATCH] ARM: Only initialize max_mapnr when using flatmem
From: Michael Spang @ 2012-10-22 19:51 UTC (permalink / raw)
To: linux-arm-kernel
The expression used to initialize max_mapnr is not appropriate for
sparsemem, since mem_map is NULL and pfn_to_page() only works on valid
pages. This patch leaves max_mapnr uninitialized for sparsemem.
For flatmem, the expression simplifies to copying max_pfn.
Signed-off-by: Michael Spang <spang@chromium.org>
---
arch/arm/mm/init.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
I'm not sure we need this variable it all - it looks like there are no
users.
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index c21d06c..9b72e6f 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -600,7 +600,9 @@ void __init mem_init(void)
extern u32 itcm_end;
#endif
- max_mapnr = pfn_to_page(max_pfn + PHYS_PFN_OFFSET) - mem_map;
+#ifdef CONFIG_FLATMEM
+ max_mapnr = max_pfn;
+#endif
/* this will put all unused low memory onto the freelists */
free_unused_memmap(&meminfo);
--
1.7.7.3
^ permalink raw reply related
* [PATCH 2/7] ARM: OMAP2xxx: hwmod: Add DMA information for SHAM module
From: Paul Walmsley @ 2012-10-22 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022193714.GB1708@animalcreek.com>
On Mon, 22 Oct 2012, Mark A. Greer wrote:
> On Sat, Oct 20, 2012 at 07:40:44PM +0000, Paul Walmsley wrote:
> > On Fri, 19 Oct 2012, Mark A. Greer wrote:
> >
> > > From: "Mark A. Greer" <mgreer@animalcreek.com>
> > >
> > > Add the DMA information for the OMAP2 SHA module.
> > >
> > > CC: Paul Walmsley <paul@pwsan.com>
> > > Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> >
> > This can probably be combined with the first patch.
>
> I made it a separate patch because the original omap2xxx code didn't
> support DMA and I wanted to keep the first patch an apples-apples
> conversion and _add_ functionality in this, separate, patch.
>
> I prefer 2 patches but if you still want me to combine them, let me know.
OK, I see. That's fine, then. Maybe add a sentence about that into the
patch description of #2, that this effectively enables a code path in
the driver that wasn't being used before, and therefore should be in a
separate patch for ease of bisecting?
- Paul
^ permalink raw reply
* [PATCH 0/4] RFC: OMAP GPMC bindings
From: Daniel Mack @ 2012-10-22 19:55 UTC (permalink / raw)
To: linux-arm-kernel
This is a series of patches to support GPMC peripherals on OMAP boards.
Depends on Linus' master +
omap-next (branch omap-for-v3.8/cleanup-headers-gpmc)
The only supported peripheral for now is NAND, but other types would be
easy to add.
In order to make the gpmc driver the 'hub' for all sub-nodes, I had to
add some includes. I'm not particularily happy about the fact that there
are mutual references from gpmc.c to gpmc-nand.c now, but that was the
easiest way.
I successfully tested these patches on an AM33xx board to make NAND
work.
Comments welcome!
Thanks,
Daniel
Daniel Mack (4):
mtd: omap-nand: pass device_node in platform data
ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
ARM: OMAP: gpmc: don't create devices from initcall on DT
OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
Documentation/devicetree/bindings/bus/gpmc.txt | 59 +++++++++
.../devicetree/bindings/mtd/gpmc-nand.txt | 65 +++++++++
arch/arm/mach-omap2/gpmc-nand.c | 2 +-
arch/arm/mach-omap2/gpmc.c | 146 +++++++++++++++++++++
drivers/mtd/nand/omap2.c | 4 +-
include/linux/platform_data/mtd-nand-omap2.h | 2 +
6 files changed, 276 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/gpmc.txt
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
--
1.7.11.7
^ permalink raw reply
* [PATCH 1/4] mtd: omap-nand: pass device_node in platform data
From: Daniel Mack @ 2012-10-22 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350935758-9215-1-git-send-email-zonque@gmail.com>
Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.
For non-DT boards, this change has no effect.
Signed-off-by: Daniel Mack <zonque@gmail.com>
---
drivers/mtd/nand/omap2.c | 4 +++-
include/linux/platform_data/mtd-nand-omap2.h | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 3282b15..a733f15 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1331,6 +1331,7 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
dma_cap_mask_t mask;
unsigned sig;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev->dev.platform_data;
if (pdata == NULL) {
@@ -1556,7 +1557,8 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
goto out_release_mem_region;
}
- mtd_device_parse_register(&info->mtd, NULL, NULL, pdata->parts,
+ ppdata.of_node = pdata->of_node;
+ mtd_device_parse_register(&info->mtd, NULL, &ppdata, pdata->parts,
pdata->nr_parts);
platform_set_drvdata(pdev, &info->mtd);
diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
index 24d32ca..5217d6e 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -60,6 +60,8 @@ struct omap_nand_platform_data {
int devsize;
enum omap_ecc ecc_opt;
struct gpmc_nand_regs reg;
+ /* for passing the partitions */
+ struct device_node *of_node;
};
#endif
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/4] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
From: Daniel Mack @ 2012-10-22 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350935758-9215-1-git-send-email-zonque@gmail.com>
Signed-off-by: Daniel Mack <zonque@gmail.com>
---
arch/arm/mach-omap2/gpmc-nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 8607735..c3616c6 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -92,7 +92,7 @@ static int omap2_nand_gpmc_retime(
static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* support only OMAP3 class */
- if (!cpu_is_omap34xx()) {
+ if (!cpu_is_omap34xx() && !soc_is_am33xx()) {
pr_err("BCH ecc is not supported on this CPU\n");
return 0;
}
--
1.7.11.7
^ permalink raw reply related
* [PATCH 3/4] ARM: OMAP: gpmc: don't create devices from initcall on DT
From: Daniel Mack @ 2012-10-22 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350935758-9215-1-git-send-email-zonque@gmail.com>
On DT driven boards, the gpmc node will match the driver. Hence, there's
no need to do that unconditionally from the initcall.
Signed-off-by: Daniel Mack <zonque@gmail.com>
---
arch/arm/mach-omap2/gpmc.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 60f1cce..1dcb30c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -844,6 +844,13 @@ static int __init omap_gpmc_init(void)
struct platform_device *pdev;
char *oh_name = "gpmc";
+ /*
+ * if the board boots up with a populated DT, do not
+ * manually add the device from this initcall
+ */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
oh = omap_hwmod_lookup(oh_name);
if (!oh) {
pr_err("Could not look up %s\n", oh_name);
--
1.7.11.7
^ permalink raw reply related
* [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
From: Daniel Mack @ 2012-10-22 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350935758-9215-1-git-send-email-zonque@gmail.com>
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.
Successfully tested on an AM33xx board.
Signed-off-by: Daniel Mack <zonque@gmail.com>
---
Documentation/devicetree/bindings/bus/gpmc.txt | 59 +++++++++
.../devicetree/bindings/mtd/gpmc-nand.txt | 65 ++++++++++
arch/arm/mach-omap2/gpmc.c | 139 +++++++++++++++++++++
3 files changed, 263 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/gpmc.txt
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
diff --git a/Documentation/devicetree/bindings/bus/gpmc.txt b/Documentation/devicetree/bindings/bus/gpmc.txt
new file mode 100644
index 0000000..ef1c6e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/gpmc.txt
@@ -0,0 +1,59 @@
+Device tree bindings for OMAP general purpose memory controllers (GPMC)
+
+The actual devices are instantiated from the child nodes of a GPMC node.
+
+Required properties:
+
+ - compatible: Should be set to "ti,gpmc"
+
+Timing properties for child nodes. All are optional and default to 0.
+
+ - gpmc,sync-clk: Minimum clock period for synchronous mode, in picoseconds
+
+ Chip-select signal timings corresponding to GPMC_CS_CONFIG2:
+ - gpmc,cs-on: Assertion time
+ - gpmc,cs-rd-off: Read deassertion time
+ - gpmc,cs-wr-off: Write deassertion time
+
+ ADV signal timings corresponding to GPMC_CONFIG3:
+ - gpmc,adv-on: Assertion time
+ - gpmc,adv-rd-off: Read deassertion time
+ - gpmc,adv-wr-off: Write deassertion time
+
+ WE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,we-on: Assertion time
+ - gpmc,we-off: Deassertion time
+
+ OE signals timings corresponding to GPMC_CONFIG4
+ - gpmc,oe-on: Assertion time
+ - gpmc,oe-off: Deassertion time
+
+ Access time and cycle time timings corresponding to GPMC_CONFIG5
+ - gpmc,page-burst-access: Multiple access word delay
+ - gpmc,access: Start-cycle to first data valid delay
+ - gpmc,rd-cycle: Total read cycle time
+ - gpmc,wr-cycle: Total write cycle time
+
+The following are only on OMAP3430
+ - gpmc,wr-access
+ - gpmc,wr-data-mux-bus
+
+
+Example for an AM33xx board:
+
+ gpmc: gpmc at 50000000 {
+ compatible = "ti,gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x1000000>;
+ interrupt-parent = <&intc>;
+ interrupts = <100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* child nodes go here */
+ };
+
+
+
+
+
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
new file mode 100644
index 0000000..6790fcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,65 @@
+Device tree bindings for GPMC connected NANDs
+
+GPMC connected NAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of "nand".
+
+All timing relevant properties are explained in a separate documents - please
+refer to Documentation/devicetree/bindings/bus/gpmc.txt
+
+Required properties:
+
+ - reg: The CS line the peripheral is connected to
+
+Optional properties:
+
+ - ecc: An integer denoting on of the OMAP_ECC_* values
+ - bus-width: An integer denoting the bus width of the peripheral. The only
+ value that has any effect is 16. When omitted, a default of
+ 8bit is assumed.
+
+For inline partiton table parsing:
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an AM33xx board:
+
+ gpmc: gpmc at 50000000 {
+ compatible = "ti,gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x1000000>;
+ interrupt-parent = <&intc>;
+ interrupts = <100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand at 0 {
+ reg = <0>; /* CS0 */
+ gpmc,bus-width = <16>;
+ gpmc,ecc = <0>;
+
+ gpmc,sync-clk = <0>;
+ gpmc,cs-on = <0>;
+ gpmc,cs-rd-off = <36>;
+ gpmc,cs-wr-off = <36>;
+ gpmc,adv-on = <6>;
+ gpmc,adv-rd-off = <24>;
+ gpmc,adv-wr-off = <36>;
+ gpmc,we-off = <30>;
+ gpmc,oe-off = <48>;
+ gpmc,access = <54>;
+ gpmc,rd-cycle = <72>;
+ gpmc,wr-cycle = <72>;
+ gpmc,wr-access = <30>;
+ gpmc,wr-data-mux-bus = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* partitions go here */
+ };
+ };
+
+
+
+
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1dcb30c..2ff919e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -25,6 +25,9 @@
#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/mtd/nand.h>
#include <linux/platform_data/mtd-nand-omap2.h>
@@ -37,6 +40,7 @@
#include "soc.h"
#include "common.h"
#include "gpmc.h"
+#include "gpmc-nand.h"
#define DEVICE_NAME "omap-gpmc"
@@ -751,6 +755,132 @@ static int __devinit gpmc_mem_init(void)
return 0;
}
+#ifdef CONFIG_OF
+static struct of_device_id gpmc_dt_ids[] = {
+ { .compatible = "ti,gpmc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, gpmc_dt_ids);
+
+static void gpmc_read_timings_dt(struct device_node *np,
+ struct gpmc_timings *gpmc_t)
+{
+ u32 val;
+
+ memset(gpmc_t, 0, sizeof(*gpmc_t));
+
+ /* minimum clock period for syncronous mode */
+ if (!of_property_read_u32(np, "gpmc,sync-clk", &val))
+ gpmc_t->sync_clk = val;
+
+ /* chip select timtings */
+ if (!of_property_read_u32(np, "gpmc,cs-on", &val))
+ gpmc_t->cs_on = val;
+
+ if (!of_property_read_u32(np, "gpmc,cs-rd-off", &val))
+ gpmc_t->cs_rd_off = val;
+
+ if (!of_property_read_u32(np, "gpmc,cs-wr-off", &val))
+ gpmc_t->cs_wr_off = val;
+
+ /* ADV signal timings */
+ if (!of_property_read_u32(np, "gpmc,adv-on", &val))
+ gpmc_t->adv_on = val;
+
+ if (!of_property_read_u32(np, "gpmc,adv-rd-off", &val))
+ gpmc_t->adv_rd_off = val;
+
+ if (!of_property_read_u32(np, "gpmc,adv-wr-off", &val))
+ gpmc_t->adv_wr_off = val;
+
+ /* WE signal timings */
+ if (!of_property_read_u32(np, "gpmc,we-on", &val))
+ gpmc_t->we_on = val;
+
+ if (!of_property_read_u32(np, "gpmc,we-off", &val))
+ gpmc_t->we_off = val;
+
+ /* OE signal timings */
+ if (!of_property_read_u32(np, "gpmc,we-on", &val))
+
+ if (!of_property_read_u32(np, "gpmc,oe-on", &val))
+ gpmc_t->oe_on = val;
+
+ if (!of_property_read_u32(np, "gpmc,oe-off", &val))
+ gpmc_t->oe_off = val;
+
+ /* access and cycle timings */
+ if (!of_property_read_u32(np, "gpmc,page-burst-access", &val))
+ gpmc_t->page_burst_access = val;
+
+ if (!of_property_read_u32(np, "gpmc,access", &val))
+ gpmc_t->access = val;
+
+ if (!of_property_read_u32(np, "gpmc,rd-cycle", &val))
+ gpmc_t->rd_cycle = val;
+
+ if (!of_property_read_u32(np, "gpmc,wr-cycle", &val))
+ gpmc_t->wr_cycle = val;
+
+ /* only for OMAP3430 */
+ if (!of_property_read_u32(np, "gpmc,wr-access", &val))
+ gpmc_t->wr_access = val;
+
+ if (!of_property_read_u32(np, "gpmc,wr-data-mux-bus", &val))
+ gpmc_t->wr_data_mux_bus = val;
+}
+
+static int gpmc_probe_dt(struct platform_device *pdev)
+{
+ u32 val;
+ struct device_node *child;
+ struct gpmc_timings gpmc_t;
+ const struct of_device_id *of_id =
+ of_match_device(gpmc_dt_ids, &pdev->dev);
+
+ if (!of_id)
+ return 0;
+
+ for_each_node_by_name(child, "nand") {
+ struct omap_nand_platform_data *gpmc_nand_data;
+
+ if (of_property_read_u32(child, "reg", &val) < 0) {
+ dev_err(&pdev->dev, "%s has no 'reg' property\n",
+ child->full_name);
+ continue;
+ }
+
+ gpmc_nand_data = devm_kzalloc(&pdev->dev,
+ sizeof(*gpmc_nand_data),
+ GFP_KERNEL);
+ if (!gpmc_nand_data) {
+ dev_err(&pdev->dev, "unable to allocate memory?");
+ return -ENOMEM;
+ }
+
+ gpmc_nand_data->cs = val;
+ gpmc_nand_data->of_node = child;
+
+ if (!of_property_read_u32(child, "gpmc,ecc", &val) < 0)
+ gpmc_nand_data->ecc_opt = val;
+
+ if ((!of_property_read_u32(child, "gpmc,bus-width", &val) < 0) &&
+ val == 16)
+ gpmc_nand_data->devsize = NAND_BUSWIDTH_16;
+
+ gpmc_read_timings_dt(child, &gpmc_t);
+ gpmc_nand_init(gpmc_nand_data, &gpmc_t);
+ }
+
+ return 0;
+}
+#else
+static int gpmc_probe_dt(struct platform_device *pdev)
+{
+ return 0;
+}
+#endif
+
static __devinit int gpmc_probe(struct platform_device *pdev)
{
int rc;
@@ -804,6 +934,14 @@ static __devinit int gpmc_probe(struct platform_device *pdev)
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
+ rc = gpmc_probe_dt(pdev);
+ if (rc < 0) {
+ clk_disable_unprepare(gpmc_l3_clk);
+ clk_put(gpmc_l3_clk);
+ dev_err(gpmc_dev, "failed to probe DT parameters\n");
+ return rc;
+ }
+
return 0;
}
@@ -821,6 +959,7 @@ static struct platform_driver gpmc_driver = {
.driver = {
.name = DEVICE_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(gpmc_dt_ids),
},
};
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/7] ARM: OMAP2xxx: hwmod: Add DMA information for SHAM module
From: Mark A. Greer @ 2012-10-22 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210221950330.13464@utopia.booyaka.com>
On Mon, Oct 22, 2012 at 07:53:06PM +0000, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Mark A. Greer wrote:
>
> > On Sat, Oct 20, 2012 at 07:40:44PM +0000, Paul Walmsley wrote:
> > > On Fri, 19 Oct 2012, Mark A. Greer wrote:
> > >
> > > > From: "Mark A. Greer" <mgreer@animalcreek.com>
> > > >
> > > > Add the DMA information for the OMAP2 SHA module.
> > > >
> > > > CC: Paul Walmsley <paul@pwsan.com>
> > > > Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> > >
> > > This can probably be combined with the first patch.
> >
> > I made it a separate patch because the original omap2xxx code didn't
> > support DMA and I wanted to keep the first patch an apples-apples
> > conversion and _add_ functionality in this, separate, patch.
> >
> > I prefer 2 patches but if you still want me to combine them, let me know.
>
> OK, I see. That's fine, then. Maybe add a sentence about that into the
> patch description of #2, that this effectively enables a code path in
> the driver that wasn't being used before, and therefore should be in a
> separate patch for ease of bisecting?
Sure. After your comment I realized my description was insufficient.
Mark
--
^ 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