From hs at denx.de  Wed Feb  1 00:40:24 2012
From: hs at denx.de (Heiko Schocher)
Date: Wed, 01 Feb 2012 07:40:24 +0100
Subject: [PATCH v3] ARM: davinci: map default_queue to edma channels
In-Reply-To: <DF0F476B391FA8409C78302C7BA518B6317970CE@DBDE01.ent.ti.com>
References: <1326956721-25158-1-git-send-email-hs@denx.de>
	<DF0F476B391FA8409C78302C7BA518B6317970CE@DBDE01.ent.ti.com>
Message-ID: <4F28DE58.3040902@denx.de>

Hello Nori,

Nori, Sekhar wrote:
> Hi Heiko,
> 
> On Thu, Jan 19, 2012 at 12:35:21, Heiko Schocher wrote:
>> Default queue is expected to be a low-priority queue.
>> This way, long transfers on the default queue started
>> by the codec engine will not cause audio defects.
>>
>> Signed-off-by: Heiko Schocher <hs at denx.de>
> 
>> Signed-off-by: juha.kuikka at gmail.com
>> Reported-by: juha.kuikka at gmail.com
> 
> Sign-off should include real name, so I changed these
> two lines to:
> 
>     Signed-off-by: Juha Kuikka <juha.kuikka at gmail.com>
>     Reported-by: Juha Kuikka <juha.kuikka at gmail.com>

Thanks!

> before applying. Let me know if anyone has objections.

I saw no objections, so can this patch go in now?

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

From sshtylyov at mvista.com  Wed Feb  1 04:20:13 2012
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 01 Feb 2012 14:20:13 +0400
Subject: [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based
	enbw_cmc board
In-Reply-To: <4F27E6E0.1050608@denx.de>
References: <1327308967-8092-1-git-send-email-hs@denx.de>
	<1327308967-8092-8-git-send-email-hs@denx.de>
	<20120130203252.GX28397@ponder.secretlab.ca>
	<4F27E6E0.1050608@denx.de>
Message-ID: <4F2911DD.6010405@mvista.com>

Hello.

On 31-01-2012 17:04, Heiko Schocher wrote:

>> On Mon, Jan 23, 2012 at 09:56:07AM +0100, Heiko Schocher wrote:
>>> - AM1808 based board
>>> - 64 MiB DDR ram
>>> - 2 MiB Nor flash
>>> - 128 MiB NAND flash
>>> - use internal RTC
>>> - I2C support
>>> - hwmon lm75 support
>>> - UBI/UBIFS support
>>> - MMC support
>>> - USB OTG support

>>> Signed-off-by: Heiko Schocher<hs at denx.de>
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: devicetree-discuss at lists.ozlabs.org
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> Cc: linux-mtd at lists.infradead.org
>>> Cc: linux-i2c at vger.kernel.org
>>> Cc: netdev at vger.kernel.org
>>> Cc: David Woodhouse<dwmw2 at infradead.org>
>>> Cc: Ben Dooks<ben-linux at fluff.org>
>>> Cc: Wolfram Sang<w.sang at pengutronix.de>
>>> Cc: Sekhar Nori<nsekhar at ti.com>
>>> Cc: Kevin Hilman<khilman at ti.com>
>>> Cc: Wolfgang Denk<wd at denx.de>

>>> ---
>>> - post this board support with USB support, even though
>>>    USB is only working with the 10 ms "workaround", posted here:
>>>    http://comments.gmane.org/gmane.linux.usb.general/54505
>>>    I see this issue also on the AM1808 TMDXEXP1808L evalboard.
>>> - MMC and USB are not using OF support yet, ideas how to port
>>>    this are welcome. I need for USB and MMC boards board
>>>    specific callbacks, how to solve this with OF support?

[...]

>>> diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts
>>> new file mode 100644
>>> index 0000000..e5995ce
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/enbw_cmc.dts
[...]

>>> +			compatible = "ns16550a";

>> Should include a string for the specific device.  Something like:

>> 	compatible = "ti,da800", "ns16550a";

> added.

    Note that there's no DA800 chip, only DA828, DA830, and DA850 AFAIK.

WBR, Sergei

From m-karicheri2 at ti.com  Wed Feb  1 09:10:33 2012
From: m-karicheri2 at ti.com (Karicheri, Muralidharan)
Date: Wed, 1 Feb 2012 15:10:33 +0000
Subject: UBIFS with davinci NAND driver - ECC error
In-Reply-To: <B6A220404B6BFC4BBD2AB91C54D39DF43176BE25@DBDE01.ent.ti.com>
References: <3E54258959B69E4282D79E01AB1F32B72747DF@DFLE34.ent.ti.com>
	<B6A220404B6BFC4BBD2AB91C54D39DF43176BE25@DBDE01.ent.ti.com>
Message-ID: <3E54258959B69E4282D79E01AB1F32B727515C@DFLE34.ent.ti.com>

Sudhakar,

Thanks for your response. I will look into this and hope it will help.

Murali Karicheri
Software Design Engineer
email: m-karicheri2 at ti.com
Phone: (301) 407 9583


>> -----Original Message-----
>> From: Rajashekhara, Sudhakar
>> Sent: Tuesday, January 31, 2012 11:48 PM
>> To: Karicheri, Muralidharan; davinci-linux-open-source at linux.davincidsp.com;
>> Nori, Sekhar
>> Subject: RE: UBIFS with davinci NAND driver - ECC error
>> 
>> Hi Murali,
>> 
>> On Wed, Feb 01, 2012 at 02:51:03, Karicheri, Muralidharan wrote:
>> > Hi,
>> >
>> > I am trying to use UBIFS in my project and we are using the davinci
>> > nand driver with a flash part that has page size of 2048, block size
>> > of 128KiB and size of 128MiB. I have done following to boot the kernel
>> > with a UBIFS rootfs.
>> >
>> 
>> Please refer to http://processors.wiki.ti.com/index.php/UBIFS_Support
>> which has steps to get UBIFS working on AM335x. But I followed these
>> steps and was able to get UBIFS working on OMAP-L138. The bootargs I
>> used from U-Boot are as below:
>> 
>> setenv bootargs mem=32M console=ttyS2,115200n8 root=ubi0:rootfs rw
>> rootfstype=ubifs ubi.mtd=4,2048 ip=dhcp
>> 
>> Note that I also faced similar booting issues when I was using mkfs.ubifs
>> version 1.3 on the host system to generate the UBIFS file system. The
>> issue went away when I used v 1.4.8.
>> 
>> Thanks,
>> Sudhakar

From m-karicheri2 at ti.com  Wed Feb  1 10:47:55 2012
From: m-karicheri2 at ti.com (Karicheri, Muralidharan)
Date: Wed, 1 Feb 2012 16:47:55 +0000
Subject: UBIFS with davinci NAND driver - ECC error
In-Reply-To: <B6A220404B6BFC4BBD2AB91C54D39DF43176BE25@DBDE01.ent.ti.com>
References: <3E54258959B69E4282D79E01AB1F32B72747DF@DFLE34.ent.ti.com>
	<B6A220404B6BFC4BBD2AB91C54D39DF43176BE25@DBDE01.ent.ti.com>
Message-ID: <3E54258959B69E4282D79E01AB1F32B727529A@DFLE34.ent.ti.com>

Sudhakhar,

Did you fix anything on the Linux NAND and u-boot NAND driver to disable sub page writes?

Murali Karicheri
Software Design Engineer
email: m-karicheri2 at ti.com
Phone: (301) 407 9583


>> -----Original Message-----
>> From: Rajashekhara, Sudhakar
>> Sent: Tuesday, January 31, 2012 11:48 PM
>> To: Karicheri, Muralidharan; davinci-linux-open-source at linux.davincidsp.com;
>> Nori, Sekhar
>> Subject: RE: UBIFS with davinci NAND driver - ECC error
>> 
>> Hi Murali,
>> 
>> On Wed, Feb 01, 2012 at 02:51:03, Karicheri, Muralidharan wrote:
>> > Hi,
>> >
>> > I am trying to use UBIFS in my project and we are using the davinci
>> > nand driver with a flash part that has page size of 2048, block size
>> > of 128KiB and size of 128MiB. I have done following to boot the kernel
>> > with a UBIFS rootfs.
>> >
>> 
>> Please refer to http://processors.wiki.ti.com/index.php/UBIFS_Support
>> which has steps to get UBIFS working on AM335x. But I followed these
>> steps and was able to get UBIFS working on OMAP-L138. The bootargs I
>> used from U-Boot are as below:
>> 
>> setenv bootargs mem=32M console=ttyS2,115200n8 root=ubi0:rootfs rw
>> rootfstype=ubifs ubi.mtd=4,2048 ip=dhcp
>> 
>> Note that I also faced similar booting issues when I was using mkfs.ubifs
>> version 1.3 on the host system to generate the UBIFS file system. The
>> issue went away when I used v 1.4.8.
>> 
>> Thanks,
>> Sudhakar

From m-karicheri2 at ti.com  Wed Feb  1 11:07:03 2012
From: m-karicheri2 at ti.com (Karicheri, Muralidharan)
Date: Wed, 1 Feb 2012 17:07:03 +0000
Subject: UBIFS with davinci NAND driver - ECC error
In-Reply-To: <3E54258959B69E4282D79E01AB1F32B727529A@DFLE34.ent.ti.com>
References: <3E54258959B69E4282D79E01AB1F32B72747DF@DFLE34.ent.ti.com>
	<B6A220404B6BFC4BBD2AB91C54D39DF43176BE25@DBDE01.ent.ti.com>
	<3E54258959B69E4282D79E01AB1F32B727529A@DFLE34.ent.ti.com>
Message-ID: <3E54258959B69E4282D79E01AB1F32B7275321@DFLE34.ent.ti.com>

Also what version of kernel and u-boot are you using for OMAP?

Murali Karicheri
Software Design Engineer
email: m-karicheri2 at ti.com
Phone: (301) 407 9583


>> -----Original Message-----
>> From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-
>> linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Karicheri,
>> Muralidharan
>> Sent: Wednesday, February 01, 2012 11:48 AM
>> To: Rajashekhara, Sudhakar; davinci-linux-open-source at linux.davincidsp.com;
>> Nori, Sekhar
>> Cc: Zhang, Hao
>> Subject: RE: UBIFS with davinci NAND driver - ECC error
>> 
>> Sudhakhar,
>> 
>> Did you fix anything on the Linux NAND and u-boot NAND driver to disable sub
>> page writes?
>> 
>> Murali Karicheri
>> Software Design Engineer
>> email: m-karicheri2 at ti.com
>> Phone: (301) 407 9583
>> 
>> 
>> >> -----Original Message-----
>> >> From: Rajashekhara, Sudhakar
>> >> Sent: Tuesday, January 31, 2012 11:48 PM
>> >> To: Karicheri, Muralidharan; davinci-linux-open-
>> source at linux.davincidsp.com;
>> >> Nori, Sekhar
>> >> Subject: RE: UBIFS with davinci NAND driver - ECC error
>> >>
>> >> Hi Murali,
>> >>
>> >> On Wed, Feb 01, 2012 at 02:51:03, Karicheri, Muralidharan wrote:
>> >> > Hi,
>> >> >
>> >> > I am trying to use UBIFS in my project and we are using the davinci
>> >> > nand driver with a flash part that has page size of 2048, block size
>> >> > of 128KiB and size of 128MiB. I have done following to boot the kernel
>> >> > with a UBIFS rootfs.
>> >> >
>> >>
>> >> Please refer to http://processors.wiki.ti.com/index.php/UBIFS_Support
>> >> which has steps to get UBIFS working on AM335x. But I followed these
>> >> steps and was able to get UBIFS working on OMAP-L138. The bootargs I
>> >> used from U-Boot are as below:
>> >>
>> >> setenv bootargs mem=32M console=ttyS2,115200n8 root=ubi0:rootfs rw
>> >> rootfstype=ubifs ubi.mtd=4,2048 ip=dhcp
>> >>
>> >> Note that I also faced similar booting issues when I was using mkfs.ubifs
>> >> version 1.3 on the host system to generate the UBIFS file system. The
>> >> issue went away when I used v 1.4.8.
>> >>
>> >> Thanks,
>> >> Sudhakar
>> _______________________________________________
>> Davinci-linux-open-source mailing list
>> Davinci-linux-open-source at linux.davincidsp.com
>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From grant.likely at secretlab.ca  Wed Feb  1 18:17:30 2012
From: grant.likely at secretlab.ca (Grant Likely)
Date: Wed, 1 Feb 2012 17:17:30 -0700
Subject: [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based
	enbw_cmc board
In-Reply-To: <4F2911DD.6010405@mvista.com>
References: <1327308967-8092-1-git-send-email-hs@denx.de>
	<1327308967-8092-8-git-send-email-hs@denx.de>
	<20120130203252.GX28397@ponder.secretlab.ca>
	<4F27E6E0.1050608@denx.de> <4F2911DD.6010405@mvista.com>
Message-ID: <20120202001730.GF15343@ponder.secretlab.ca>

On Wed, Feb 01, 2012 at 02:20:13PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 31-01-2012 17:04, Heiko Schocher wrote:
> 
> >>On Mon, Jan 23, 2012 at 09:56:07AM +0100, Heiko Schocher wrote:
> >>>- AM1808 based board
> >>>- 64 MiB DDR ram
> >>>- 2 MiB Nor flash
> >>>- 128 MiB NAND flash
> >>>- use internal RTC
> >>>- I2C support
> >>>- hwmon lm75 support
> >>>- UBI/UBIFS support
> >>>- MMC support
> >>>- USB OTG support
> 
> >>>Signed-off-by: Heiko Schocher<hs at denx.de>
> >>>Cc: linux-arm-kernel at lists.infradead.org
> >>>Cc: devicetree-discuss at lists.ozlabs.org
> >>>Cc: davinci-linux-open-source at linux.davincidsp.com
> >>>Cc: linux-mtd at lists.infradead.org
> >>>Cc: linux-i2c at vger.kernel.org
> >>>Cc: netdev at vger.kernel.org
> >>>Cc: David Woodhouse<dwmw2 at infradead.org>
> >>>Cc: Ben Dooks<ben-linux at fluff.org>
> >>>Cc: Wolfram Sang<w.sang at pengutronix.de>
> >>>Cc: Sekhar Nori<nsekhar at ti.com>
> >>>Cc: Kevin Hilman<khilman at ti.com>
> >>>Cc: Wolfgang Denk<wd at denx.de>
> 
> >>>---
> >>>- post this board support with USB support, even though
> >>>   USB is only working with the 10 ms "workaround", posted here:
> >>>   http://comments.gmane.org/gmane.linux.usb.general/54505
> >>>   I see this issue also on the AM1808 TMDXEXP1808L evalboard.
> >>>- MMC and USB are not using OF support yet, ideas how to port
> >>>   this are welcome. I need for USB and MMC boards board
> >>>   specific callbacks, how to solve this with OF support?
> 
> [...]
> 
> >>>diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts
> >>>new file mode 100644
> >>>index 0000000..e5995ce
> >>>--- /dev/null
> >>>+++ b/arch/arm/boot/dts/enbw_cmc.dts
> [...]
> 
> >>>+			compatible = "ns16550a";
> 
> >>Should include a string for the specific device.  Something like:
> 
> >>	compatible = "ti,da800", "ns16550a";
> 
> >added.
> 
>    Note that there's no DA800 chip, only DA828, DA830, and DA850 AFAIK.

Right, so the compatible string should reflect that.

g.


From grant.likely at secretlab.ca  Wed Feb  1 18:19:55 2012
From: grant.likely at secretlab.ca (Grant Likely)
Date: Wed, 1 Feb 2012 17:19:55 -0700
Subject: [RFC PATCH 4/7] ARM: davinci: net: davinci_emac: add OF support
In-Reply-To: <4F27D00F.4040807@denx.de>
References: <1327308967-8092-1-git-send-email-hs@denx.de>
	<1327308967-8092-5-git-send-email-hs@denx.de>
	<20120130202208.GW28397@ponder.secretlab.ca>
	<4F27D00F.4040807@denx.de>
Message-ID: <20120202001955.GG15343@ponder.secretlab.ca>

On Tue, Jan 31, 2012 at 12:27:11PM +0100, Heiko Schocher wrote:
> Hello Grant,
> 
> Grant Likely wrote:
> > On Mon, Jan 23, 2012 at 09:56:04AM +0100, Heiko Schocher wrote:
> >> add of support for the davinci_emac driver.
> >>
> >> Signed-off-by: Heiko Schocher <hs at denx.de>
> >> Cc: davinci-linux-open-source at linux.davincidsp.com
> >> Cc: linux-arm-kernel at lists.infradead.org
> >> Cc: devicetree-discuss at lists.ozlabs.org
> >> Cc: netdev at vger.kernel.org
> >> Cc: Grant Likely <grant.likely at secretlab.ca>
> >> Cc: Sekhar Nori <nsekhar at ti.com>
> >> Cc: Wolfgang Denk <wd at denx.de>
> >> ---
> >>  .../bindings/arm/davinci/davinci_emac.txt          |   46 ++++++++
> >>  drivers/net/ethernet/ti/davinci_emac.c             |  111 +++++++++++++++++++-
> >>  2 files changed, 156 insertions(+), 1 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
> >> new file mode 100644
> >> index 0000000..4e5dc8d
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
> >> @@ -0,0 +1,46 @@
> >> +* Texas Instruments Davinci EMAC
> >> +
> >> +This file provides information, what the davice node
> >> +for the davinci_emac interface contain.
> >> +
> >> +Required properties:
> >> +- compatible: "ti,davinci-emac";
> >> +- reg: Offset and length of the register set for the device
> >> +- ctrl_reg_offset: offset to control register
> >> +- ctrl_mod_reg_offset: offset to control module register
> >> +- ctrl_ram_offset: offset to control module ram
> > 
> > Should these be explicit properties, or can they be discerned from the
> > compatible string (which should include the hardware version; see
> > below).
> 
> Hmm.. I do not know all davinci SoCs ... maybe someone from TI
> could answer this? But I think, we could discern this from
> the compatible string. I prepare this for v2. Maybe it is Ok,
> if I do this only for my hardwareversion and others add this,
> if needed? (maybe the better approach, as I can code it, but
> have no hw for testing it ... so it maybe is buggy)
> 
> > Also, any custom properties that are specific to a binding really
> > should include a vendor prefix ('ti,') to avoid namespace collisions
> > with common bindings.
> 
> Yep, is "ti,davinci-" ok? Also I should use dashes instead
> underscores, right?

Correct.

> 
> >> +- hw_ram_addr: hardware ram addr
> > 
> > Can this be added as a second tuple in the reg property?
> 
> No, if I know this right, this is used for DMA, and also could be RAM.

Not getting what you mean here.  The second tuple could be omitted if there
isn't a physical address for hardware ram.


From grant.likely at secretlab.ca  Wed Feb  1 22:54:59 2012
From: grant.likely at secretlab.ca (Grant Likely)
Date: Wed, 1 Feb 2012 21:54:59 -0700
Subject: [RFC PATCH 1/7] ARM: davinci, intc: Add OF support for TI
	interrupt controller
In-Reply-To: <1327308967-8092-2-git-send-email-hs@denx.de>
References: <1327308967-8092-1-git-send-email-hs@denx.de>
	<1327308967-8092-2-git-send-email-hs@denx.de>
Message-ID: <20120202045459.GI15343@ponder.secretlab.ca>

On Mon, Jan 23, 2012 at 09:56:01AM +0100, Heiko Schocher wrote:
> Add a function to initialize the davinci interrupt controller (INTC)
> using a device tree node.
> 
> Signed-off-by: Heiko Schocher <hs at denx.de>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Cc: Wolfgang Denk <wd at denx.de>
> ---
>  .../devicetree/bindings/arm/davinci/intc.txt       |   26 ++++++++++
>  arch/arm/mach-davinci/cp_intc.c                    |   51 ++++++++++++++++++++
>  arch/arm/mach-davinci/include/mach/cp_intc.h       |    1 +
>  3 files changed, 78 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/davinci/intc.txt b/Documentation/devicetree/bindings/arm/davinci/intc.txt
> new file mode 100644
> index 0000000..dac2f69
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/intc.txt
> @@ -0,0 +1,26 @@
> +* TI Davinci Interrupt Controller
> +
> +davinci are using a TI interrupt controller that can support several
> +configurable number of interrupts.
> +
> +Main node required properties:
> +
> +- compatible : should be:
> +	"ti,davinci-intc"
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt source. The type shall be a <u32> and the value shall be 1.
> +
> +  The cell contains the interrupt number in the range [0-128].
> +- ti,intc-size: Number of interrupts handled by the interrupt controller.
> +- reg: physical base address and size of the intc registers map.
> +
> +Example:
> +
> +	intc: interrupt-controller at 1 {
> +		compatible = "ti,davinci-intc";
> +		interrupt-controller;
> +		#interrupt-cells = <1>;
> +		ti,intc-size = <101>;
> +		reg = <0xfffee000 0x2000>;
> +	};
> diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
> index f83152d..2c6e2e4 100644
> --- a/arch/arm/mach-davinci/cp_intc.c
> +++ b/arch/arm/mach-davinci/cp_intc.c
> @@ -11,7 +11,11 @@
>  
>  #include <linux/init.h>
>  #include <linux/irq.h>
> +#include <linux/irqdomain.h>
>  #include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
>  
>  #include <mach/common.h>
>  #include <mach/cp_intc.h>
> @@ -175,3 +179,50 @@ void __init cp_intc_init(void)
>  	/* Enable global interrupt */
>  	cp_intc_write(1, CP_INTC_GLOBAL_ENABLE);
>  }
> +
> +#ifdef CONFIG_OF
> +int __init dv_intc_of_init(struct device_node *node, struct device_node *parent)
> +{
> +	struct resource res;
> +	u32 nr_irqs;
> +
> +	if (WARN_ON(!node))
> +		return -ENODEV;
> +
> +	if (of_address_to_resource(node, 0, &res)) {
> +		WARN(1, "unable to get intc registers\n");
> +		return -EINVAL;
> +	}
> +
> +	davinci_soc_info.intc_base = res.start;
> +	if (WARN_ON(!davinci_soc_info.intc_base))
> +		return -EINVAL;
> +
> +	if (of_property_read_u32(node, "ti,intc-size", &nr_irqs)) {
> +		WARN(1, "unable to get intc-size\n");
> +		return -EINVAL;
> +	}
> +	davinci_soc_info.intc_irq_num = nr_irqs;
> +	davinci_soc_info.intc_type = DAVINCI_INTC_TYPE_CP_INTC;
> +
> +	cp_intc_init();
> +	irq_domain_add_simple(node, 0);

Take a look at the irq_domain patches that will be (probably) merged
in v3.4.  Instead of calling irq_domain_add_simple(), you should
migrate the whole interrupt controller to natively use an irq_domain
for hwirq <--> irq mapping.

g.

From nsekhar at ti.com  Thu Feb  2 13:53:11 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Thu, 2 Feb 2012 19:53:11 +0000
Subject: [PATCH v3] ARM: davinci: map default_queue to edma channels
In-Reply-To: <4F28DE58.3040902@denx.de>
References: <1326956721-25158-1-git-send-email-hs@denx.de>
	<DF0F476B391FA8409C78302C7BA518B6317970CE@DBDE01.ent.ti.com>
	<4F28DE58.3040902@denx.de>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317AE7C6@DBDE01.ent.ti.com>

Hi Heiko,

On Wed, Feb 01, 2012 at 12:10:24, Heiko Schocher wrote:
> Hello Nori,
> 
> Nori, Sekhar wrote:
> > Hi Heiko,
> > 
> > On Thu, Jan 19, 2012 at 12:35:21, Heiko Schocher wrote:
> >> Default queue is expected to be a low-priority queue.
> >> This way, long transfers on the default queue started
> >> by the codec engine will not cause audio defects.
> >>
> >> Signed-off-by: Heiko Schocher <hs at denx.de>
> > 
> >> Signed-off-by: juha.kuikka at gmail.com
> >> Reported-by: juha.kuikka at gmail.com
> > 
> > Sign-off should include real name, so I changed these
> > two lines to:
> > 
> >     Signed-off-by: Juha Kuikka <juha.kuikka at gmail.com>
> >     Reported-by: Juha Kuikka <juha.kuikka at gmail.com>
> 
> Thanks!
> 
> > before applying. Let me know if anyone has objections.
> 
> I saw no objections, so can this patch go in now?

Queuing this for v3.4. Thanks for the reminder.

Regards,
Sekhar

From m-karicheri2 at ti.com  Thu Feb  2 17:39:27 2012
From: m-karicheri2 at ti.com (Karicheri, Muralidharan)
Date: Thu, 2 Feb 2012 23:39:27 +0000
Subject: UBIFS with davinci NAND driver - ECC error
In-Reply-To: <3E54258959B69E4282D79E01AB1F32B7275321@DFLE34.ent.ti.com>
References: <3E54258959B69E4282D79E01AB1F32B72747DF@DFLE34.ent.ti.com>
	<B6A220404B6BFC4BBD2AB91C54D39DF43176BE25@DBDE01.ent.ti.com>
	<3E54258959B69E4282D79E01AB1F32B727529A@DFLE34.ent.ti.com>
	<3E54258959B69E4282D79E01AB1F32B7275321@DFLE34.ent.ti.com>
Message-ID: <3E54258959B69E4282D79E01AB1F32B72764B7@DFLE34.ent.ti.com>

Sudhakar,

The good news is that I am able to get UBIFS working as per your procedure. But I have to make following changes as well:-

1) Disable sub-page write in Linux kernel nand driver and u-boot nand driver. Have you done this at your end?
2) Use a sub page size of 2048 in mkfs and ubinize commands. Your procdure still shows -s 512 though the procedure mention about disabling sub page writes.

With these I can ubiformat a partition for rootfs from Linux and boot Linux using the rootfs volume. But following steps still doesn't work when you try the same from u-boot

1) nand erase.part <rootfs partition>
2) nand write 0x88000000 <rootfs partition> <size>
3) Boot using rootfs volume.

We see ECC error when Linux boots up. Have you made any changes
To u-boot code? Is there a step missing between 1) and 2) similar to ubiformat?

Murali Karicheri
Software Design Engineer
email: m-karicheri2 at ti.com
Phone: (301) 407 9583


>> -----Original Message-----
>> From: Karicheri, Muralidharan
>> Sent: Wednesday, February 01, 2012 12:07 PM
>> To: Karicheri, Muralidharan; Rajashekhara, Sudhakar; davinci-linux-open-
>> source at linux.davincidsp.com; Nori, Sekhar
>> Cc: Zhang, Hao
>> Subject: RE: UBIFS with davinci NAND driver - ECC error
>> 
>> Also what version of kernel and u-boot are you using for OMAP?
>> 
>> Murali Karicheri
>> Software Design Engineer
>> email: m-karicheri2 at ti.com
>> Phone: (301) 407 9583
>> 
>> 
>> >> -----Original Message-----
>> >> From: davinci-linux-open-source-bounces at linux.davincidsp.com
>> [mailto:davinci-
>> >> linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Karicheri,
>> >> Muralidharan
>> >> Sent: Wednesday, February 01, 2012 11:48 AM
>> >> To: Rajashekhara, Sudhakar; davinci-linux-open-
>> source at linux.davincidsp.com;
>> >> Nori, Sekhar
>> >> Cc: Zhang, Hao
>> >> Subject: RE: UBIFS with davinci NAND driver - ECC error
>> >>
>> >> Sudhakhar,
>> >>
>> >> Did you fix anything on the Linux NAND and u-boot NAND driver to disable
>> sub
>> >> page writes?
>> >>
>> >> Murali Karicheri
>> >> Software Design Engineer
>> >> email: m-karicheri2 at ti.com
>> >> Phone: (301) 407 9583
>> >>
>> >>
>> >> >> -----Original Message-----
>> >> >> From: Rajashekhara, Sudhakar
>> >> >> Sent: Tuesday, January 31, 2012 11:48 PM
>> >> >> To: Karicheri, Muralidharan; davinci-linux-open-
>> >> source at linux.davincidsp.com;
>> >> >> Nori, Sekhar
>> >> >> Subject: RE: UBIFS with davinci NAND driver - ECC error
>> >> >>
>> >> >> Hi Murali,
>> >> >>
>> >> >> On Wed, Feb 01, 2012 at 02:51:03, Karicheri, Muralidharan wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > I am trying to use UBIFS in my project and we are using the davinci
>> >> >> > nand driver with a flash part that has page size of 2048, block size
>> >> >> > of 128KiB and size of 128MiB. I have done following to boot the
>> kernel
>> >> >> > with a UBIFS rootfs.
>> >> >> >
>> >> >>
>> >> >> Please refer to http://processors.wiki.ti.com/index.php/UBIFS_Support
>> >> >> which has steps to get UBIFS working on AM335x. But I followed these
>> >> >> steps and was able to get UBIFS working on OMAP-L138. The bootargs I
>> >> >> used from U-Boot are as below:
>> >> >>
>> >> >> setenv bootargs mem=32M console=ttyS2,115200n8 root=ubi0:rootfs rw
>> >> >> rootfstype=ubifs ubi.mtd=4,2048 ip=dhcp
>> >> >>
>> >> >> Note that I also faced similar booting issues when I was using
>> mkfs.ubifs
>> >> >> version 1.3 on the host system to generate the UBIFS file system. The
>> >> >> issue went away when I used v 1.4.8.
>> >> >>
>> >> >> Thanks,
>> >> >> Sudhakar
>> >> _______________________________________________
>> >> Davinci-linux-open-source mailing list
>> >> Davinci-linux-open-source at linux.davincidsp.com
>> >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

From sudhakar.raj at ti.com  Thu Feb  2 23:09:44 2012
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Fri, 3 Feb 2012 05:09:44 +0000
Subject: UBIFS with davinci NAND driver - ECC error
In-Reply-To: <3E54258959B69E4282D79E01AB1F32B72764B7@DFLE34.ent.ti.com>
References: <3E54258959B69E4282D79E01AB1F32B72747DF@DFLE34.ent.ti.com>
	<B6A220404B6BFC4BBD2AB91C54D39DF43176BE25@DBDE01.ent.ti.com>
	<3E54258959B69E4282D79E01AB1F32B727529A@DFLE34.ent.ti.com>
	<3E54258959B69E4282D79E01AB1F32B7275321@DFLE34.ent.ti.com>
	<3E54258959B69E4282D79E01AB1F32B72764B7@DFLE34.ent.ti.com>
Message-ID: <B6A220404B6BFC4BBD2AB91C54D39DF43176D800@DBDE01.ent.ti.com>

Hi Murali,

On Fri, Feb 03, 2012 at 05:09:27, Karicheri, Muralidharan wrote:
> Sudhakar,
> 
> The good news is that I am able to get UBIFS working as per your
> procedure. But I have to make following changes as well:-
> 
> 1) Disable sub-page write in Linux kernel nand driver and u-boot
> nand driver. Have you done this at your end?
> 2) Use a sub page size of 2048 in mkfs and ubinize commands. Your
> procdure still shows -s 512 though the procedure mention about disabling
> sub page writes.
> 
> With these I can ubiformat a partition for rootfs from Linux and boot
> Linux using the rootfs volume. But following steps still doesn't work when
> you try the same from u-boot
> 
> 1) nand erase.part <rootfs partition>
> 2) nand write 0x88000000 <rootfs partition> <size>
> 3) Boot using rootfs volume.
> 
> We see ECC error when Linux boots up. Have you made any changes
> To u-boot code? Is there a step missing between 1) and 2) similar to ubiformat?
> 

I have not tried it from u-boot. But we were able to boot the AM335x EVM
when UBIFS was flashed from u-boot. The only thing to be taken care of is
that both u-boot and Linux kernel should be following same ECC layout.

Thanks,
Sudhakar

From sakari.ailus at iki.fi  Sun Feb  5 03:13:06 2012
From: sakari.ailus at iki.fi (Sakari Ailus)
Date: Sun, 5 Feb 2012 11:13:06 +0200
Subject: [PATCH v2 2/2] v4l2: add new pixel formats supported on dm365
In-Reply-To: <1327065739-3362-3-git-send-email-manjunath.hadli@ti.com>
References: <1327065739-3362-1-git-send-email-manjunath.hadli@ti.com>
	<1327065739-3362-3-git-send-email-manjunath.hadli@ti.com>
Message-ID: <20120205091306.GC7784@valkosipuli.localdomain>

Hi Manju,

On Fri, Jan 20, 2012 at 06:52:19PM +0530, Manjunath Hadli wrote:
> add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
> to represent Bayer format frames compressed by A-LAW alogorithm,
> add V4L2_PIX_FMT_UV8 to represent storage of C data (UV interleved)
> only.

The patch is finally here:

<URL:http://www.spinics.net/lists/linux-media/msg43890.html>

Cheers,

-- 
Sakari Ailus
e-mail: sakari.ailus at iki.fi	jabber/XMPP/Gmail: sailus at retiisi.org.uk

From snjw23 at gmail.com  Sun Feb  5 14:44:01 2012
From: snjw23 at gmail.com (Sylwester Nawrocki)
Date: Sun, 05 Feb 2012 21:44:01 +0100
Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
In-Reply-To: <20120130201307.GV28397@ponder.secretlab.ca>
References: <1327308967-8092-1-git-send-email-hs@denx.de>
	<1327308967-8092-6-git-send-email-hs@denx.de>
	<4F1DC480.4010603@gmail.com> <4F1E5B44.4090200@denx.de>
	<4F1E7F36.50505@samsung.com>
	<20120130201307.GV28397@ponder.secretlab.ca>
Message-ID: <4F2EEA11.9080807@gmail.com>

Hi Grant,

On 01/30/2012 09:13 PM, Grant Likely wrote:
> The whole 'cell-index' or 'id' thing is a BadIdea(tm).  Don't use it, and tell
> others not to do it when you see it.  There are some legacy uses in powerpc,
> but those were written before I and others knew better.
> 
> The *only* situation where cell-index is acceptable is when the driver
> absolutely must know which hardware instance it is driving because it
> needs to calculate offsets in a shared register or something, and even
> then it should not be used to set the pdev->id field. That situation
> does not look to be the case here.

Thanks a lot for the clarification. Some media device drivers use the pdev->id
field to enumerate hardware entities which are shown to user space libraries/
applications through the media device interface:
<http://linuxtv.org/downloads/v4l-dvb-apis/media-ioc-enum-entities.html>

The entity name is initialized from dev_name(&pdev->dev), which in DT case
will be rather random string AFAICS. Is using 'cell-index' property justified
in such cases ? 
 
> If you're using the DT, then let the core code dynamically assign the
> i2c adapter number.

Then it means that all uses if i2c_get_adapter() that take an I2C adapter 
number as an argument need to be converted accordingly, e.g. we need an OF
version of i2c_get_adapter() ?

The V4L core provides v4l2_i2c_new_subdev_board() function which is used
by the video bridge drivers to register its sub-devices - I2C clients 
(usually image sensors or video encoders). The I2C bus ids are usually 
provided as platform data to the bridge driver. Sounds like all this will
need to be reworked quite significantly for DT support.

---

Thanks,
Sylwester

From hs at denx.de  Mon Feb  6 00:36:11 2012
From: hs at denx.de (Heiko Schocher)
Date: Mon, 06 Feb 2012 07:36:11 +0100
Subject: [RFC PATCH 1/7] ARM: davinci,
	intc: Add OF support for TI interrupt controller
In-Reply-To: <20120202045459.GI15343@ponder.secretlab.ca>
References: <1327308967-8092-1-git-send-email-hs@denx.de>
	<1327308967-8092-2-git-send-email-hs@denx.de>
	<20120202045459.GI15343@ponder.secretlab.ca>
Message-ID: <4F2F74DB.7010604@denx.de>

Hello Grant,

Grant Likely wrote:
> On Mon, Jan 23, 2012 at 09:56:01AM +0100, Heiko Schocher wrote:
>> Add a function to initialize the davinci interrupt controller (INTC)
>> using a device tree node.
>>
>> Signed-off-by: Heiko Schocher <hs at denx.de>
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree-discuss at lists.ozlabs.org
>> Cc: Grant Likely <grant.likely at secretlab.ca>
>> Cc: Sekhar Nori <nsekhar at ti.com>
>> Cc: Wolfgang Denk <wd at denx.de>
>> ---
>>  .../devicetree/bindings/arm/davinci/intc.txt       |   26 ++++++++++
>>  arch/arm/mach-davinci/cp_intc.c                    |   51 ++++++++++++++++++++
>>  arch/arm/mach-davinci/include/mach/cp_intc.h       |    1 +
>>  3 files changed, 78 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt
[...]
>> diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
>> index f83152d..2c6e2e4 100644
>> --- a/arch/arm/mach-davinci/cp_intc.c
>> +++ b/arch/arm/mach-davinci/cp_intc.c
[...]
>> +	cp_intc_init();
>> +	irq_domain_add_simple(node, 0);
> 
> Take a look at the irq_domain patches that will be (probably) merged
> in v3.4.  Instead of calling irq_domain_add_simple(), you should
> migrate the whole interrupt controller to natively use an irq_domain
> for hwirq <--> irq mapping.

I rebased my hole patchset to:

git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
and reworked the arch/arm/mach-davinci/cp_intc.c irq driver to use
irq_domain, works good on the enbw_cmc board :-)

Waiting for your comment to my question to the
[RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
patch, see:
http://www.mail-archive.com/linux-i2c at vger.kernel.org/msg07132.html

and resend the hole reworked patchserie. Is it OK, if I use the above
branch as base for sending this patchserie, or should I use another
tree/branch for it?

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

From manjunath.hadli at ti.com  Mon Feb  6 01:24:52 2012
From: manjunath.hadli at ti.com (Hadli, Manjunath)
Date: Mon, 6 Feb 2012 07:24:52 +0000
Subject: [GIT PULL] davinci vpif pull request
In-Reply-To: <E99FAA59F8D8D34D8A118DD37F7C8F7531744F4D@DBDE01.ent.ti.com>
References: <E99FAA59F8D8D34D8A118DD37F7C8F7531744F4D@DBDE01.ent.ti.com>
Message-ID: <E99FAA59F8D8D34D8A118DD37F7C8F753174D7F6@DBDE01.ent.ti.com>

Mauro,
 A gentle reminder for the pull request.

Cheers,
-Manju

On Fri, Jan 27, 2012 at 15:43:00, Hadli, Manjunath wrote:
> Hi Mauro,
>  Can you please pull the following patch for v3.3-rc1 which removes some unnecessary inclusion  of machine specific header files from the main driver files?
> 
>  This patch has undergone sufficient review already. It is just a cleanup patch and I don't  expect any functionality to break because of this. 
> 
>  Thanks and Regards,
> -Manju
> 
> 
> The following changes since commit 74ea15d909b31158f9b63190a95b52bc05586d4b:
>   Linus Torvalds (1):
>         Merge branch 'v4l_for_linus' of git://git.kernel.org/.../mchehab/linux-media
> 
> 
> are available in the git repository at:
> 
> 
>   git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3
> 
> Manjunath Hadli (1):
>       davinci: vpif: remove machine specific header file inclusion from the driver
> 
> 
>  drivers/media/video/davinci/vpif.h         |    2 --
>  drivers/media/video/davinci/vpif_display.c |    2 --
>  include/media/davinci/vpif_types.h         |    2 ++
>  3 files changed, 2 insertions(+), 4 deletions(-)
> 


From prabhakar.csengg at gmail.com  Tue Feb  7 01:09:30 2012
From: prabhakar.csengg at gmail.com (Prabhakar Lad)
Date: Tue, 7 Feb 2012 12:39:30 +0530
Subject: videobuf2 porting
Message-ID: <CA+V-a8smpQMNTHDGuX6+P=MXCJFcjH25e1yVoZ9aG6mAytvyTQ@mail.gmail.com>

Hi folks,

I was trying to port a existing driver to videobuf2 framework, I had a
hurdle in between
the driver I was trying to port supports user pointer, How does videobuf2
support this
thing ?

Regards,
--Prabhakar Lad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20120207/46ccc3bd/attachment.html>

From manjunath.hadli at ti.com  Tue Feb  7 04:05:12 2012
From: manjunath.hadli at ti.com (Manjunath Hadli)
Date: Tue, 7 Feb 2012 15:35:12 +0530
Subject: [PATCH v3 0/2] add dm365 specific media formats
Message-ID: <1328609114-5487-1-git-send-email-manjunath.hadli@ti.com>

add mediabus formats and pixel formats supported
as part of dm365 vpfe device.
The device supports media formats(transfer and storage)
which include-
1: ALAW compressed bayer.
2: UV interleaved without Y (for resizer).
3: YDYC.

Changes for v3:
1: Added 4cc code for A-law compressed format as per
   specified in documentation,
   http://www.spinics.net/lists/linux-media/msg43890.html

Changes for v2:
1: Added entries in subdev-formats.xml for
  V4L2_MBUS_FMT_YDYC8_1X16, V4L2_MBUS_FMT_UV8_1X8,
  V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8,
  V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8,
  V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8,
  V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8.
2: Added documentation of ALAW and UV8 pix format.

Manjunath Hadli (2):
  media: add new mediabus format enums for dm365
  v4l2: add new pixel formats supported on dm365

 .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml      |   34 ++++
 Documentation/DocBook/media/v4l/pixfmt-uv8.xml     |   62 +++++++
 Documentation/DocBook/media/v4l/pixfmt.xml         |    2 +
 Documentation/DocBook/media/v4l/subdev-formats.xml |  171 ++++++++++++++++++++
 include/linux/v4l2-mediabus.h                      |   10 +-
 include/linux/videodev2.h                          |    9 +
 6 files changed, 286 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml


From manjunath.hadli at ti.com  Tue Feb  7 04:05:13 2012
From: manjunath.hadli at ti.com (Manjunath Hadli)
Date: Tue, 7 Feb 2012 15:35:13 +0530
Subject: [PATCH v3 1/2] media: add new mediabus format enums for dm365
In-Reply-To: <1328609114-5487-1-git-send-email-manjunath.hadli@ti.com>
References: <1328609114-5487-1-git-send-email-manjunath.hadli@ti.com>
Message-ID: <1328609114-5487-2-git-send-email-manjunath.hadli@ti.com>

add new enum entries for supporting the media-bus formats on dm365.
These include some bayer and some non-bayer formats.
V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used
internal to the hardware by the resizer.
V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format
that is supported by dm365 hardware.

Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>
Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 Documentation/DocBook/media/v4l/subdev-formats.xml |  171 ++++++++++++++++++++
 include/linux/v4l2-mediabus.h                      |   10 +-
 2 files changed, 179 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 49c532e..48d92bb 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -356,6 +356,9 @@
 	<listitem><para>If the pixel components are DPCM-compressed, a mention of the
 	DPCM compression and the number of bits per compressed pixel component.</para>
 	</listitem>
+	<listitem><para>If the pixel components are ALAW-compressed, a mention of the
+	ALAW compression and the number of bits per compressed pixel component.</para>
+	</listitem>
 	<listitem><para>The number of bus samples per pixel. Pixels that are wider than
 	the bus width must be transferred in multiple samples. Common values are
 	1 and 2.</para></listitem>
@@ -572,6 +575,74 @@
 	      <entry>r<subscript>1</subscript></entry>
 	      <entry>r<subscript>0</subscript></entry>
 	    </row>
+	    <row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8">
+	      <entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry>
+	      <entry>0x3015</entry>
+	      <entry></entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>b<subscript>7</subscript></entry>
+	      <entry>b<subscript>6</subscript></entry>
+	      <entry>b<subscript>5</subscript></entry>
+	      <entry>b<subscript>4</subscript></entry>
+	      <entry>b<subscript>3</subscript></entry>
+	      <entry>b<subscript>2</subscript></entry>
+	      <entry>b<subscript>1</subscript></entry>
+	      <entry>b<subscript>0</subscript></entry>
+	    </row>
+	    <row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8">
+	      <entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry>
+	      <entry>0x3016</entry>
+	      <entry></entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>g<subscript>7</subscript></entry>
+	      <entry>g<subscript>6</subscript></entry>
+	      <entry>g<subscript>5</subscript></entry>
+	      <entry>g<subscript>4</subscript></entry>
+	      <entry>g<subscript>3</subscript></entry>
+	      <entry>g<subscript>2</subscript></entry>
+	      <entry>g<subscript>1</subscript></entry>
+	      <entry>g<subscript>0</subscript></entry>
+	    </row>
+	    <row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8">
+	      <entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry>
+	      <entry>0x3017</entry>
+	      <entry></entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>g<subscript>7</subscript></entry>
+	      <entry>g<subscript>6</subscript></entry>
+	      <entry>g<subscript>5</subscript></entry>
+	      <entry>g<subscript>4</subscript></entry>
+	      <entry>g<subscript>3</subscript></entry>
+	      <entry>g<subscript>2</subscript></entry>
+	      <entry>g<subscript>1</subscript></entry>
+	      <entry>g<subscript>0</subscript></entry>
+	    </row>
+	    <row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8">
+	      <entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry>
+	      <entry>0x3018</entry>
+	      <entry></entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>r<subscript>7</subscript></entry>
+	      <entry>r<subscript>6</subscript></entry>
+	      <entry>r<subscript>5</subscript></entry>
+	      <entry>r<subscript>4</subscript></entry>
+	      <entry>r<subscript>3</subscript></entry>
+	      <entry>r<subscript>2</subscript></entry>
+	      <entry>r<subscript>1</subscript></entry>
+	      <entry>r<subscript>0</subscript></entry>
+	    </row>
 	    <row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADHI-BE">
 	      <entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE</entry>
 	      <entry>0x3003</entry>
@@ -965,6 +1036,56 @@
 	      <entry>y<subscript>1</subscript></entry>
 	      <entry>y<subscript>0</subscript></entry>
 	    </row>
+	    <row id="V4L2-MBUS-FMT-UV8-1X8">
+	      <entry>V4L2_MBUS_FMT_UV8_1X8</entry>
+	      <entry>0x2015</entry>
+	      <entry></entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>u<subscript>7</subscript></entry>
+	      <entry>u<subscript>6</subscript></entry>
+	      <entry>u<subscript>5</subscript></entry>
+	      <entry>u<subscript>4</subscript></entry>
+	      <entry>u<subscript>3</subscript></entry>
+	      <entry>u<subscript>2</subscript></entry>
+	      <entry>u<subscript>1</subscript></entry>
+	      <entry>u<subscript>0</subscript></entry>
+	    </row>
+	    <row>
+	      <entry></entry>
+	      <entry></entry>
+	      <entry></entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>v<subscript>7</subscript></entry>
+	      <entry>v<subscript>6</subscript></entry>
+	      <entry>v<subscript>5</subscript></entry>
+	      <entry>v<subscript>4</subscript></entry>
+	      <entry>v<subscript>3</subscript></entry>
+	      <entry>v<subscript>2</subscript></entry>
+	      <entry>v<subscript>1</subscript></entry>
+	      <entry>v<subscript>0</subscript></entry>
+	    </row>
 	    <row id="V4L2-MBUS-FMT-UYVY8-1_5X8">
 	      <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry>
 	      <entry>0x2002</entry>
@@ -2415,6 +2536,56 @@
 	      <entry>u<subscript>1</subscript></entry>
 	      <entry>u<subscript>0</subscript></entry>
 	    </row>
+	    <row id="V4L2-MBUS-FMT-YDYC8-1X16">
+	      <entry>V4L2_MBUS_FMT_YDYC8_1X16</entry>
+	      <entry>0x2014</entry>
+	      <entry></entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>y<subscript>7</subscript></entry>
+	      <entry>y<subscript>6</subscript></entry>
+	      <entry>y<subscript>5</subscript></entry>
+	      <entry>y<subscript>4</subscript></entry>
+	      <entry>y<subscript>3</subscript></entry>
+	      <entry>y<subscript>2</subscript></entry>
+	      <entry>y<subscript>1</subscript></entry>
+	      <entry>y<subscript>0</subscript></entry>
+	      <entry>d<subscript>7</subscript></entry>
+	      <entry>d<subscript>6</subscript></entry>
+	      <entry>d<subscript>5</subscript></entry>
+	      <entry>d<subscript>4</subscript></entry>
+	      <entry>d<subscript>3</subscript></entry>
+	      <entry>d<subscript>2</subscript></entry>
+	      <entry>d<subscript>1</subscript></entry>
+	      <entry>d<subscript>0</subscript></entry>
+	    </row>
+	    <row>
+	      <entry></entry>
+	      <entry></entry>
+	      <entry></entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>-</entry>
+	      <entry>y<subscript>7</subscript></entry>
+	      <entry>y<subscript>6</subscript></entry>
+	      <entry>y<subscript>5</subscript></entry>
+	      <entry>y<subscript>4</subscript></entry>
+	      <entry>y<subscript>3</subscript></entry>
+	      <entry>y<subscript>2</subscript></entry>
+	      <entry>y<subscript>1</subscript></entry>
+	      <entry>y<subscript>0</subscript></entry>
+	      <entry>c<subscript>7</subscript></entry>
+	      <entry>c<subscript>6</subscript></entry>
+	      <entry>c<subscript>5</subscript></entry>
+	      <entry>c<subscript>4</subscript></entry>
+	      <entry>c<subscript>3</subscript></entry>
+	      <entry>c<subscript>2</subscript></entry>
+	      <entry>c<subscript>1</subscript></entry>
+	      <entry>c<subscript>0</subscript></entry>
+	    </row>
 	    <row id="V4L2-MBUS-FMT-YUYV10-1X20">
 	      <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry>
 	      <entry>0x200d</entry>
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..8d68fa1 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -47,8 +47,9 @@ enum v4l2_mbus_pixelcode {
 	V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
 	V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
 
-	/* YUV (including grey) - next is 0x2014 */
+	/* YUV (including grey) - next is 0x2016 */
 	V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
+	V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
 	V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
 	V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
 	V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
@@ -65,10 +66,11 @@ enum v4l2_mbus_pixelcode {
 	V4L2_MBUS_FMT_VYUY8_1X16 = 0x2010,
 	V4L2_MBUS_FMT_YUYV8_1X16 = 0x2011,
 	V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
+	V4L2_MBUS_FMT_YDYC8_1X16 = 0x2014,
 	V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
 	V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
 
-	/* Bayer - next is 0x3015 */
+	/* Bayer - next is 0x3019 */
 	V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
 	V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
 	V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
@@ -77,6 +79,10 @@ enum v4l2_mbus_pixelcode {
 	V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c,
 	V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
 	V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 = 0x300d,
+	V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
+	V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
+	V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
+	V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
 	V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003,
 	V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004,
 	V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005,
-- 
1.6.2.4


From manjunath.hadli at ti.com  Tue Feb  7 04:05:14 2012
From: manjunath.hadli at ti.com (Manjunath Hadli)
Date: Tue, 7 Feb 2012 15:35:14 +0530
Subject: [PATCH v3 2/2] v4l2: add new pixel formats supported on dm365
In-Reply-To: <1328609114-5487-1-git-send-email-manjunath.hadli@ti.com>
References: <1328609114-5487-1-git-send-email-manjunath.hadli@ti.com>
Message-ID: <1328609114-5487-3-git-send-email-manjunath.hadli@ti.com>

add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
to represent Bayer format frames compressed by A-LAW algorithm,
add V4L2_PIX_FMT_UV8 to represent storage of C data (UV interleaved)
only.

Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>
Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml      |   34 +++++++++++
 Documentation/DocBook/media/v4l/pixfmt-uv8.xml     |   62 ++++++++++++++++++++
 Documentation/DocBook/media/v4l/pixfmt.xml         |    2 +
 include/linux/videodev2.h                          |    9 +++
 4 files changed, 107 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml

diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
new file mode 100644
index 0000000..b20f525
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+	<refentry>
+	  <refmeta>
+	    <refentrytitle>
+	      V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
+	      V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
+	      V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
+	      V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
+	    </refentrytitle>
+	    &manvol;
+	  </refmeta>
+	  <refnamediv>
+	    <refname id="V4L2-PIX-FMT-SRGGB10ALAW8">
+	      <constant>V4L2_PIX_FMT_SRGGB10ALAW8</constant>
+	    </refname>
+	    <refname id="V4L2-PIX-FMT-SGRBG10ALAW8">
+	      <constant>V4L2_PIX_FMT_SGRBG10ALAW8</constant>
+	    </refname>
+	    <refname id="V4L2-PIX-FMT-SGBRG10ALAW8">
+	      <constant>V4L2_PIX_FMT_SGBRG10ALAW8</constant>
+	    </refname>
+	    <refname id="V4L2-PIX-FMT-SBGGR10ALAW8">
+	      <constant>V4L2_PIX_FMT_SBGGR10ALAW8</constant>
+	    </refname>
+	    <refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose>
+	  </refnamediv>
+	  <refsect1>
+	    <title>Description</title>
+	    <para>The following four pixel formats are raw sRGB / Bayer
+	    formats with 10 bits per colour compressed to 8 bits each,
+	    using the A-LAW algorithm. Each colour component consumes 8
+	    bits of memory. In other respects this format is similar to
+	    <xref linkend="V4L2-PIX-FMT-SRGGB8">.</xref></para>
+	  </refsect1>
+	</refentry>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
new file mode 100644
index 0000000..e3e6b11
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
@@ -0,0 +1,62 @@
+	<refentry id="V4L2-PIX-FMT-UV8">
+	  <refmeta>
+	    <refentrytitle>V4L2_PIX_FMT_UV8  ('UV8')</refentrytitle>
+	    &manvol;
+	  </refmeta>
+	  <refnamediv>
+	    <refname><constant>V4L2_PIX_FMT_UV8</constant></refname>
+	    <refpurpose>UV plane interleaved</refpurpose>
+	  </refnamediv>
+	  <refsect1>
+	    <title>Description</title>
+	    <para>In this format there is no Y plane, Only C plane. ie
+	    (UV interleaved)</para>
+	    <example>
+	    <title>
+	      <constant>V4L2_PIX_FMT_UV8</constant>
+	       pixel image
+	    </title>
+
+	    <formalpara>
+	      <title>Byte Order.</title>
+	      <para>Each cell is one byte.
+	        <informaltable frame="none">
+	        <tgroup cols="5" align="center">
+		  <colspec align="left" colwidth="2*" />
+		  <tbody valign="top">
+		    <row>
+		      <entry>start&nbsp;+&nbsp;0:</entry>
+		      <entry>Cb<subscript>00</subscript></entry>
+		      <entry>Cr<subscript>00</subscript></entry>
+		      <entry>Cb<subscript>01</subscript></entry>
+		      <entry>Cr<subscript>01</subscript></entry>
+		    </row>
+		    <row>
+		      <entry>start&nbsp;+&nbsp;4:</entry>
+		      <entry>Cb<subscript>10</subscript></entry>
+		      <entry>Cr<subscript>10</subscript></entry>
+		      <entry>Cb<subscript>11</subscript></entry>
+		      <entry>Cr<subscript>11</subscript></entry>
+		    </row>
+		    <row>
+		      <entry>start&nbsp;+&nbsp;8:</entry>
+		      <entry>Cb<subscript>20</subscript></entry>
+		      <entry>Cr<subscript>20</subscript></entry>
+		      <entry>Cb<subscript>21</subscript></entry>
+		      <entry>Cr<subscript>21</subscript></entry>
+		    </row>
+		    <row>
+		      <entry>start&nbsp;+&nbsp;12:</entry>
+		      <entry>Cb<subscript>30</subscript></entry>
+		      <entry>Cr<subscript>30</subscript></entry>
+		      <entry>Cb<subscript>31</subscript></entry>
+		      <entry>Cr<subscript>31</subscript></entry>
+		    </row>
+		  </tbody>
+		</tgroup>
+		</informaltable>
+	      </para>
+	      </formalpara>
+	    </example>
+	  </refsect1>
+	</refentry>
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml
index 9ddc57c..0b62750 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
     &sub-srggb8;
     &sub-sbggr16;
     &sub-srggb10;
+    &sub-srggb10alaw8;
     &sub-srggb12;
   </section>
 
@@ -696,6 +697,7 @@ information.</para>
 
     &sub-packed-yuv;
     &sub-grey;
+    &sub-uv8;
     &sub-y10;
     &sub-y12;
     &sub-y10b;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 012a296..8e6b3f2 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -338,6 +338,9 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_HM12    v4l2_fourcc('H', 'M', '1', '2') /*  8  YUV 4:2:0 16x16 macroblocks */
 #define V4L2_PIX_FMT_M420    v4l2_fourcc('M', '4', '2', '0') /* 12  YUV 4:2:0 2 lines y, 1 line uv interleaved */
 
+/* Chrominance formats */
+#define V4L2_PIX_FMT_UV8      v4l2_fourcc('U', 'V', '8', ' ') /*  8  UV 4:4 */
+
 /* two planes -- one Y, one Cr + Cb interleaved  */
 #define V4L2_PIX_FMT_NV12    v4l2_fourcc('N', 'V', '1', '2') /* 12  Y/CbCr 4:2:0  */
 #define V4L2_PIX_FMT_NV21    v4l2_fourcc('N', 'V', '2', '1') /* 12  Y/CrCb 4:2:0  */
@@ -366,6 +369,12 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG.. GBGB.. */
 	/* 10bit raw bayer DPCM compressed to 8 bits */
 #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
+	/* 10bit raw bayer a-law compressed to 8 bits */
+#define V4L2_PIX_FMT_SBGGR10ALAW8 v4l2_fourcc('a', 'B', 'A', '8')
+#define V4L2_PIX_FMT_SGBRG10ALAW8 v4l2_fourcc('a', 'G', 'A', '8')
+#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('a', 'g', 'A', '8')
+#define V4L2_PIX_FMT_SRGGB10ALAW8 v4l2_fourcc('a', 'R', 'A', '8')
+
 	/*
 	 * 10bit raw bayer, expanded to 16 bits
 	 * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb...
-- 
1.6.2.4


From prakash.pm at ti.com  Tue Feb  7 09:11:50 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 7 Feb 2012 20:41:50 +0530
Subject: [PATCH v3 0/3] Moving EMIF driver to MFD framework
Message-ID: <1328627513-30134-1-git-send-email-prakash.pm@ti.com>

Patch series are based on the discussion and concerns expressed in
davinci-linux-open-source community. Here is the link for the same:
http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-tt7059739.html#none

Manjunathappa, Prakash (3):
  arm:davinci: prepare to move aemif driver to drivers/mfd
  arm:davinci: Move emif driver to drivers/mfd from mach-davinci folder
  arm:davinci: move NAND and NOR devices as aemif MFD slaves

 arch/arm/Kconfig                                   |    1 +
 arch/arm/mach-davinci/Makefile                     |    2 +-
 arch/arm/mach-davinci/aemif.c                      |  133 -------------
 arch/arm/mach-davinci/board-da830-evm.c            |   33 +++-
 arch/arm/mach-davinci/board-da850-evm.c            |   56 +++---
 arch/arm/mach-davinci/board-dm355-evm.c            |   33 +++-
 arch/arm/mach-davinci/board-dm355-leopard.c        |   35 +++-
 arch/arm/mach-davinci/board-dm365-evm.c            |   34 +++-
 arch/arm/mach-davinci/board-dm644x-evm.c           |  175 ++++++++++-------
 arch/arm/mach-davinci/board-dm646x-evm.c           |   32 +++-
 arch/arm/mach-davinci/board-mityomapl138.c         |   34 +++-
 arch/arm/mach-davinci/board-neuros-osd2.c          |    1 +
 arch/arm/mach-davinci/board-sffsdr.c               |   34 +++-
 drivers/mfd/Makefile                               |    1 +
 drivers/mfd/davinci_aemif.c                        |  206 ++++++++++++++++++++
 drivers/mtd/nand/davinci_nand.c                    |    2 +-
 .../aemif.h => include/linux/mfd/davinci_aemif.h   |   14 ++
 17 files changed, 527 insertions(+), 299 deletions(-)
 delete mode 100644 arch/arm/mach-davinci/aemif.c
 create mode 100644 drivers/mfd/davinci_aemif.c
 rename arch/arm/mach-davinci/include/mach/aemif.h => include/linux/mfd/davinci_aemif.h (74%)


From prakash.pm at ti.com  Tue Feb  7 09:11:51 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 7 Feb 2012 20:41:51 +0530
Subject: [PATCH v3 1/3] arm:davinci: prepare to move aemif driver to
	drivers/mfd
In-Reply-To: <1328627513-30134-1-git-send-email-prakash.pm@ti.com>
References: <1328627513-30134-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1328627513-30134-2-git-send-email-prakash.pm@ti.com>

Patch moves emif header file appropriately as a part preparation to move emif
driver from arch/arm/mach-davinci/ to drivers/mfd folder.
There by it isolates modifications in emif interface depicting as platform code
change.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v2:
No change
Since v1:
Patch generated using -M option.

 arch/arm/mach-davinci/aemif.c                      |    2 +-
 arch/arm/mach-davinci/board-da830-evm.c            |    2 +-
 arch/arm/mach-davinci/board-da850-evm.c            |    2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c           |    2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c           |    2 +-
 drivers/mtd/nand/davinci_nand.c                    |    2 +-
 .../aemif.h => include/linux/mfd/davinci_aemif.h   |    0
 7 files changed, 6 insertions(+), 6 deletions(-)
 rename arch/arm/mach-davinci/include/mach/aemif.h => include/linux/mfd/davinci_aemif.h (100%)

diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
index 1ce70a9..b67c115 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/arch/arm/mach-davinci/aemif.c
@@ -15,7 +15,7 @@
 #include <linux/module.h>
 #include <linux/time.h>
 
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 /* Timing value configuration */
 
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index dc1afe5..0b43554 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -31,7 +31,7 @@
 #include <mach/nand.h>
 #include <mach/da8xx.h>
 #include <mach/usb.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 #include <mach/spi.h>
 
 #define DA830_EVM_PHY_ID		""
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index d508890..9f2a544 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -41,7 +41,7 @@
 #include <mach/da8xx.h>
 #include <mach/nand.h>
 #include <mach/mux.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 #include <mach/spi.h>
 
 #define DA850_EVM_PHY_ID		"davinci_mdio-0:00"
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 1247ecd..99a6639 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -38,7 +38,7 @@
 #include <mach/nand.h>
 #include <mach/mmc.h>
 #include <mach/usb.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #define DM644X_EVM_PHY_ID		"davinci_mdio-0:01"
 #define LXT971_PHY_ID	(0x001378e2)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 872ac69..af55a9d 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -43,7 +43,7 @@
 #include <mach/nand.h>
 #include <mach/clock.h>
 #include <mach/cdce949.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include "clock.h"
 
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 6e56615..f19151b 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -35,7 +35,7 @@
 #include <linux/slab.h>
 
 #include <mach/nand.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 /*
  * This is a device driver for the NAND flash controller found on the
diff --git a/arch/arm/mach-davinci/include/mach/aemif.h b/include/linux/mfd/davinci_aemif.h
similarity index 100%
rename from arch/arm/mach-davinci/include/mach/aemif.h
rename to include/linux/mfd/davinci_aemif.h
-- 
1.7.1


From prakash.pm at ti.com  Tue Feb  7 09:11:52 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 7 Feb 2012 20:41:52 +0530
Subject: [PATCH v3 2/3] arm:davinci: Move emif driver to drivers/mfd from
	mach-davinci folder
In-Reply-To: <1328627513-30134-1-git-send-email-prakash.pm@ti.com>
References: <1328627513-30134-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1328627513-30134-3-git-send-email-prakash.pm@ti.com>

Move aemif kernel module from arch/arm/mach-davinci/ to multi functional
devices frame work. "davinci_aemif" MFD driver adds "davinci_nand" and
"physmap-flash" slave devices.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v2:
Modified emif MFD driver to load multiple instance of NAND/NOR devices.
Since v1:
Patch generated using -M option.

 arch/arm/Kconfig                                   |    1 +
 arch/arm/mach-davinci/Makefile                     |    2 +-
 drivers/mfd/Makefile                               |    1 +
 .../aemif.c => drivers/mfd/davinci_aemif.c         |   75 +++++++++++++++++++-
 include/linux/mfd/davinci_aemif.h                  |   14 ++++
 5 files changed, 91 insertions(+), 2 deletions(-)
 rename arch/arm/mach-davinci/aemif.c => drivers/mfd/davinci_aemif.c (66%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a48aecc..09dcb94 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -934,6 +934,7 @@ config ARCH_DAVINCI
 	select GENERIC_ALLOCATOR
 	select GENERIC_IRQ_CHIP
 	select ARCH_HAS_HOLES_MEMORYMODEL
+	select MFD_CORE
 	help
 	  Support for TI's DaVinci platform.
 
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 2db78bd..8bab47c 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
 
 # Common objects
 obj-y 			:= time.o clock.o serial.o psc.o \
-			   dma.o usb.o common.o sram.o aemif.o
+			   dma.o usb.o common.o sram.o
 
 obj-$(CONFIG_DAVINCI_MUX)		+= mux.o
 
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b953bab..54fc267 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_HTC_EGPIO)		+= htc-egpio.o
 obj-$(CONFIG_HTC_PASIC3)	+= htc-pasic3.o
 obj-$(CONFIG_HTC_I2CPLD)	+= htc-i2cpld.o
 
+obj-${CONFIG_ARCH_DAVINCI}	+= davinci_aemif.o
 obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)	+= davinci_voicecodec.o
 obj-$(CONFIG_MFD_DM355EVM_MSP)	+= dm355evm_msp.o
 obj-$(CONFIG_MFD_TI_SSP)	+= ti-ssp.o
diff --git a/arch/arm/mach-davinci/aemif.c b/drivers/mfd/davinci_aemif.c
similarity index 66%
rename from arch/arm/mach-davinci/aemif.c
rename to drivers/mfd/davinci_aemif.c
index b67c115..5fb490d 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/drivers/mfd/davinci_aemif.c
@@ -14,8 +14,13 @@
 #include <linux/clk.h>
 #include <linux/module.h>
 #include <linux/time.h>
-
 #include <linux/mfd/davinci_aemif.h>
+#include <linux/mtd/physmap.h>
+#include <linux/slab.h>
+#include <mach/nand.h>
+
+static char *name[] = {"davinci_nand", "physmap-flash",};
+#define MAX ARRAY_SIZE(name)
 
 /* Timing value configuration */
 
@@ -131,3 +136,71 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
 	return 0;
 }
 EXPORT_SYMBOL(davinci_aemif_setup_timing);
+
+static int __init davinci_aemif_probe(struct platform_device *pdev)
+{
+	struct davinci_aemif_devices *davinci_aemif_devices =
+		pdev->dev.platform_data;
+	struct platform_device *devices;
+	struct mfd_cell *cells;
+	int ret, i, j, count;
+
+	devices = davinci_aemif_devices->devices;
+
+	cells = kzalloc(sizeof(struct mfd_cell) *
+			davinci_aemif_devices->num_devices, GFP_KERNEL);
+
+	for (j = 0, count = 0; j < MAX; j++) {
+		for (i = 0; i < davinci_aemif_devices->num_devices; i++) {
+			if (strcmp(devices[i].name, name[j]))
+				continue;
+			cells[count].name = name[j];
+			cells[count].platform_data =
+				devices[i].dev.platform_data;
+			cells[count].pdata_size =
+				sizeof(struct davinci_nand_pdata);
+			cells[count].id = devices[i].id;
+			cells[count].resources = devices[i].resource;
+			cells[count].num_resources = devices[i].num_resources;
+			count++;
+		}
+	}
+
+	ret = mfd_add_devices(&pdev->dev, 0, cells,
+			      count, NULL, 0);
+	if (ret != 0)
+		dev_err(&pdev->dev, "fail to register client devices\n");
+
+	return 0;
+}
+
+static int __devexit davinci_aemif_remove(struct platform_device *pdev)
+{
+	mfd_remove_devices(&pdev->dev);
+	return 0;
+}
+
+static struct platform_driver davinci_aemif_driver = {
+	.driver	= {
+		.name = "davinci_aemif",
+		.owner = THIS_MODULE,
+	},
+	.remove	= __devexit_p(davinci_aemif_remove),
+};
+
+static int __init davinci_aemif_init(void)
+{
+	return platform_driver_probe(&davinci_aemif_driver,
+			davinci_aemif_probe);
+}
+module_init(davinci_aemif_init);
+
+static void __exit davinci_aemif_exit(void)
+{
+	platform_driver_unregister(&davinci_aemif_driver);
+}
+module_exit(davinci_aemif_exit);
+
+MODULE_AUTHOR("Prakash Manjunathappa");
+MODULE_DESCRIPTION("Texas Instruments AEMIF Interface");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/davinci_aemif.h b/include/linux/mfd/davinci_aemif.h
index 05b2934..18650c3 100644
--- a/include/linux/mfd/davinci_aemif.h
+++ b/include/linux/mfd/davinci_aemif.h
@@ -10,6 +10,10 @@
 #ifndef _MACH_DAVINCI_AEMIF_H
 #define _MACH_DAVINCI_AEMIF_H
 
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/core.h>
+
 #define NRCSR_OFFSET		0x00
 #define AWCCR_OFFSET		0x04
 #define A1CR_OFFSET		0x10
@@ -18,6 +22,16 @@
 #define ACR_EW_MASK		BIT(30)
 #define ACR_SS_MASK		BIT(31)
 
+enum davinci_emif_cells {
+	DAVINCI_NAND_DEVICE_CELL,
+	DAVINCI_NOR_FLASH_CELL,
+};
+
+struct davinci_aemif_devices {
+	struct platform_device *devices;
+	unsigned int num_devices;
+};
+
 /* All timings in nanoseconds */
 struct davinci_aemif_timing {
 	u8	wsetup;
-- 
1.7.1


From prakash.pm at ti.com  Tue Feb  7 09:11:53 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 7 Feb 2012 20:41:53 +0530
Subject: [PATCH v3 3/3] arm:davinci: move NAND and NOR devices as aemif MFD
	slaves
In-Reply-To: <1328627513-30134-1-git-send-email-prakash.pm@ti.com>
References: <1328627513-30134-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1328627513-30134-4-git-send-email-prakash.pm@ti.com>

NAND and NOR device are made as aemif device slaves, hence all DaVinci
board NAND/NOR device registration achieved via aemif MFD driver.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v2:
Make changes for all DaVinci boards in single patch.
Since v1:
Patch generated using -M option.

 arch/arm/mach-davinci/board-da830-evm.c     |   31 ++++--
 arch/arm/mach-davinci/board-da850-evm.c     |   54 +++++----
 arch/arm/mach-davinci/board-dm355-evm.c     |   33 ++++--
 arch/arm/mach-davinci/board-dm355-leopard.c |   35 ++++--
 arch/arm/mach-davinci/board-dm365-evm.c     |   34 ++++--
 arch/arm/mach-davinci/board-dm644x-evm.c    |  173 +++++++++++++++------------
 arch/arm/mach-davinci/board-dm646x-evm.c    |   30 ++++--
 arch/arm/mach-davinci/board-mityomapl138.c  |   34 ++++--
 arch/arm/mach-davinci/board-neuros-osd2.c   |    1 +
 arch/arm/mach-davinci/board-sffsdr.c        |   34 ++++--
 10 files changed, 299 insertions(+), 160 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 0b43554..0ad3662 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -396,14 +396,29 @@ static struct resource da830_evm_nand_resources[] = {
 	},
 };
 
-static struct platform_device da830_evm_nand_device = {
-	.name		= "davinci_nand",
-	.id		= 1,
-	.dev		= {
-		.platform_data	= &da830_evm_nand_pdata,
+static struct platform_device da830_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 1,
+		.dev		= {
+			.platform_data	= &da830_evm_nand_pdata,
+		},
+		.num_resources	= ARRAY_SIZE(da830_evm_nand_resources),
+		.resource	= da830_evm_nand_resources,
+	},
+};
+
+static struct davinci_aemif_devices da830_emif_devices = {
+	.devices	= da830_evm_devices,
+	.num_devices	= ARRAY_SIZE(da830_evm_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &da830_emif_devices,
 	},
-	.num_resources	= ARRAY_SIZE(da830_evm_nand_resources),
-	.resource	= da830_evm_nand_resources,
 };
 
 static inline void da830_evm_init_nand(int mux_mode)
@@ -422,7 +437,7 @@ static inline void da830_evm_init_nand(int mux_mode)
 		pr_warning("da830_evm_init: emif25 mux setup failed: %d\n",
 				ret);
 
-	ret = platform_device_register(&da830_evm_nand_device);
+	ret = platform_device_register(&davinci_emif_device);
 	if (ret)
 		pr_warning("da830_evm_init: NAND device not registered.\n");
 
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 9f2a544..49ab16d 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -181,16 +181,6 @@ static struct resource da850_evm_norflash_resource[] = {
 	},
 };
 
-static struct platform_device da850_evm_norflash_device = {
-	.name		= "physmap-flash",
-	.id		= 0,
-	.dev		= {
-		.platform_data  = &da850_evm_norflash_data,
-	},
-	.num_resources	= 1,
-	.resource	= da850_evm_norflash_resource,
-};
-
 static struct davinci_pm_config da850_pm_pdata = {
 	.sleepcount = 128,
 };
@@ -273,19 +263,39 @@ static struct resource da850_evm_nandflash_resource[] = {
 	},
 };
 
-static struct platform_device da850_evm_nandflash_device = {
-	.name		= "davinci_nand",
-	.id		= 1,
-	.dev		= {
-		.platform_data	= &da850_evm_nandflash_data,
+static struct platform_device da850_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 1,
+		.dev		= {
+			.platform_data	= &da850_evm_nandflash_data,
+		},
+		.num_resources	= ARRAY_SIZE(da850_evm_nandflash_resource),
+		.resource	= da850_evm_nandflash_resource,
 	},
-	.num_resources	= ARRAY_SIZE(da850_evm_nandflash_resource),
-	.resource	= da850_evm_nandflash_resource,
+	{
+		.name		= "physmap-flash",
+		.id		= 0,
+		.dev		= {
+			.platform_data  = &da850_evm_norflash_data,
+		},
+		.num_resources	= 1,
+		.resource	= da850_evm_norflash_resource,
+
+	},
+
+};
+static struct davinci_aemif_devices da850_emif_devices = {
+	.devices	= da850_evm_devices,
+	.num_devices	= ARRAY_SIZE(da850_evm_devices),
 };
 
-static struct platform_device *da850_evm_devices[] __initdata = {
-	&da850_evm_nandflash_device,
-	&da850_evm_norflash_device,
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &da850_emif_devices,
+	},
 };
 
 #define DA8XX_AEMIF_CE2CFG_OFFSET	0x10
@@ -352,9 +362,7 @@ static inline void da850_evm_setup_nor_nand(void)
 				ret);
 
 		da850_evm_init_nor();
-
-		platform_add_devices(da850_evm_devices,
-					ARRAY_SIZE(da850_evm_devices));
+		platform_device_register(&davinci_emif_device);
 	}
 }
 
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 275341f..e7359e8 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -22,6 +22,7 @@
 #include <media/tvp514x.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -93,15 +94,16 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
-
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
+static struct platform_device dm355_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
 
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
 	},
 };
 
@@ -241,9 +243,22 @@ static struct vpfe_config vpfe_cfg = {
 	.ccdc = "DM355 CCDC",
 };
 
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm355_evm_devices,
+	.num_devices	= ARRAY_SIZE(dm355_evm_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
 	&dm355evm_dm9000,
-	&davinci_nand_device,
+	&davinci_emif_device,
 };
 
 static struct davinci_uart_config uart_config __initdata = {
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c
index e99db28..ec057b6 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -19,6 +19,7 @@
 #include <linux/clk.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -89,15 +90,16 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
-
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
-
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+static struct platform_device dm355_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
 	},
 };
 
@@ -166,9 +168,22 @@ static struct platform_device dm355leopard_dm9000 = {
 	.num_resources	= ARRAY_SIZE(dm355leopard_dm9000_rsrc),
 };
 
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm355_evm_devices,
+	.num_devices	= ARRAY_SIZE(dm355_evm_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
+};
+
 static struct platform_device *davinci_leopard_devices[] __initdata = {
 	&dm355leopard_dm9000,
-	&davinci_nand_device,
+	&davinci_emif_device,
 };
 
 static struct davinci_uart_config uart_config __initdata = {
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 849311d..f97d67d 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -27,6 +27,7 @@
 #include <linux/input.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -155,13 +156,16 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+static struct platform_device dm365_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
 	},
 };
 
@@ -379,8 +383,17 @@ static void __init evm_init_i2c(void)
 	i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
 }
 
-static struct platform_device *dm365_evm_nand_devices[] __initdata = {
-	&davinci_nand_device,
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm365_emif_devices,
+	.num_devices	= ARRAY_SIZE(dm365_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
 };
 
 static inline int have_leds(void)
@@ -502,8 +515,7 @@ fail:
 		/* external keypad mux */
 		mux |= BIT(7);
 
-		platform_add_devices(dm365_evm_nand_devices,
-				ARRAY_SIZE(dm365_evm_nand_devices));
+		platform_device_register(&davinci_emif_device);
 	} else {
 		/* no OneNAND support yet */
 	}
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 99a6639..ad4c944 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -44,61 +44,21 @@
 #define LXT971_PHY_ID	(0x001378e2)
 #define LXT971_PHY_MASK	(0xfffffff0)
 
-static struct mtd_partition davinci_evm_norflash_partitions[] = {
-	/* bootloader (UBL, U-Boot, etc) in first 5 sectors */
-	{
-		.name		= "bootloader",
-		.offset		= 0,
-		.size		= 5 * SZ_64K,
-		.mask_flags	= MTD_WRITEABLE, /* force read-only */
-	},
-	/* bootloader params in the next 1 sectors */
-	{
-		.name		= "params",
-		.offset		= MTDPART_OFS_APPEND,
-		.size		= SZ_64K,
-		.mask_flags	= 0,
-	},
-	/* kernel */
-	{
-		.name		= "kernel",
-		.offset		= MTDPART_OFS_APPEND,
-		.size		= SZ_2M,
-		.mask_flags	= 0
-	},
-	/* file system */
-	{
-		.name		= "filesystem",
-		.offset		= MTDPART_OFS_APPEND,
-		.size		= MTDPART_SIZ_FULL,
-		.mask_flags	= 0
-	}
-};
-
-static struct physmap_flash_data davinci_evm_norflash_data = {
-	.width		= 2,
-	.parts		= davinci_evm_norflash_partitions,
-	.nr_parts	= ARRAY_SIZE(davinci_evm_norflash_partitions),
-};
-
-/* NOTE: CFI probe will correctly detect flash part as 32M, but EMIF
- * limits addresses to 16M, so using addresses past 16M will wrap */
-static struct resource davinci_evm_norflash_resource = {
-	.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
-	.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
-	.flags		= IORESOURCE_MEM,
-};
+#if defined(CONFIG_MTD_PHYSMAP) || \
+	defined(CONFIG_MTD_PHYSMAP_MODULE)
+#define HAS_NOR 1
+#else
+#define HAS_NOR 0
+#endif
 
-static struct platform_device davinci_evm_norflash_device = {
-	.name		= "physmap-flash",
-	.id		= 0,
-	.dev		= {
-		.platform_data	= &davinci_evm_norflash_data,
-	},
-	.num_resources	= 1,
-	.resource	= &davinci_evm_norflash_resource,
-};
+#if defined(CONFIG_MTD_NAND_DAVINCI) || \
+	defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
+#define HAS_NAND 1
+#else
+#define HAS_NAND 0
+#endif
 
+#if (HAS_NAND == 1)
 /* DM644x EVM includes a 64 MByte small-page NAND flash (16K blocks).
  * It may used instead of the (default) NOR chip to boot, using TI's
  * tools to install the secondary boot loader (UBL) and U-Boot.
@@ -166,15 +126,79 @@ static struct resource davinci_evm_nandflash_resource[] = {
 		.flags		= IORESOURCE_MEM,
 	},
 };
+#elif (HAS_NOR == 1)
+static struct mtd_partition davinci_evm_norflash_partitions[] = {
+	/* bootloader (UBL, U-Boot, etc) in first 5 sectors */
+	{
+		.name		= "bootloader",
+		.offset		= 0,
+		.size		= 5 * SZ_64K,
+		.mask_flags	= MTD_WRITEABLE, /* force read-only */
+	},
+	/* bootloader params in the next 1 sectors */
+	{
+		.name		= "params",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_64K,
+		.mask_flags	= 0,
+	},
+	/* kernel */
+	{
+		.name		= "kernel",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_2M,
+		.mask_flags	= 0
+	},
+	/* file system */
+	{
+		.name		= "filesystem",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= MTDPART_SIZ_FULL,
+		.mask_flags	= 0
+	}
+};
+
+static struct physmap_flash_data davinci_evm_norflash_data = {
+	.width		= 2,
+	.parts		= davinci_evm_norflash_partitions,
+	.nr_parts	= ARRAY_SIZE(davinci_evm_norflash_partitions),
+};
+
+/* NOTE: CFI probe will correctly detect flash part as 32M, but EMIF
+ * limits addresses to 16M, so using addresses past 16M will wrap */
+static struct resource davinci_evm_norflash_resource[] = {
+	{
+		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+#endif
 
-static struct platform_device davinci_evm_nandflash_device = {
-	.name		= "davinci_nand",
-	.id		= 0,
-	.dev		= {
-		.platform_data	= &davinci_evm_nandflash_data,
+static struct platform_device dm644x_emif_devices[] __initdata = {
+#if (HAS_NAND == 1)
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+		.resource		= davinci_evm_nandflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(davinci_evm_nandflash_resource),
+		.dev		= {
+			.platform_data	= &davinci_evm_nandflash_data,
+		},
 	},
-	.num_resources	= ARRAY_SIZE(davinci_evm_nandflash_resource),
-	.resource	= davinci_evm_nandflash_resource,
+#elif (HAS_NOR == 1)
+	{
+		.name		= "physmap-flash",
+		.id		= 0,
+		.resource		= davinci_evm_norflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(davinci_evm_norflash_resource),
+		.dev		= {
+			.platform_data	= &davinci_evm_norflash_data,
+		},
+	},
+#endif
 };
 
 static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
@@ -649,19 +673,19 @@ static int davinci_phy_fixup(struct phy_device *phydev)
 #define HAS_ATA 0
 #endif
 
-#if defined(CONFIG_MTD_PHYSMAP) || \
-    defined(CONFIG_MTD_PHYSMAP_MODULE)
-#define HAS_NOR 1
-#else
-#define HAS_NOR 0
-#endif
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm644x_emif_devices,
+	.num_devices	= ARRAY_SIZE(dm644x_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
+};
 
-#if defined(CONFIG_MTD_NAND_DAVINCI) || \
-    defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
-#define HAS_NAND 1
-#else
-#define HAS_NAND 0
-#endif
 
 static __init void davinci_evm_init(void)
 {
@@ -683,13 +707,12 @@ static __init void davinci_evm_init(void)
 
 		/* only one device will be jumpered and detected */
 		if (HAS_NAND) {
-			platform_device_register(&davinci_evm_nandflash_device);
 			evm_leds[7].default_trigger = "nand-disk";
 			if (HAS_NOR)
 				pr_warning("WARNING: both NAND and NOR flash "
 					"are enabled; disable one of them.\n");
-		} else if (HAS_NOR)
-			platform_device_register(&davinci_evm_norflash_device);
+		}
+		platform_device_register(&davinci_emif_device);
 	}
 
 	platform_add_devices(davinci_evm_devices,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index af55a9d..34bc4af 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -104,15 +104,29 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
+static struct platform_device dm646x_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
+	},
+};
 
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm646x_emif_devices,
+	.num_devices	= ARRAY_SIZE(dm646x_emif_devices),
+};
 
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
 	},
 };
 
@@ -782,7 +796,7 @@ static __init void evm_init(void)
 	if (machine_is_davinci_dm6467tevm())
 		davinci_nand_data.timing = &dm6467tevm_nandflash_timing;
 
-	platform_device_register(&davinci_nand_device);
+	platform_device_register(&davinci_emif_device);
 
 	dm646x_init_edma(dm646x_edma_rsv);
 
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 672d820..bb29b7a 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -19,6 +19,7 @@
 #include <linux/etherdevice.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/flash.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/io.h>
 #include <asm/mach-types.h>
@@ -414,18 +415,35 @@ static struct resource mityomapl138_nandflash_resource[] = {
 	},
 };
 
-static struct platform_device mityomapl138_nandflash_device = {
-	.name		= "davinci_nand",
-	.id		= 1,
-	.dev		= {
-		.platform_data	= &mityomapl138_nandflash_data,
+static struct platform_device mityomapl138_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= mityomapl138_nandflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(mityomapl138_nandflash_resource),
+		.dev		= {
+			.platform_data	= &mityomapl138_nandflash_data,
+		},
+	},
+};
+
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= mityomapl138_emif_devices,
+	.num_devices	= ARRAY_SIZE(mityomapl138_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
 	},
-	.num_resources	= ARRAY_SIZE(mityomapl138_nandflash_resource),
-	.resource	= mityomapl138_nandflash_resource,
 };
 
 static struct platform_device *mityomapl138_devices[] __initdata = {
-	&mityomapl138_nandflash_device,
+	&davinci_emif_device,
 };
 
 static void __init mityomapl138_setup_nand(void)
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index 8d34f51..c1c6fa1 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -26,6 +26,7 @@
 #include <linux/platform_device.h>
 #include <linux/gpio.h>
 #include <linux/mtd/partitions.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
index 31da3c5..ac36320 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -30,6 +30,7 @@
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -81,14 +82,31 @@ static struct resource davinci_sffsdr_nandflash_resource[] = {
 	},
 };
 
-static struct platform_device davinci_sffsdr_nandflash_device = {
-	.name		= "davinci_nand", /* Name of driver */
-	.id		= 0,
-	.dev		= {
-		.platform_data	= &davinci_sffsdr_nandflash_data,
+static struct platform_device davinci_sffsdr_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_sffsdr_nandflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(davinci_sffsdr_nandflash_resource),
+		.dev		= {
+			.platform_data	= &davinci_sffsdr_nandflash_data,
+		},
+	},
+};
+
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= davinci_sffsdr_emif_devices,
+	.num_devices	= ARRAY_SIZE(davinci_sffsdr_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
 	},
-	.num_resources	= ARRAY_SIZE(davinci_sffsdr_nandflash_resource),
-	.resource	= davinci_sffsdr_nandflash_resource,
 };
 
 static struct at24_platform_data eeprom_info = {
@@ -121,7 +139,7 @@ static void __init sffsdr_init_i2c(void)
 }
 
 static struct platform_device *davinci_sffsdr_devices[] __initdata = {
-	&davinci_sffsdr_nandflash_device,
+	&davinci_emif_device,
 };
 
 static struct davinci_uart_config uart_config __initdata = {
-- 
1.7.1


From michael.williamson at criticallink.com  Tue Feb  7 10:45:33 2012
From: michael.williamson at criticallink.com (Michael Williamson)
Date: Tue, 07 Feb 2012 11:45:33 -0500
Subject: [PATCH v3 3/3] arm:davinci: move NAND and NOR devices as aemif
	MFD slaves
In-Reply-To: <1328627513-30134-4-git-send-email-prakash.pm@ti.com>
References: <1328627513-30134-1-git-send-email-prakash.pm@ti.com>
	<1328627513-30134-4-git-send-email-prakash.pm@ti.com>
Message-ID: <4F31552D.9060505@criticallink.com>

Hello Prakash,

On 2/7/2012 10:11 AM, Manjunathappa, Prakash wrote:

> NAND and NOR device are made as aemif device slaves, hence all DaVinci
> board NAND/NOR device registration achieved via aemif MFD driver.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
> ---
> Since v2:
> Make changes for all DaVinci boards in single patch.



[...]

> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
> index 672d820..bb29b7a 100644
> --- a/arch/arm/mach-davinci/board-mityomapl138.c
> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
> @@ -19,6 +19,7 @@
>  #include <linux/etherdevice.h>
>  #include <linux/spi/spi.h>
>  #include <linux/spi/flash.h>
> +#include <linux/mfd/davinci_aemif.h>
>  
>  #include <asm/io.h>
>  #include <asm/mach-types.h>
> @@ -414,18 +415,35 @@ static struct resource mityomapl138_nandflash_resource[] = {
>  	},
>  };
>  
> -static struct platform_device mityomapl138_nandflash_device = {
> -	.name		= "davinci_nand",
> -	.id		= 1,
> -	.dev		= {
> -		.platform_data	= &mityomapl138_nandflash_data,
> +static struct platform_device mityomapl138_emif_devices[] __initdata = {
> +	{
> +		.name		= "davinci_nand",
> +		.id		= 0,



Pretty sure this still needs to be a 1.  The nand is on chip select 3,
EMA_CS3, which I believe is the same as the da850 EVM.

-Mike



From olof at lixom.net  Tue Feb  7 19:18:58 2012
From: olof at lixom.net (Olof Johansson)
Date: Tue, 7 Feb 2012 17:18:58 -0800
Subject: ARM/ARM-SoC plans for v3.4 merge window
In-Reply-To: <4F266C13.5080302@atmel.com>
References: <20120123114902.GY1068@n2100.arm.linux.org.uk>
	<20120124095009.GS16726@n2100.arm.linux.org.uk>
	<20120126212319.GE11941@n2100.arm.linux.org.uk>
	<CAOesGMh45HSb4mRMc7q53xhmj_kMFvdVJhNnY7cY6gHi=_KynQ@mail.gmail.com>
	<4F266C13.5080302@atmel.com>
Message-ID: <CAOesGMh1wHpaDmYY6_oCu_u0s4fmTfKMLiPaa9bHh9YaiDJozw@mail.gmail.com>

Hi,

On Mon, Jan 30, 2012 at 2:08 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> On 01/29/2012 12:57 AM, Olof Johansson :
>> Hi,
>>
>>
>> On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>>
>>
>>> And we're now there. ?So...
>>>
>>> Arnd, Olaf,
>>>
>>> Please incorporate the latest ARM (for-armsoc branch) changes, which can be found at:
>>>
>>> ? ? ? ?git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git for-armsoc
>>>
>>> with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05.
>>
>> Thanks. I have added this as depends/rmk/for-armsoc in the arm-soc repo.
>>
>> Any next/ branch we start will have this as the base of said branch,
>> so any vendor branches must either already be developed against this
>> stable branch, or merge on top of this with minimal conflicts.
>
> Ok, great.
>
> I just let you know that there is a conflict between the current Linus'
> tree (with recently updated at91 fixes) and this rmk/for-armsoc branch.
>
> I can give you the resolution of this conflict easily but I would like
> to know which way I execute the merge:
>
> I use this rmk/for-armsoc as a baseline and merge the fixes already in
> Linus' tree on top of it or the other way around?
>
> Maybe it is preferable that I wait for 3.3-rc2 and merge rmk/for-armsoc
> on top of it. This result can be the base of our AT91 work for 3.4
> preparation.
>
> Your thought?

I missed replying to this email until now when I started looking at
picking up branches for the 3.4 staging, sorry for the delay.

Russell, would you prefer merging in v3.3-rc2 into your branch so I
can pull the exact same resolution from there, or should we do it
locally in arm-soc? It probably makes sense for you to do it so
there's no more conflicts from there on out for dependent branches.


-Olof

From prakash.pm at ti.com  Tue Feb  7 22:00:13 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Wed, 8 Feb 2012 04:00:13 +0000
Subject: [PATCH v3 3/3] arm:davinci: move NAND and NOR devices as aemif
	MFD slaves
In-Reply-To: <4F31552D.9060505@criticallink.com>
References: <1328627513-30134-1-git-send-email-prakash.pm@ti.com>
	<1328627513-30134-4-git-send-email-prakash.pm@ti.com>
	<4F31552D.9060505@criticallink.com>
Message-ID: <A73F36158E33644199EB82C5EC81C7BC31761D77@DBDE01.ent.ti.com>

Hi Mike,

On Tue, Feb 07, 2012 at 22:15:33, Michael Williamson wrote:
> Hello Prakash,
> 
> On 2/7/2012 10:11 AM, Manjunathappa, Prakash wrote:
> 
> > NAND and NOR device are made as aemif device slaves, hence all DaVinci
> > board NAND/NOR device registration achieved via aemif MFD driver.
> >
> > Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
> > ---
> > Since v2:
> > Make changes for all DaVinci boards in single patch.
> 
> 
> 
> [...]
> 
> > diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
> > index 672d820..bb29b7a 100644
> > --- a/arch/arm/mach-davinci/board-mityomapl138.c
> > +++ b/arch/arm/mach-davinci/board-mityomapl138.c
> > @@ -19,6 +19,7 @@
> >  #include <linux/etherdevice.h>
> >  #include <linux/spi/spi.h>
> >  #include <linux/spi/flash.h>
> > +#include <linux/mfd/davinci_aemif.h>
> >  
> >  #include <asm/io.h>
> >  #include <asm/mach-types.h>
> > @@ -414,18 +415,35 @@ static struct resource mityomapl138_nandflash_resource[] = {
> >  	},
> >  };
> >  
> > -static struct platform_device mityomapl138_nandflash_device = {
> > -	.name		= "davinci_nand",
> > -	.id		= 1,
> > -	.dev		= {
> > -		.platform_data	= &mityomapl138_nandflash_data,
> > +static struct platform_device mityomapl138_emif_devices[] __initdata = {
> > +	{
> > +		.name		= "davinci_nand",
> > +		.id		= 0,
> 
> 
> 
> Pretty sure this still needs to be a 1.  The nand is on chip select 3,
> EMA_CS3, which I believe is the same as the da850 EVM.

Yes I could not test on this board. I will make id as 1.

Thanks,
Prakash

> 
> -Mike
> 
> 
> 


From nicolas.ferre at atmel.com  Wed Feb  8 05:52:51 2012
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 08 Feb 2012 12:52:51 +0100
Subject: ARM/ARM-SoC plans for v3.4 merge window
In-Reply-To: <CAOesGMh1wHpaDmYY6_oCu_u0s4fmTfKMLiPaa9bHh9YaiDJozw@mail.gmail.com>
References: <20120123114902.GY1068@n2100.arm.linux.org.uk>
	<20120124095009.GS16726@n2100.arm.linux.org.uk>
	<20120126212319.GE11941@n2100.arm.linux.org.uk>
	<CAOesGMh45HSb4mRMc7q53xhmj_kMFvdVJhNnY7cY6gHi=_KynQ@mail.gmail.com>
	<4F266C13.5080302@atmel.com>
	<CAOesGMh1wHpaDmYY6_oCu_u0s4fmTfKMLiPaa9bHh9YaiDJozw@mail.gmail.com>
Message-ID: <4F326213.3030500@atmel.com>

On 02/08/2012 02:18 AM, Olof Johansson :
> Hi,
> 
> On Mon, Jan 30, 2012 at 2:08 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
>> On 01/29/2012 12:57 AM, Olof Johansson :
>>> Hi,
>>>
>>>
>>> On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux
>>> <linux at arm.linux.org.uk> wrote:
>>>
>>>
>>>> And we're now there.  So...
>>>>
>>>> Arnd, Olaf,
>>>>
>>>> Please incorporate the latest ARM (for-armsoc branch) changes, which can be found at:
>>>>
>>>>        git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git for-armsoc
>>>>
>>>> with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05.
>>>
>>> Thanks. I have added this as depends/rmk/for-armsoc in the arm-soc repo.
>>>
>>> Any next/ branch we start will have this as the base of said branch,
>>> so any vendor branches must either already be developed against this
>>> stable branch, or merge on top of this with minimal conflicts.
>>
>> Ok, great.
>>
>> I just let you know that there is a conflict between the current Linus'
>> tree (with recently updated at91 fixes) and this rmk/for-armsoc branch.
>>
>> I can give you the resolution of this conflict easily but I would like
>> to know which way I execute the merge:
>>
>> I use this rmk/for-armsoc as a baseline and merge the fixes already in
>> Linus' tree on top of it or the other way around?
>>
>> Maybe it is preferable that I wait for 3.3-rc2 and merge rmk/for-armsoc
>> on top of it. This result can be the base of our AT91 work for 3.4
>> preparation.
>>
>> Your thought?
> 
> I missed replying to this email until now when I started looking at
> picking up branches for the 3.4 staging, sorry for the delay.
> 
> Russell, would you prefer merging in v3.3-rc2 into your branch so I
> can pull the exact same resolution from there, or should we do it
> locally in arm-soc? It probably makes sense for you to do it so
> there's no more conflicts from there on out for dependent branches.

Olof,

For your information the conflict resolution is already present in
linux-next (and in my 3.4 preparation branches actually).

Best regards,
-- 
Nicolas Ferre

From manjunath.hadli at ti.com  Wed Feb  8 06:41:14 2012
From: manjunath.hadli at ti.com (Hadli, Manjunath)
Date: Wed, 8 Feb 2012 12:41:14 +0000
Subject: [RESEND PATCH] davinci: CQ93VC: remove machine specific header
	file inclusion from codec driver
In-Reply-To: <20120110184741.GG7164@opensource.wolfsonmicro.com>
References: <1326194863-31194-1-git-send-email-manjunath.hadli@ti.com>
	<20120110184741.GG7164@opensource.wolfsonmicro.com>
Message-ID: <E99FAA59F8D8D34D8A118DD37F7C8F753174E3EC@DBDE01.ent.ti.com>

Mark,

On Wed, Jan 11, 2012 at 00:17:41, Mark Brown wrote:
> On Tue, Jan 10, 2012 at 04:57:43PM +0530, Manjunath Hadli wrote:
> > remove unnecessary inclusion of machine specific header file 
> > mach/dm365.h from cq93vc.c voice codec driver which comes in the way 
> > of platform code consolidation.
> 
> Applied but please do try to use a subject line appropriate for the subsystem you're contributing to.
I still can't find this patch in the mainline, any issues?

Regards,
--Manju
> 


From broonie at opensource.wolfsonmicro.com  Wed Feb  8 06:52:04 2012
From: broonie at opensource.wolfsonmicro.com (Mark Brown)
Date: Wed, 8 Feb 2012 12:52:04 +0000
Subject: [RESEND PATCH] davinci: CQ93VC: remove machine specific header
	file inclusion from codec driver
In-Reply-To: <E99FAA59F8D8D34D8A118DD37F7C8F753174E3EC@DBDE01.ent.ti.com>
References: <1326194863-31194-1-git-send-email-manjunath.hadli@ti.com>
	<20120110184741.GG7164@opensource.wolfsonmicro.com>
	<E99FAA59F8D8D34D8A118DD37F7C8F753174E3EC@DBDE01.ent.ti.com>
Message-ID: <20120208125204.GA5943@opensource.wolfsonmicro.com>

On Wed, Feb 08, 2012 at 12:41:14PM +0000, Hadli, Manjunath wrote:
> On Wed, Jan 11, 2012 at 00:17:41, Mark Brown wrote:

Fix your mailer, not only is it not word wrapping within paragraphs it's
adding such problems to quoted text.

> > Applied but please do try to use a subject line appropriate for the subsystem you're contributing to.

> I still can't find this patch in the mainline, any issues?

It will go into mainline in the next merge window.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20120208/b2f3d2cb/attachment.bin>

From olof at lixom.net  Wed Feb  8 19:19:21 2012
From: olof at lixom.net (Olof Johansson)
Date: Wed, 8 Feb 2012 17:19:21 -0800
Subject: ARM/ARM-SoC plans for v3.4 merge window
In-Reply-To: <4F326213.3030500@atmel.com>
References: <20120123114902.GY1068@n2100.arm.linux.org.uk>
	<20120124095009.GS16726@n2100.arm.linux.org.uk>
	<20120126212319.GE11941@n2100.arm.linux.org.uk>
	<CAOesGMh45HSb4mRMc7q53xhmj_kMFvdVJhNnY7cY6gHi=_KynQ@mail.gmail.com>
	<4F266C13.5080302@atmel.com>
	<CAOesGMh1wHpaDmYY6_oCu_u0s4fmTfKMLiPaa9bHh9YaiDJozw@mail.gmail.com>
	<4F326213.3030500@atmel.com>
Message-ID: <CAOesGMjm+irNw-kHStLf_H3QyJHa04ProG6i0Zyum1iy7TJxpA@mail.gmail.com>

On Wed, Feb 8, 2012 at 3:52 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> On 02/08/2012 02:18 AM, Olof Johansson :
>> Hi,
>>
>> On Mon, Jan 30, 2012 at 2:08 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
>>> On 01/29/2012 12:57 AM, Olof Johansson :
>>>> Hi,
>>>>
>>>>
>>>> On Thu, Jan 26, 2012 at 1:23 PM, Russell King - ARM Linux
>>>> <linux at arm.linux.org.uk> wrote:
>>>>
>>>>
>>>>> And we're now there. ?So...
>>>>>
>>>>> Arnd, Olaf,
>>>>>
>>>>> Please incorporate the latest ARM (for-armsoc branch) changes, which can be found at:
>>>>>
>>>>> ? ? ? ?git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git for-armsoc
>>>>>
>>>>> with SHA1 dcf81c1af839b77b44404453ecae6e5ac5a75f05.
>>>>
>>>> Thanks. I have added this as depends/rmk/for-armsoc in the arm-soc repo.
>>>>
>>>> Any next/ branch we start will have this as the base of said branch,
>>>> so any vendor branches must either already be developed against this
>>>> stable branch, or merge on top of this with minimal conflicts.
>>>
>>> Ok, great.
>>>
>>> I just let you know that there is a conflict between the current Linus'
>>> tree (with recently updated at91 fixes) and this rmk/for-armsoc branch.
>>>
>>> I can give you the resolution of this conflict easily but I would like
>>> to know which way I execute the merge:
>>>
>>> I use this rmk/for-armsoc as a baseline and merge the fixes already in
>>> Linus' tree on top of it or the other way around?
>>>
>>> Maybe it is preferable that I wait for 3.3-rc2 and merge rmk/for-armsoc
>>> on top of it. This result can be the base of our AT91 work for 3.4
>>> preparation.
>>>
>>> Your thought?
>>
>> I missed replying to this email until now when I started looking at
>> picking up branches for the 3.4 staging, sorry for the delay.
>>
>> Russell, would you prefer merging in v3.3-rc2 into your branch so I
>> can pull the exact same resolution from there, or should we do it
>> locally in arm-soc? It probably makes sense for you to do it so
>> there's no more conflicts from there on out for dependent branches.
>
> Olof,
>
> For your information the conflict resolution is already present in
> linux-next (and in my 3.4 preparation branches actually).

Yeah, it's just convenient if it's resolved once in the base branch
instead of every time we pull in something based on it.

I've pulled in and resolved the conflict with v3.3-rc2 into
depends/rmk/for-armsoc now so it should be covered for anyone basing
new branches off of it.


Thanks,

-Olof

From prakash.pm at ti.com  Wed Feb  8 23:04:38 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 9 Feb 2012 10:34:38 +0530
Subject: [PATCH] video: da8xx-fb: Fix build warning on unused label
Message-ID: <1328763879-16345-1-git-send-email-prakash.pm@ti.com>

Patch fixes build warning on label "err_cpu_freq" when CONFIG_CPU_FREQ
is not defined.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
 drivers/video/da8xx-fb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 29577bf..f360d62 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1264,8 +1264,8 @@ static int __devinit fb_probe(struct platform_device *device)
 irq_freq:
 #ifdef CONFIG_CPU_FREQ
 	lcd_da8xx_cpufreq_deregister(par);
-#endif
 err_cpu_freq:
+#endif
 	unregister_framebuffer(da8xx_fb_info);
 
 err_dealloc_cmap:
-- 
1.7.1


From prakash.pm at ti.com  Wed Feb  8 23:04:39 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 9 Feb 2012 10:34:39 +0530
Subject: [PATCH] video:da8xx-fb: calculate pixel clock period for the panel
In-Reply-To: <1328763879-16345-1-git-send-email-prakash.pm@ti.com>
References: <1328763879-16345-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1328763879-16345-2-git-send-email-prakash.pm@ti.com>

Patch calculates pixel clock period in pico seconds and updates
the same in variable screen information structure. fbset utility
uses this information.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
 drivers/video/da8xx-fb.c |   21 ++++++++++++++++++++-
 1 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index f360d62..8b0a174 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -32,6 +32,7 @@
 #include <linux/console.h>
 #include <linux/slab.h>
 #include <video/da8xx-fb.h>
+#include <asm/div64.h>
 
 #define DRIVER_NAME "da8xx_lcdc"
 
@@ -174,7 +175,6 @@ static struct fb_var_screeninfo da8xx_fb_var __devinitdata = {
 	.activate = 0,
 	.height = -1,
 	.width = -1,
-	.pixclock = 46666,	/* 46us - AUO display */
 	.accel_flags = 0,
 	.left_margin = LEFT_MARGIN,
 	.right_margin = RIGHT_MARGIN,
@@ -1048,6 +1048,24 @@ static struct fb_ops da8xx_fb_ops = {
 	.fb_blank = cfb_blank,
 };
 
+/*
+ * Calculate and return pixel clock period in pico secods
+ */
+static unsigned int da8xxfb_pixel_clk_period(struct da8xx_fb_par *par)
+{
+	unsigned int lcd_clk, div;
+	unsigned int configured_pix_clk;
+	unsigned long long pix_clk_period_picosec = 1000000000000ULL;
+
+	lcd_clk = clk_get_rate(par->lcdc_clk);
+	div = lcd_clk / par->pxl_clk;
+	configured_pix_clk = (lcd_clk / div);
+
+	do_div(pix_clk_period_picosec, configured_pix_clk);
+
+	return pix_clk_period_picosec;
+}
+
 static int __devinit fb_probe(struct platform_device *device)
 {
 	struct da8xx_lcdc_platform_data *fb_pdata =
@@ -1209,6 +1227,7 @@ static int __devinit fb_probe(struct platform_device *device)
 
 	da8xx_fb_var.hsync_len = lcdc_info->hsw;
 	da8xx_fb_var.vsync_len = lcdc_info->vsw;
+	da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
 
 	/* Initialize fbinfo */
 	da8xx_fb_info->flags = FBINFO_FLAG_DEFAULT;
-- 
1.7.1


From prakash.pm at ti.com  Thu Feb  9 00:24:06 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 9 Feb 2012 11:54:06 +0530
Subject: [PATCH v2] video:da8xx-fb: calculate pixel clock period for the panel
Message-ID: <1328768646-25169-1-git-send-email-prakash.pm@ti.com>

Patch calculates pixel clock period in pico seconds and updates
the same in variable screen information structure. fbset utility
uses this information.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v1:
Fixed the spelling mistake.

 drivers/video/da8xx-fb.c |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index f360d62..882dd67 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -32,6 +32,7 @@
 #include <linux/console.h>
 #include <linux/slab.h>
 #include <video/da8xx-fb.h>
+#include <asm/div64.h>
 
 #define DRIVER_NAME "da8xx_lcdc"
 
@@ -174,7 +175,6 @@ static struct fb_var_screeninfo da8xx_fb_var __devinitdata = {
 	.activate = 0,
 	.height = -1,
 	.width = -1,
-	.pixclock = 46666,	/* 46us - AUO display */
 	.accel_flags = 0,
 	.left_margin = LEFT_MARGIN,
 	.right_margin = RIGHT_MARGIN,
@@ -1048,6 +1048,22 @@ static struct fb_ops da8xx_fb_ops = {
 	.fb_blank = cfb_blank,
 };
 
+/* Calculate and return pixel clock period in pico seconds */
+static unsigned int da8xxfb_pixel_clk_period(struct da8xx_fb_par *par)
+{
+	unsigned int lcd_clk, div;
+	unsigned int configured_pix_clk;
+	unsigned long long pix_clk_period_picosec = 1000000000000ULL;
+
+	lcd_clk = clk_get_rate(par->lcdc_clk);
+	div = lcd_clk / par->pxl_clk;
+	configured_pix_clk = (lcd_clk / div);
+
+	do_div(pix_clk_period_picosec, configured_pix_clk);
+
+	return pix_clk_period_picosec;
+}
+
 static int __devinit fb_probe(struct platform_device *device)
 {
 	struct da8xx_lcdc_platform_data *fb_pdata =
@@ -1209,6 +1225,7 @@ static int __devinit fb_probe(struct platform_device *device)
 
 	da8xx_fb_var.hsync_len = lcdc_info->hsw;
 	da8xx_fb_var.vsync_len = lcdc_info->vsw;
+	da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
 
 	/* Initialize fbinfo */
 	da8xx_fb_info->flags = FBINFO_FLAG_DEFAULT;
-- 
1.7.1


From prakash.pm at ti.com  Thu Feb  9 01:18:25 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 9 Feb 2012 12:48:25 +0530
Subject: [PATCH v4 0/3] Moving EMIF driver to MFD framework
Message-ID: <1328771908-32527-1-git-send-email-prakash.pm@ti.com>

Patch series are based on the discussion and concerns expressed in
davinci-linux-open-source community. Here is the link for the same:
http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-tt7059739.html#none

Manjunathappa, Prakash (3):
  arm:davinci: prepare to move aemif driver to drivers/mfd
  arm:davinci: move emif driver to drivers/mfd from mach-davinci folder
  arm:davinci: move NAND and NOR devices as aemif MFD slaves

 arch/arm/Kconfig                                   |    1 +
 arch/arm/mach-davinci/Makefile                     |    2 +-
 arch/arm/mach-davinci/aemif.c                      |  133 -------------
 arch/arm/mach-davinci/board-da830-evm.c            |   33 +++-
 arch/arm/mach-davinci/board-da850-evm.c            |   56 +++---
 arch/arm/mach-davinci/board-dm355-evm.c            |   33 +++-
 arch/arm/mach-davinci/board-dm355-leopard.c        |   35 +++-
 arch/arm/mach-davinci/board-dm365-evm.c            |   34 +++-
 arch/arm/mach-davinci/board-dm644x-evm.c           |  175 ++++++++++-------
 arch/arm/mach-davinci/board-dm646x-evm.c           |   32 +++-
 arch/arm/mach-davinci/board-mityomapl138.c         |   34 +++-
 arch/arm/mach-davinci/board-neuros-osd2.c          |    1 +
 arch/arm/mach-davinci/board-sffsdr.c               |   34 +++-
 drivers/mfd/Makefile                               |    1 +
 drivers/mfd/davinci_aemif.c                        |  206 ++++++++++++++++++++
 drivers/mtd/nand/davinci_nand.c                    |    2 +-
 .../aemif.h => include/linux/mfd/davinci_aemif.h   |   14 ++
 17 files changed, 527 insertions(+), 299 deletions(-)
 delete mode 100644 arch/arm/mach-davinci/aemif.c
 create mode 100644 drivers/mfd/davinci_aemif.c
 rename arch/arm/mach-davinci/include/mach/aemif.h => include/linux/mfd/davinci_aemif.h (74%)


From prakash.pm at ti.com  Thu Feb  9 01:18:26 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 9 Feb 2012 12:48:26 +0530
Subject: [PATCH v4 1/3] arm:davinci: prepare to move aemif driver to
	drivers/mfd
In-Reply-To: <1328771908-32527-1-git-send-email-prakash.pm@ti.com>
References: <1328771908-32527-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1328771908-32527-2-git-send-email-prakash.pm@ti.com>

Patch moves emif header file appropriately as a part preparation to move emif
driver from arch/arm/mach-davinci/ to drivers/mfd folder.
There by it isolates modifications in emif interface depicting as platform code
change.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v3:
No change. Resending as 3/3 in patch changed.
Since v2:
No change.
Since v1:
Patch generated using -M option.

 arch/arm/mach-davinci/aemif.c                      |    2 +-
 arch/arm/mach-davinci/board-da830-evm.c            |    2 +-
 arch/arm/mach-davinci/board-da850-evm.c            |    2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c           |    2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c           |    2 +-
 drivers/mtd/nand/davinci_nand.c                    |    2 +-
 .../aemif.h => include/linux/mfd/davinci_aemif.h   |    0
 7 files changed, 6 insertions(+), 6 deletions(-)
 rename arch/arm/mach-davinci/include/mach/aemif.h => include/linux/mfd/davinci_aemif.h (100%)

diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
index 1ce70a9..b67c115 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/arch/arm/mach-davinci/aemif.c
@@ -15,7 +15,7 @@
 #include <linux/module.h>
 #include <linux/time.h>
 
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 /* Timing value configuration */
 
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index dc1afe5..0b43554 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -31,7 +31,7 @@
 #include <mach/nand.h>
 #include <mach/da8xx.h>
 #include <mach/usb.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 #include <mach/spi.h>
 
 #define DA830_EVM_PHY_ID		""
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index d508890..9f2a544 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -41,7 +41,7 @@
 #include <mach/da8xx.h>
 #include <mach/nand.h>
 #include <mach/mux.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 #include <mach/spi.h>
 
 #define DA850_EVM_PHY_ID		"davinci_mdio-0:00"
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 1247ecd..99a6639 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -38,7 +38,7 @@
 #include <mach/nand.h>
 #include <mach/mmc.h>
 #include <mach/usb.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #define DM644X_EVM_PHY_ID		"davinci_mdio-0:01"
 #define LXT971_PHY_ID	(0x001378e2)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 872ac69..af55a9d 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -43,7 +43,7 @@
 #include <mach/nand.h>
 #include <mach/clock.h>
 #include <mach/cdce949.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include "clock.h"
 
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 6e56615..f19151b 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -35,7 +35,7 @@
 #include <linux/slab.h>
 
 #include <mach/nand.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 /*
  * This is a device driver for the NAND flash controller found on the
diff --git a/arch/arm/mach-davinci/include/mach/aemif.h b/include/linux/mfd/davinci_aemif.h
similarity index 100%
rename from arch/arm/mach-davinci/include/mach/aemif.h
rename to include/linux/mfd/davinci_aemif.h
-- 
1.7.1


From prakash.pm at ti.com  Thu Feb  9 01:18:27 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 9 Feb 2012 12:48:27 +0530
Subject: [PATCH v4 2/3] arm:davinci: move emif driver to drivers/mfd from
	mach-davinci folder
In-Reply-To: <1328771908-32527-1-git-send-email-prakash.pm@ti.com>
References: <1328771908-32527-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1328771908-32527-3-git-send-email-prakash.pm@ti.com>

Move aemif kernel module from arch/arm/mach-davinci/ to multi functional
devices frame work. "davinci_aemif" MFD driver adds "davinci_nand" and
"physmap-flash" slave devices.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v3:
No change. Resending as 3/3 in patch changed.
Since v2:
Modified emif MFD driver to load multiple instance of NAND/NOR devices.
Since v1:
Patch generated using -M option.

 arch/arm/Kconfig                                   |    1 +
 arch/arm/mach-davinci/Makefile                     |    2 +-
 drivers/mfd/Makefile                               |    1 +
 .../aemif.c => drivers/mfd/davinci_aemif.c         |   75 +++++++++++++++++++-
 include/linux/mfd/davinci_aemif.h                  |   14 ++++
 5 files changed, 91 insertions(+), 2 deletions(-)
 rename arch/arm/mach-davinci/aemif.c => drivers/mfd/davinci_aemif.c (66%)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a48aecc..09dcb94 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -934,6 +934,7 @@ config ARCH_DAVINCI
 	select GENERIC_ALLOCATOR
 	select GENERIC_IRQ_CHIP
 	select ARCH_HAS_HOLES_MEMORYMODEL
+	select MFD_CORE
 	help
 	  Support for TI's DaVinci platform.
 
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 2db78bd..8bab47c 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
 
 # Common objects
 obj-y 			:= time.o clock.o serial.o psc.o \
-			   dma.o usb.o common.o sram.o aemif.o
+			   dma.o usb.o common.o sram.o
 
 obj-$(CONFIG_DAVINCI_MUX)		+= mux.o
 
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b953bab..54fc267 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_HTC_EGPIO)		+= htc-egpio.o
 obj-$(CONFIG_HTC_PASIC3)	+= htc-pasic3.o
 obj-$(CONFIG_HTC_I2CPLD)	+= htc-i2cpld.o
 
+obj-${CONFIG_ARCH_DAVINCI}	+= davinci_aemif.o
 obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)	+= davinci_voicecodec.o
 obj-$(CONFIG_MFD_DM355EVM_MSP)	+= dm355evm_msp.o
 obj-$(CONFIG_MFD_TI_SSP)	+= ti-ssp.o
diff --git a/arch/arm/mach-davinci/aemif.c b/drivers/mfd/davinci_aemif.c
similarity index 66%
rename from arch/arm/mach-davinci/aemif.c
rename to drivers/mfd/davinci_aemif.c
index b67c115..5fb490d 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/drivers/mfd/davinci_aemif.c
@@ -14,8 +14,13 @@
 #include <linux/clk.h>
 #include <linux/module.h>
 #include <linux/time.h>
-
 #include <linux/mfd/davinci_aemif.h>
+#include <linux/mtd/physmap.h>
+#include <linux/slab.h>
+#include <mach/nand.h>
+
+static char *name[] = {"davinci_nand", "physmap-flash",};
+#define MAX ARRAY_SIZE(name)
 
 /* Timing value configuration */
 
@@ -131,3 +136,71 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
 	return 0;
 }
 EXPORT_SYMBOL(davinci_aemif_setup_timing);
+
+static int __init davinci_aemif_probe(struct platform_device *pdev)
+{
+	struct davinci_aemif_devices *davinci_aemif_devices =
+		pdev->dev.platform_data;
+	struct platform_device *devices;
+	struct mfd_cell *cells;
+	int ret, i, j, count;
+
+	devices = davinci_aemif_devices->devices;
+
+	cells = kzalloc(sizeof(struct mfd_cell) *
+			davinci_aemif_devices->num_devices, GFP_KERNEL);
+
+	for (j = 0, count = 0; j < MAX; j++) {
+		for (i = 0; i < davinci_aemif_devices->num_devices; i++) {
+			if (strcmp(devices[i].name, name[j]))
+				continue;
+			cells[count].name = name[j];
+			cells[count].platform_data =
+				devices[i].dev.platform_data;
+			cells[count].pdata_size =
+				sizeof(struct davinci_nand_pdata);
+			cells[count].id = devices[i].id;
+			cells[count].resources = devices[i].resource;
+			cells[count].num_resources = devices[i].num_resources;
+			count++;
+		}
+	}
+
+	ret = mfd_add_devices(&pdev->dev, 0, cells,
+			      count, NULL, 0);
+	if (ret != 0)
+		dev_err(&pdev->dev, "fail to register client devices\n");
+
+	return 0;
+}
+
+static int __devexit davinci_aemif_remove(struct platform_device *pdev)
+{
+	mfd_remove_devices(&pdev->dev);
+	return 0;
+}
+
+static struct platform_driver davinci_aemif_driver = {
+	.driver	= {
+		.name = "davinci_aemif",
+		.owner = THIS_MODULE,
+	},
+	.remove	= __devexit_p(davinci_aemif_remove),
+};
+
+static int __init davinci_aemif_init(void)
+{
+	return platform_driver_probe(&davinci_aemif_driver,
+			davinci_aemif_probe);
+}
+module_init(davinci_aemif_init);
+
+static void __exit davinci_aemif_exit(void)
+{
+	platform_driver_unregister(&davinci_aemif_driver);
+}
+module_exit(davinci_aemif_exit);
+
+MODULE_AUTHOR("Prakash Manjunathappa");
+MODULE_DESCRIPTION("Texas Instruments AEMIF Interface");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/davinci_aemif.h b/include/linux/mfd/davinci_aemif.h
index 05b2934..18650c3 100644
--- a/include/linux/mfd/davinci_aemif.h
+++ b/include/linux/mfd/davinci_aemif.h
@@ -10,6 +10,10 @@
 #ifndef _MACH_DAVINCI_AEMIF_H
 #define _MACH_DAVINCI_AEMIF_H
 
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/core.h>
+
 #define NRCSR_OFFSET		0x00
 #define AWCCR_OFFSET		0x04
 #define A1CR_OFFSET		0x10
@@ -18,6 +22,16 @@
 #define ACR_EW_MASK		BIT(30)
 #define ACR_SS_MASK		BIT(31)
 
+enum davinci_emif_cells {
+	DAVINCI_NAND_DEVICE_CELL,
+	DAVINCI_NOR_FLASH_CELL,
+};
+
+struct davinci_aemif_devices {
+	struct platform_device *devices;
+	unsigned int num_devices;
+};
+
 /* All timings in nanoseconds */
 struct davinci_aemif_timing {
 	u8	wsetup;
-- 
1.7.1


From prakash.pm at ti.com  Thu Feb  9 01:18:28 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 9 Feb 2012 12:48:28 +0530
Subject: [PATCH v4 3/3] arm:davinci: move NAND and NOR devices as aemif MFD
	slaves
In-Reply-To: <1328771908-32527-1-git-send-email-prakash.pm@ti.com>
References: <1328771908-32527-1-git-send-email-prakash.pm@ti.com>
Message-ID: <1328771908-32527-4-git-send-email-prakash.pm@ti.com>

NAND and NOR device are made as aemif device slaves, hence all DaVinci
board NAND/NOR device registration achieved via aemif MFD driver.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v3:
Changed NAND device id to 1 for board-mityomapl138.
Since v2:
Make changes for all DaVinci boards in single patch.
Since v1:
Patch generated using -M option.

 arch/arm/mach-davinci/board-da830-evm.c     |   31 ++++--
 arch/arm/mach-davinci/board-da850-evm.c     |   54 +++++----
 arch/arm/mach-davinci/board-dm355-evm.c     |   33 ++++--
 arch/arm/mach-davinci/board-dm355-leopard.c |   35 ++++--
 arch/arm/mach-davinci/board-dm365-evm.c     |   34 ++++--
 arch/arm/mach-davinci/board-dm644x-evm.c    |  173 +++++++++++++++------------
 arch/arm/mach-davinci/board-dm646x-evm.c    |   30 ++++--
 arch/arm/mach-davinci/board-mityomapl138.c  |   34 ++++--
 arch/arm/mach-davinci/board-neuros-osd2.c   |    1 +
 arch/arm/mach-davinci/board-sffsdr.c        |   34 ++++--
 10 files changed, 299 insertions(+), 160 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 0b43554..0ad3662 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -396,14 +396,29 @@ static struct resource da830_evm_nand_resources[] = {
 	},
 };
 
-static struct platform_device da830_evm_nand_device = {
-	.name		= "davinci_nand",
-	.id		= 1,
-	.dev		= {
-		.platform_data	= &da830_evm_nand_pdata,
+static struct platform_device da830_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 1,
+		.dev		= {
+			.platform_data	= &da830_evm_nand_pdata,
+		},
+		.num_resources	= ARRAY_SIZE(da830_evm_nand_resources),
+		.resource	= da830_evm_nand_resources,
+	},
+};
+
+static struct davinci_aemif_devices da830_emif_devices = {
+	.devices	= da830_evm_devices,
+	.num_devices	= ARRAY_SIZE(da830_evm_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &da830_emif_devices,
 	},
-	.num_resources	= ARRAY_SIZE(da830_evm_nand_resources),
-	.resource	= da830_evm_nand_resources,
 };
 
 static inline void da830_evm_init_nand(int mux_mode)
@@ -422,7 +437,7 @@ static inline void da830_evm_init_nand(int mux_mode)
 		pr_warning("da830_evm_init: emif25 mux setup failed: %d\n",
 				ret);
 
-	ret = platform_device_register(&da830_evm_nand_device);
+	ret = platform_device_register(&davinci_emif_device);
 	if (ret)
 		pr_warning("da830_evm_init: NAND device not registered.\n");
 
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 9f2a544..49ab16d 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -181,16 +181,6 @@ static struct resource da850_evm_norflash_resource[] = {
 	},
 };
 
-static struct platform_device da850_evm_norflash_device = {
-	.name		= "physmap-flash",
-	.id		= 0,
-	.dev		= {
-		.platform_data  = &da850_evm_norflash_data,
-	},
-	.num_resources	= 1,
-	.resource	= da850_evm_norflash_resource,
-};
-
 static struct davinci_pm_config da850_pm_pdata = {
 	.sleepcount = 128,
 };
@@ -273,19 +263,39 @@ static struct resource da850_evm_nandflash_resource[] = {
 	},
 };
 
-static struct platform_device da850_evm_nandflash_device = {
-	.name		= "davinci_nand",
-	.id		= 1,
-	.dev		= {
-		.platform_data	= &da850_evm_nandflash_data,
+static struct platform_device da850_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 1,
+		.dev		= {
+			.platform_data	= &da850_evm_nandflash_data,
+		},
+		.num_resources	= ARRAY_SIZE(da850_evm_nandflash_resource),
+		.resource	= da850_evm_nandflash_resource,
 	},
-	.num_resources	= ARRAY_SIZE(da850_evm_nandflash_resource),
-	.resource	= da850_evm_nandflash_resource,
+	{
+		.name		= "physmap-flash",
+		.id		= 0,
+		.dev		= {
+			.platform_data  = &da850_evm_norflash_data,
+		},
+		.num_resources	= 1,
+		.resource	= da850_evm_norflash_resource,
+
+	},
+
+};
+static struct davinci_aemif_devices da850_emif_devices = {
+	.devices	= da850_evm_devices,
+	.num_devices	= ARRAY_SIZE(da850_evm_devices),
 };
 
-static struct platform_device *da850_evm_devices[] __initdata = {
-	&da850_evm_nandflash_device,
-	&da850_evm_norflash_device,
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &da850_emif_devices,
+	},
 };
 
 #define DA8XX_AEMIF_CE2CFG_OFFSET	0x10
@@ -352,9 +362,7 @@ static inline void da850_evm_setup_nor_nand(void)
 				ret);
 
 		da850_evm_init_nor();
-
-		platform_add_devices(da850_evm_devices,
-					ARRAY_SIZE(da850_evm_devices));
+		platform_device_register(&davinci_emif_device);
 	}
 }
 
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 275341f..e7359e8 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -22,6 +22,7 @@
 #include <media/tvp514x.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -93,15 +94,16 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
-
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
+static struct platform_device dm355_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
 
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
 	},
 };
 
@@ -241,9 +243,22 @@ static struct vpfe_config vpfe_cfg = {
 	.ccdc = "DM355 CCDC",
 };
 
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm355_evm_devices,
+	.num_devices	= ARRAY_SIZE(dm355_evm_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
 	&dm355evm_dm9000,
-	&davinci_nand_device,
+	&davinci_emif_device,
 };
 
 static struct davinci_uart_config uart_config __initdata = {
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c
index e99db28..ec057b6 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -19,6 +19,7 @@
 #include <linux/clk.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -89,15 +90,16 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
-
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
-
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+static struct platform_device dm355_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
 	},
 };
 
@@ -166,9 +168,22 @@ static struct platform_device dm355leopard_dm9000 = {
 	.num_resources	= ARRAY_SIZE(dm355leopard_dm9000_rsrc),
 };
 
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm355_evm_devices,
+	.num_devices	= ARRAY_SIZE(dm355_evm_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
+};
+
 static struct platform_device *davinci_leopard_devices[] __initdata = {
 	&dm355leopard_dm9000,
-	&davinci_nand_device,
+	&davinci_emif_device,
 };
 
 static struct davinci_uart_config uart_config __initdata = {
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 849311d..f97d67d 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -27,6 +27,7 @@
 #include <linux/input.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -155,13 +156,16 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+static struct platform_device dm365_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
 	},
 };
 
@@ -379,8 +383,17 @@ static void __init evm_init_i2c(void)
 	i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
 }
 
-static struct platform_device *dm365_evm_nand_devices[] __initdata = {
-	&davinci_nand_device,
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm365_emif_devices,
+	.num_devices	= ARRAY_SIZE(dm365_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
 };
 
 static inline int have_leds(void)
@@ -502,8 +515,7 @@ fail:
 		/* external keypad mux */
 		mux |= BIT(7);
 
-		platform_add_devices(dm365_evm_nand_devices,
-				ARRAY_SIZE(dm365_evm_nand_devices));
+		platform_device_register(&davinci_emif_device);
 	} else {
 		/* no OneNAND support yet */
 	}
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 99a6639..ad4c944 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -44,61 +44,21 @@
 #define LXT971_PHY_ID	(0x001378e2)
 #define LXT971_PHY_MASK	(0xfffffff0)
 
-static struct mtd_partition davinci_evm_norflash_partitions[] = {
-	/* bootloader (UBL, U-Boot, etc) in first 5 sectors */
-	{
-		.name		= "bootloader",
-		.offset		= 0,
-		.size		= 5 * SZ_64K,
-		.mask_flags	= MTD_WRITEABLE, /* force read-only */
-	},
-	/* bootloader params in the next 1 sectors */
-	{
-		.name		= "params",
-		.offset		= MTDPART_OFS_APPEND,
-		.size		= SZ_64K,
-		.mask_flags	= 0,
-	},
-	/* kernel */
-	{
-		.name		= "kernel",
-		.offset		= MTDPART_OFS_APPEND,
-		.size		= SZ_2M,
-		.mask_flags	= 0
-	},
-	/* file system */
-	{
-		.name		= "filesystem",
-		.offset		= MTDPART_OFS_APPEND,
-		.size		= MTDPART_SIZ_FULL,
-		.mask_flags	= 0
-	}
-};
-
-static struct physmap_flash_data davinci_evm_norflash_data = {
-	.width		= 2,
-	.parts		= davinci_evm_norflash_partitions,
-	.nr_parts	= ARRAY_SIZE(davinci_evm_norflash_partitions),
-};
-
-/* NOTE: CFI probe will correctly detect flash part as 32M, but EMIF
- * limits addresses to 16M, so using addresses past 16M will wrap */
-static struct resource davinci_evm_norflash_resource = {
-	.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
-	.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
-	.flags		= IORESOURCE_MEM,
-};
+#if defined(CONFIG_MTD_PHYSMAP) || \
+	defined(CONFIG_MTD_PHYSMAP_MODULE)
+#define HAS_NOR 1
+#else
+#define HAS_NOR 0
+#endif
 
-static struct platform_device davinci_evm_norflash_device = {
-	.name		= "physmap-flash",
-	.id		= 0,
-	.dev		= {
-		.platform_data	= &davinci_evm_norflash_data,
-	},
-	.num_resources	= 1,
-	.resource	= &davinci_evm_norflash_resource,
-};
+#if defined(CONFIG_MTD_NAND_DAVINCI) || \
+	defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
+#define HAS_NAND 1
+#else
+#define HAS_NAND 0
+#endif
 
+#if (HAS_NAND == 1)
 /* DM644x EVM includes a 64 MByte small-page NAND flash (16K blocks).
  * It may used instead of the (default) NOR chip to boot, using TI's
  * tools to install the secondary boot loader (UBL) and U-Boot.
@@ -166,15 +126,79 @@ static struct resource davinci_evm_nandflash_resource[] = {
 		.flags		= IORESOURCE_MEM,
 	},
 };
+#elif (HAS_NOR == 1)
+static struct mtd_partition davinci_evm_norflash_partitions[] = {
+	/* bootloader (UBL, U-Boot, etc) in first 5 sectors */
+	{
+		.name		= "bootloader",
+		.offset		= 0,
+		.size		= 5 * SZ_64K,
+		.mask_flags	= MTD_WRITEABLE, /* force read-only */
+	},
+	/* bootloader params in the next 1 sectors */
+	{
+		.name		= "params",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_64K,
+		.mask_flags	= 0,
+	},
+	/* kernel */
+	{
+		.name		= "kernel",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_2M,
+		.mask_flags	= 0
+	},
+	/* file system */
+	{
+		.name		= "filesystem",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= MTDPART_SIZ_FULL,
+		.mask_flags	= 0
+	}
+};
+
+static struct physmap_flash_data davinci_evm_norflash_data = {
+	.width		= 2,
+	.parts		= davinci_evm_norflash_partitions,
+	.nr_parts	= ARRAY_SIZE(davinci_evm_norflash_partitions),
+};
+
+/* NOTE: CFI probe will correctly detect flash part as 32M, but EMIF
+ * limits addresses to 16M, so using addresses past 16M will wrap */
+static struct resource davinci_evm_norflash_resource[] = {
+	{
+		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+#endif
 
-static struct platform_device davinci_evm_nandflash_device = {
-	.name		= "davinci_nand",
-	.id		= 0,
-	.dev		= {
-		.platform_data	= &davinci_evm_nandflash_data,
+static struct platform_device dm644x_emif_devices[] __initdata = {
+#if (HAS_NAND == 1)
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+		.resource		= davinci_evm_nandflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(davinci_evm_nandflash_resource),
+		.dev		= {
+			.platform_data	= &davinci_evm_nandflash_data,
+		},
 	},
-	.num_resources	= ARRAY_SIZE(davinci_evm_nandflash_resource),
-	.resource	= davinci_evm_nandflash_resource,
+#elif (HAS_NOR == 1)
+	{
+		.name		= "physmap-flash",
+		.id		= 0,
+		.resource		= davinci_evm_norflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(davinci_evm_norflash_resource),
+		.dev		= {
+			.platform_data	= &davinci_evm_norflash_data,
+		},
+	},
+#endif
 };
 
 static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
@@ -649,19 +673,19 @@ static int davinci_phy_fixup(struct phy_device *phydev)
 #define HAS_ATA 0
 #endif
 
-#if defined(CONFIG_MTD_PHYSMAP) || \
-    defined(CONFIG_MTD_PHYSMAP_MODULE)
-#define HAS_NOR 1
-#else
-#define HAS_NOR 0
-#endif
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm644x_emif_devices,
+	.num_devices	= ARRAY_SIZE(dm644x_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
+};
 
-#if defined(CONFIG_MTD_NAND_DAVINCI) || \
-    defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
-#define HAS_NAND 1
-#else
-#define HAS_NAND 0
-#endif
 
 static __init void davinci_evm_init(void)
 {
@@ -683,13 +707,12 @@ static __init void davinci_evm_init(void)
 
 		/* only one device will be jumpered and detected */
 		if (HAS_NAND) {
-			platform_device_register(&davinci_evm_nandflash_device);
 			evm_leds[7].default_trigger = "nand-disk";
 			if (HAS_NOR)
 				pr_warning("WARNING: both NAND and NOR flash "
 					"are enabled; disable one of them.\n");
-		} else if (HAS_NOR)
-			platform_device_register(&davinci_evm_norflash_device);
+		}
+		platform_device_register(&davinci_emif_device);
 	}
 
 	platform_add_devices(davinci_evm_devices,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index af55a9d..34bc4af 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -104,15 +104,29 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
+static struct platform_device dm646x_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
+	},
+};
 
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm646x_emif_devices,
+	.num_devices	= ARRAY_SIZE(dm646x_emif_devices),
+};
 
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
 	},
 };
 
@@ -782,7 +796,7 @@ static __init void evm_init(void)
 	if (machine_is_davinci_dm6467tevm())
 		davinci_nand_data.timing = &dm6467tevm_nandflash_timing;
 
-	platform_device_register(&davinci_nand_device);
+	platform_device_register(&davinci_emif_device);
 
 	dm646x_init_edma(dm646x_edma_rsv);
 
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 672d820..4e48ade 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -19,6 +19,7 @@
 #include <linux/etherdevice.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/flash.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/io.h>
 #include <asm/mach-types.h>
@@ -414,18 +415,35 @@ static struct resource mityomapl138_nandflash_resource[] = {
 	},
 };
 
-static struct platform_device mityomapl138_nandflash_device = {
-	.name		= "davinci_nand",
-	.id		= 1,
-	.dev		= {
-		.platform_data	= &mityomapl138_nandflash_data,
+static struct platform_device mityomapl138_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 1,
+
+		.resource		= mityomapl138_nandflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(mityomapl138_nandflash_resource),
+		.dev		= {
+			.platform_data	= &mityomapl138_nandflash_data,
+		},
+	},
+};
+
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= mityomapl138_emif_devices,
+	.num_devices	= ARRAY_SIZE(mityomapl138_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
 	},
-	.num_resources	= ARRAY_SIZE(mityomapl138_nandflash_resource),
-	.resource	= mityomapl138_nandflash_resource,
 };
 
 static struct platform_device *mityomapl138_devices[] __initdata = {
-	&mityomapl138_nandflash_device,
+	&davinci_emif_device,
 };
 
 static void __init mityomapl138_setup_nand(void)
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index 8d34f51..c1c6fa1 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -26,6 +26,7 @@
 #include <linux/platform_device.h>
 #include <linux/gpio.h>
 #include <linux/mtd/partitions.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
index 31da3c5..ac36320 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -30,6 +30,7 @@
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -81,14 +82,31 @@ static struct resource davinci_sffsdr_nandflash_resource[] = {
 	},
 };
 
-static struct platform_device davinci_sffsdr_nandflash_device = {
-	.name		= "davinci_nand", /* Name of driver */
-	.id		= 0,
-	.dev		= {
-		.platform_data	= &davinci_sffsdr_nandflash_data,
+static struct platform_device davinci_sffsdr_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_sffsdr_nandflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(davinci_sffsdr_nandflash_resource),
+		.dev		= {
+			.platform_data	= &davinci_sffsdr_nandflash_data,
+		},
+	},
+};
+
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= davinci_sffsdr_emif_devices,
+	.num_devices	= ARRAY_SIZE(davinci_sffsdr_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
 	},
-	.num_resources	= ARRAY_SIZE(davinci_sffsdr_nandflash_resource),
-	.resource	= davinci_sffsdr_nandflash_resource,
 };
 
 static struct at24_platform_data eeprom_info = {
@@ -121,7 +139,7 @@ static void __init sffsdr_init_i2c(void)
 }
 
 static struct platform_device *davinci_sffsdr_devices[] __initdata = {
-	&davinci_sffsdr_nandflash_device,
+	&davinci_emif_device,
 };
 
 static struct davinci_uart_config uart_config __initdata = {
-- 
1.7.1


From FlorianSchandinat at gmx.de  Mon Feb 13 15:27:15 2012
From: FlorianSchandinat at gmx.de (Florian Tobias Schandinat)
Date: Mon, 13 Feb 2012 21:27:15 +0000
Subject: [PATCH] video: da8xx-fb: Fix build warning on unused label
In-Reply-To: <1328763879-16345-1-git-send-email-prakash.pm@ti.com>
References: <1328763879-16345-1-git-send-email-prakash.pm@ti.com>
Message-ID: <4F398033.80900@gmx.de>

On 02/09/2012 05:04 AM, Manjunathappa, Prakash wrote:
> Patch fixes build warning on label "err_cpu_freq" when CONFIG_CPU_FREQ
> is not defined.
> 
> Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>

Applied.


Thanks,

Florian Tobias Schandinat

> ---
>  drivers/video/da8xx-fb.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index 29577bf..f360d62 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -1264,8 +1264,8 @@ static int __devinit fb_probe(struct platform_device *device)
>  irq_freq:
>  #ifdef CONFIG_CPU_FREQ
>  	lcd_da8xx_cpufreq_deregister(par);
> -#endif
>  err_cpu_freq:
> +#endif
>  	unregister_framebuffer(da8xx_fb_info);
>  
>  err_dealloc_cmap:


From FlorianSchandinat at gmx.de  Mon Feb 13 15:28:06 2012
From: FlorianSchandinat at gmx.de (Florian Tobias Schandinat)
Date: Mon, 13 Feb 2012 21:28:06 +0000
Subject: [PATCH v2] video:da8xx-fb: calculate pixel clock period for the
	panel
In-Reply-To: <1328768646-25169-1-git-send-email-prakash.pm@ti.com>
References: <1328768646-25169-1-git-send-email-prakash.pm@ti.com>
Message-ID: <4F398066.1050602@gmx.de>

On 02/09/2012 06:24 AM, Manjunathappa, Prakash wrote:
> Patch calculates pixel clock period in pico seconds and updates
> the same in variable screen information structure. fbset utility
> uses this information.
> 
> Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>

Applied.


Thanks,

Florian Tobias Schandinat

> ---
> Since v1:
> Fixed the spelling mistake.
> 
>  drivers/video/da8xx-fb.c |   19 ++++++++++++++++++-
>  1 files changed, 18 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index f360d62..882dd67 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -32,6 +32,7 @@
>  #include <linux/console.h>
>  #include <linux/slab.h>
>  #include <video/da8xx-fb.h>
> +#include <asm/div64.h>
>  
>  #define DRIVER_NAME "da8xx_lcdc"
>  
> @@ -174,7 +175,6 @@ static struct fb_var_screeninfo da8xx_fb_var __devinitdata = {
>  	.activate = 0,
>  	.height = -1,
>  	.width = -1,
> -	.pixclock = 46666,	/* 46us - AUO display */
>  	.accel_flags = 0,
>  	.left_margin = LEFT_MARGIN,
>  	.right_margin = RIGHT_MARGIN,
> @@ -1048,6 +1048,22 @@ static struct fb_ops da8xx_fb_ops = {
>  	.fb_blank = cfb_blank,
>  };
>  
> +/* Calculate and return pixel clock period in pico seconds */
> +static unsigned int da8xxfb_pixel_clk_period(struct da8xx_fb_par *par)
> +{
> +	unsigned int lcd_clk, div;
> +	unsigned int configured_pix_clk;
> +	unsigned long long pix_clk_period_picosec = 1000000000000ULL;
> +
> +	lcd_clk = clk_get_rate(par->lcdc_clk);
> +	div = lcd_clk / par->pxl_clk;
> +	configured_pix_clk = (lcd_clk / div);
> +
> +	do_div(pix_clk_period_picosec, configured_pix_clk);
> +
> +	return pix_clk_period_picosec;
> +}
> +
>  static int __devinit fb_probe(struct platform_device *device)
>  {
>  	struct da8xx_lcdc_platform_data *fb_pdata =
> @@ -1209,6 +1225,7 @@ static int __devinit fb_probe(struct platform_device *device)
>  
>  	da8xx_fb_var.hsync_len = lcdc_info->hsw;
>  	da8xx_fb_var.vsync_len = lcdc_info->vsw;
> +	da8xx_fb_var.pixclock = da8xxfb_pixel_clk_period(par);
>  
>  	/* Initialize fbinfo */
>  	da8xx_fb_info->flags = FBINFO_FLAG_DEFAULT;


From ben-i2c at fluff.org  Mon Feb 13 17:37:26 2012
From: ben-i2c at fluff.org (Ben Dooks)
Date: Mon, 13 Feb 2012 23:37:26 +0000
Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
In-Reply-To: <1327308967-8092-6-git-send-email-hs@denx.de>
References: <1327308967-8092-1-git-send-email-hs@denx.de>
	<1327308967-8092-6-git-send-email-hs@denx.de>
Message-ID: <20120213233726.GK2999@freya.fluff.org>

On Mon, Jan 23, 2012 at 09:56:05AM +0100, Heiko Schocher wrote:
> add of support for the davinci i2c driver.
> 
> Signed-off-by: Heiko Schocher <hs at denx.de>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-i2c at vger.kernel.org
> Cc: Ben Dooks <ben-linux at fluff.org>
> Cc: Wolfram Sang <w.sang at pengutronix.de>
> Cc: Grant Likely <grant.likely at secretlab.ca>
> Cc: Sekhar Nori <nsekhar at ti.com>
> Cc: Wolfgang Denk <wd at denx.de>
> ---
>  .../devicetree/bindings/arm/davinci/i2c.txt        |   39 ++++++++++++++++++
>  drivers/i2c/busses/i2c-davinci.c                   |   43 ++++++++++++++++++++
>  2 files changed, 82 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> new file mode 100644
> index 0000000..94ec670
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> @@ -0,0 +1,39 @@
> +* Texas Instruments Davinci I2C
> +
> +This file provides information, what the device node for the
> +davinci i2c interface contain.
> +
> +Required properties:
> +- compatible: "ti,davinci-i2c";
> +- reg : Offset and length of the register set for the device
> +- id: id of the controller
> +
> +Recommended properties :
> +- interrupts : <a b> where a is the interrupt number and b is a
> +  field that represents an encoding of the sense and level
> +  information for the interrupt.
> +- interrupt-parent : the phandle for the interrupt controller that
> +  services interrupts for this device.
> +- clock-frequency : desired I2C bus clock frequency in Hz.

> +Optional properties:
> +- bus-delay: bus delay in usec

bus_delay sounds rather like frequency in a different name, what is it for?

 +- pinmux-handle: Contains a handle to configure the pinmux settings.
> +
> +Example (enbw_cmc board):
> +	i2c at 1c22000 {
> +		compatible = "ti,davinci-i2c";
> +		reg = <0x22000 0x1000>;
> +		clock-frequency = <100000>;
> +		interrupts = <15 2>;
> +		interrupt-parent = <&intc>;
> +		id = <1>;
> +		pinmux-handle = <&i2c1_pins>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		dtt at 48 {
> +				compatible = "national,lm75";
> +				reg = <0x48>;
> +			};
> +	};
> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
> index a76d85f..6f59fae 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -38,9 +38,12 @@
>  #include <linux/slab.h>
>  #include <linux/cpufreq.h>
>  #include <linux/gpio.h>
> +#include <linux/of_i2c.h>
> +#include <linux/of_device.h>
>  
>  #include <mach/hardware.h>
>  #include <mach/i2c.h>
> +#include <mach/mux.h>
>  
>  /* ----- global defines ----------------------------------------------- */
>  
> @@ -635,6 +638,16 @@ static struct i2c_algorithm i2c_davinci_algo = {
>  	.functionality	= i2c_davinci_func,
>  };
>  
> +#if defined(CONFIG_OF)
> +static const struct of_device_id davinci_i2c_of_match[] = {
> +	{.compatible = "ti,davinci-i2c", },
> +	{},
> +}
> +MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
> +#else
> +#define davinci_i2c_of_match NULL
> +#endif

see of_match_ptr() and you won't need the #else.

>  static int davinci_i2c_probe(struct platform_device *pdev)
>  {
>  	struct davinci_i2c_dev *dev;
> @@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev)
>  	dev->irq = irq->start;
>  	platform_set_drvdata(pdev, dev);
>  
> +	if ((dev->dev->platform_data == NULL) &&
> +		(pdev->dev.of_node)) {

If there's platform_data an of_node, what happens then?

> +		struct device_node *pinmux_np;
> +		struct davinci_i2c_platform_data *pdata;
> +		u32 prop;
> +
> +		dev->dev->platform_data = &davinci_i2c_platform_data_default;
> +		pdata = &davinci_i2c_platform_data_default;
> +		if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
> +			&prop))
> +			pdata->bus_freq = prop / 1000;
> +		if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
> +			&prop))
> +			pdata->bus_delay = prop;
> +		if (!of_property_read_u32(pdev->dev.of_node, "id",
> +			&prop)) {
> +			pdev->id = prop;
> +			pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
> +			sprintf((char *)pdev->dev.init_name,
> +				"i2c_davinci.%d", pdev->id);
> +		}

Is this _really_ necessary, looks a bit of a hack to me.

> +		pinmux_np = of_parse_phandle(pdev->dev.of_node,
> +				"pinmux-handle", 0);
> +		if (pinmux_np)
> +			davinci_cfg_reg_of(pinmux_np);
> +	}
>  	dev->clk = clk_get(&pdev->dev, NULL);
> +
>  	if (IS_ERR(dev->clk)) {
>  		r = -ENODEV;
>  		goto err_free_mem;
> @@ -711,6 +751,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
>  	adap->algo = &i2c_davinci_algo;
>  	adap->dev.parent = &pdev->dev;
>  	adap->timeout = DAVINCI_I2C_TIMEOUT;
> +	adap->dev.of_node = pdev->dev.of_node;
>  
>  	adap->nr = pdev->id;
>  	r = i2c_add_numbered_adapter(adap);
> @@ -718,6 +759,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
>  		dev_err(&pdev->dev, "failure adding adapter\n");
>  		goto err_free_irq;
>  	}
> +	of_i2c_register_devices(adap);
>  
>  	return 0;
>  
> @@ -809,6 +851,7 @@ static struct platform_driver davinci_i2c_driver = {
>  		.name	= "i2c_davinci",
>  		.owner	= THIS_MODULE,
>  		.pm	= davinci_i2c_pm_ops,
> +		.of_match_table = davinci_i2c_of_match,
>  	},
>  };
>  
> -- 
> 1.7.7.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

From hs at denx.de  Tue Feb 14 01:15:25 2012
From: hs at denx.de (Heiko Schocher)
Date: Tue, 14 Feb 2012 08:15:25 +0100
Subject: [RFC PATCH 1/7] ARM: davinci,
	intc: Add OF support for TI interrupt controller
In-Reply-To: <4F2F74DB.7010604@denx.de>
References: <1327308967-8092-1-git-send-email-hs@denx.de>
	<1327308967-8092-2-git-send-email-hs@denx.de>
	<20120202045459.GI15343@ponder.secretlab.ca> <4F2F74DB.7010604@denx.de>
Message-ID: <4F3A0A0D.3060005@denx.de>

Hello Grant,

Heiko Schocher wrote:
> Hello Grant,
> 
> Grant Likely wrote:
>> On Mon, Jan 23, 2012 at 09:56:01AM +0100, Heiko Schocher wrote:
>>> Add a function to initialize the davinci interrupt controller (INTC)
>>> using a device tree node.
>>>
>>> Signed-off-by: Heiko Schocher <hs at denx.de>
>>> Cc: davinci-linux-open-source at linux.davincidsp.com
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: devicetree-discuss at lists.ozlabs.org
>>> Cc: Grant Likely <grant.likely at secretlab.ca>
>>> Cc: Sekhar Nori <nsekhar at ti.com>
>>> Cc: Wolfgang Denk <wd at denx.de>
>>> ---
>>>  .../devicetree/bindings/arm/davinci/intc.txt       |   26 ++++++++++
>>>  arch/arm/mach-davinci/cp_intc.c                    |   51 ++++++++++++++++++++
>>>  arch/arm/mach-davinci/include/mach/cp_intc.h       |    1 +
>>>  3 files changed, 78 insertions(+), 0 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt
> [...]
>>> diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
>>> index f83152d..2c6e2e4 100644
>>> --- a/arch/arm/mach-davinci/cp_intc.c
>>> +++ b/arch/arm/mach-davinci/cp_intc.c
> [...]
>>> +	cp_intc_init();
>>> +	irq_domain_add_simple(node, 0);
>> Take a look at the irq_domain patches that will be (probably) merged
>> in v3.4.  Instead of calling irq_domain_add_simple(), you should
>> migrate the whole interrupt controller to natively use an irq_domain
>> for hwirq <--> irq mapping.
> 
> I rebased my hole patchset to:
> 
> git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
> and reworked the arch/arm/mach-davinci/cp_intc.c irq driver to use
> irq_domain, works good on the enbw_cmc board :-)
> 
> Waiting for your comment to my question to the
> [RFC PATCH 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
> patch, see:
> http://www.mail-archive.com/linux-i2c at vger.kernel.org/msg07132.html
> 
> and resend the hole reworked patchserie. Is it OK, if I use the above
> branch as base for sending this patchserie, or should I use another
> tree/branch for it?

Ping?

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

From hs at denx.de  Tue Feb 14 01:16:40 2012
From: hs at denx.de (Heiko Schocher)
Date: Tue, 14 Feb 2012 08:16:40 +0100
Subject: [RFC PATCH 5/7] ARM: davinci: i2c: add OF support
In-Reply-To: <20120213233726.GK2999@freya.fluff.org>
References: <1327308967-8092-1-git-send-email-hs@denx.de>
	<1327308967-8092-6-git-send-email-hs@denx.de>
	<20120213233726.GK2999@freya.fluff.org>
Message-ID: <4F3A0A58.5030707@denx.de>

Hello Ben,

Ben Dooks wrote:
> On Mon, Jan 23, 2012 at 09:56:05AM +0100, Heiko Schocher wrote:
>> add of support for the davinci i2c driver.
>>
>> Signed-off-by: Heiko Schocher <hs at denx.de>
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree-discuss at lists.ozlabs.org
>> Cc: linux-i2c at vger.kernel.org
>> Cc: Ben Dooks <ben-linux at fluff.org>
>> Cc: Wolfram Sang <w.sang at pengutronix.de>
>> Cc: Grant Likely <grant.likely at secretlab.ca>
>> Cc: Sekhar Nori <nsekhar at ti.com>
>> Cc: Wolfgang Denk <wd at denx.de>
>> ---
>>  .../devicetree/bindings/arm/davinci/i2c.txt        |   39 ++++++++++++++++++
>>  drivers/i2c/busses/i2c-davinci.c                   |   43 ++++++++++++++++++++
>>  2 files changed, 82 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
>> new file mode 100644
>> index 0000000..94ec670
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
[...]
>> +Optional properties:
>> +- bus-delay: bus delay in usec
> 
> bus_delay sounds rather like frequency in a different name, what is it for?

from drivers/i2c/busses/i2c-davinci.c i2c_davinci_xfer_msg():

        /* Introduce a delay, required for some boards (e.g Davinci EVM) */
        if (pdata->bus_delay)
                udelay(pdata->bus_delay);

so I added this option to OF support too, but I do not know more about
this "feature" ...

[...]
>> diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
>> index a76d85f..6f59fae 100644
>> --- a/drivers/i2c/busses/i2c-davinci.c
>> +++ b/drivers/i2c/busses/i2c-davinci.c
>> @@ -38,9 +38,12 @@
[...]
>> +MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
>> +#else
>> +#define davinci_i2c_of_match NULL
>> +#endif
> 
> see of_match_ptr() and you won't need the #else.

Yep, already fixed, as Grant Likely commented.

>>  static int davinci_i2c_probe(struct platform_device *pdev)
>>  {
>>  	struct davinci_i2c_dev *dev;
>> @@ -676,7 +689,34 @@ static int davinci_i2c_probe(struct platform_device *pdev)
>>  	dev->irq = irq->start;
>>  	platform_set_drvdata(pdev, dev);
>>  
>> +	if ((dev->dev->platform_data == NULL) &&
>> +		(pdev->dev.of_node)) {
> 
> If there's platform_data an of_node, what happens then?

Then platform_data is used.

>> +		struct device_node *pinmux_np;
>> +		struct davinci_i2c_platform_data *pdata;
>> +		u32 prop;
>> +
>> +		dev->dev->platform_data = &davinci_i2c_platform_data_default;
>> +		pdata = &davinci_i2c_platform_data_default;
>> +		if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
>> +			&prop))
>> +			pdata->bus_freq = prop / 1000;
>> +		if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
>> +			&prop))
>> +			pdata->bus_delay = prop;
>> +		if (!of_property_read_u32(pdev->dev.of_node, "id",
>> +			&prop)) {
>> +			pdev->id = prop;
>> +			pdev->dev.init_name = kzalloc(20, GFP_KERNEL);
>> +			sprintf((char *)pdev->dev.init_name,
>> +				"i2c_davinci.%d", pdev->id);
>> +		}
> 
> Is this _really_ necessary, looks a bit of a hack to me.

Yep, "id" completely removed, as Grant Likely commented too.

[...]

Thanks for looking through this. Posting v2 soon.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

From andre at bluewatersys.com  Sun Feb 19 19:18:28 2012
From: andre at bluewatersys.com (Andre Renaud)
Date: Mon, 20 Feb 2012 14:18:28 +1300
Subject: DM355/DM365/DM368 suspend support
Message-ID: <4F419F64.6070601@bluewatersys.com>

Hello,
Can anyone tell me the status of the DM36X suspend support in Linux at
the moment? From what I can see detailed at
http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Power_Management
and from the Linux kernel code, it would appear that there is currently
only support for the DA850 and OMAP-L138.

Is anyone working on this, or any out-of-tree patches available to test
this functionality?

Regards,
Andre

From nsekhar at ti.com  Mon Feb 20 07:31:54 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 20 Feb 2012 13:31:54 +0000
Subject: [PATCH v7 2/8] ARM: davinci: create new common platform header
	for	davinci
In-Reply-To: <1324475021-32509-3-git-send-email-manjunath.hadli@ti.com>
References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com>
	<1324475021-32509-3-git-send-email-manjunath.hadli@ti.com>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317C78B6@DBDE01.ent.ti.com>

Hi Manju,

On Wed, Dec 21, 2011 at 19:13:35, Hadli, Manjunath wrote:
> remove individual platform header files for dm365, dm355, dm644x
> and dm646x and consolidate it into a single and common
> header file davinci.h placed in arch/arm/mach-davinci.
> 
> This reduces the pollution in the include/mach and is consistent
> with Russel's suggestions as part of his "pet peaves" mail.

While committing this patch, I fixed Russell's name and added
a link to his post.

> 
> The further patches in the series take  advantage of this consolidation
> for easy implementation of IO_ADDRESS elimination.
> 
> Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>

> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
> index 635bf77..123bea8 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -36,7 +36,6 @@
>  #include <asm/mach-types.h>
>  #include <asm/mach/arch.h>
>  
> -#include <mach/dm646x.h>
>  #include <mach/common.h>
>  #include <mach/serial.h>
>  #include <mach/i2c.h>
> @@ -46,6 +45,7 @@
>  #include <mach/aemif.h>
>  
>  #include "clock.h"
> +#include "davinci.h"

In cases where multiple local include files are present,
I modified the patch to make davinci.h the first include
file. I did this to keep the new include order closer
to the original order.

> diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
> new file mode 100644
> index 0000000..238c282
> --- /dev/null
> +++ b/arch/arm/mach-davinci/davinci.h
> @@ -0,0 +1,85 @@
> +/*
> + * This file contains the processor specific definitions
> + * of the TI DM644x, DM355, DM365, and DM646x.
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated

Deep Root Systems had a copyright on one of the files
this code is derived from. I restored the copyright of
Deep Root Systems in the file.

[...]

> +/* DM355 function declarations */
> +struct spi_board_info;

I saw no reason to maintain a forward declaration like this.
I included linux/spi/spi.h in this file instead.

I am making these changes myself since I was delayed in getting
back to you and also since you have already spun 7 versions of
this. I figured you must be getting tired already ;-)

I will push the code to a branch on my tree, please give it a
good test.

Thanks,
Sekhar


From nsekhar at ti.com  Mon Feb 20 08:19:29 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 20 Feb 2012 14:19:29 +0000
Subject: [PATCH v7 3/8] davinci: eliminate use of IO_ADDRESS() on sysmod
In-Reply-To: <1324475021-32509-4-git-send-email-manjunath.hadli@ti.com>
References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com>
	<1324475021-32509-4-git-send-email-manjunath.hadli@ti.com>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317C7996@DBDE01.ent.ti.com>

Hi Manju,

On Wed, Dec 21, 2011 at 19:13:36, Hadli, Manjunath wrote:
> Current devices.c file has a number of instances where
> IO_ADDRESS() is used for system module register

You seemed to have limited yourself to devices.c, but there
is one more IO_ADDRESS() usage in dm646x.c which can also be
eliminated with the change you are making in this patch.
I included that clean-up too in this patch.

> access. Eliminate this in favor of a ioremap()
> based access.

Along with IO_ADDRESS() I also found some VPIF specific registers
in system module were being ioremapped separately in DM646x EVM code.
I included fixing that into this patch as well.

I also found duplicate system module register offsets definitions
in code so I consolidated system module register offsets in davinci.h.

> 
> Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>

Arnd had acked one of the earlier versions of this patch.
Please carry forward the acks you receive on previous versions
of the patch (unless the patch is now doing something totally
different). Otherwise, there is no way for a person like me
to add the proper acks before committing.

> ---
>  arch/arm/mach-davinci/davinci.h               |    9 +++++++++
>  arch/arm/mach-davinci/devices.c               |   25 ++++++++++++++++---------
>  arch/arm/mach-davinci/dm355.c                 |    1 +
>  arch/arm/mach-davinci/dm365.c                 |    1 +
>  arch/arm/mach-davinci/dm644x.c                |    1 +
>  arch/arm/mach-davinci/dm646x.c                |    1 +
>  arch/arm/mach-davinci/include/mach/hardware.h |    2 --
>  7 files changed, 29 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
> index 238c282..065b3a0 100644
> --- a/arch/arm/mach-davinci/davinci.h
> +++ b/arch/arm/mach-davinci/davinci.h
> @@ -23,10 +23,19 @@
>  
>  #include <mach/asp.h>
>  #include <mach/keyscan.h>
> +#include <mach/hardware.h>
>  
>  #include <media/davinci/vpfe_capture.h>
>  #include <media/davinci/vpif_types.h>
>  
> +#define DAVINCI_SYSTEM_MODULE_BASE        0x01c40000
> +
> +#ifndef __ASSEMBLER__
> +extern void __iomem *davinci_sysmodbase;
> +#define DAVINCI_SYSMODULE_VIRT(x)	(davinci_sysmodbase + (x))
> +void davinci_map_sysmod(void);
> +#endif

I couldn't see the reason why ifndef __ASSEMBLER__ is required here
I don't see this file being included in any assembly file. So, I have
removed it in my commit.

> diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
> index 806a2f0..faff29a 100644
> --- a/arch/arm/mach-davinci/devices.c
> +++ b/arch/arm/mach-davinci/devices.c
> @@ -23,6 +23,7 @@
>  #include <mach/mmc.h>
>  #include <mach/time.h>
>  
> +#include "davinci.h"
>  #include "clock.h"
>  
>  #define DAVINCI_I2C_BASE	     0x01C21000
> @@ -36,6 +37,14 @@
>  /* System control register offsets */
>  #define DM64XX_VDD3P3V_PWDN	0x48
>  
> +void __iomem  *davinci_sysmodbase;
> +
> +void davinci_map_sysmod(void)
> +{
> +	davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
> +	WARN_ON(!davinci_sysmodbase);

I converted this to a bug since this is something basic
for SoC initialization and I did not see a point in going
ahead and failing elsewhere. I also think ioremap() failing
this early in system boot needs attention anyway. I have
included these reasons in a comment above the BUG_ON().

With  these items fixed, here is the updated patch.

Thanks,
Sekhar
----8<-----
commit 0180a7edde29929e36b97ca8493bf35b3e39a6dc
Author:     Manjunath Hadli <manjunath.hadli at ti.com>
AuthorDate: Wed Dec 21 19:13:36 2011 +0530
Commit:     Sekhar Nori <nsekhar at ti.com>
CommitDate: Mon Feb 20 19:38:03 2012 +0530

    ARM: davinci: streamline sysmod access
    
    There are instances of IO_ADDRESS() being used for system module
    (sysmod) register access. Eliminate this in favor of a ioremap()
    based access. ioremap() the entire sysmod address space once during
    boot-up and provide a helper macro to access specific register
    offsets within the address space.
    
    With this, also eliminate ioremap() of specific sysmodule registers
    related to VPIF happening in DM646x EVM code.
    
    While at it, also eliminate some duplicate sysmod register offset macros
    defined in code and place offset definitions at one place in davinci.h
    
    Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>
    Acked-by: Arnd Bergmann <arnd at arndb.de>
    [nsekhar at ti.com: removed the addition of ifndef __ASSEMBLER__
    in davinci.h, eliminate IO_ADDRESS() usage left out in dm646x.c,
    cleanup VPIF sysmodule register access as part of this patch and
    keep all sysmod offsets in davinci.h Also, convert the WARN_ON()
    on failure to setup sysmod base to BUG_ON()]
    Signed-off-by: Sekhar Nori <nsekhar at ti.com>

diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 74ae0c4..9468904 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -410,8 +410,6 @@ static struct davinci_i2c_platform_data i2c_pdata = {
 	.bus_delay      = 0 /* usec */,
 };
 
-#define VIDCLKCTL_OFFSET	(DAVINCI_SYSTEM_MODULE_BASE + 0x38)
-#define VSCLKDIS_OFFSET		(DAVINCI_SYSTEM_MODULE_BASE + 0x6c)
 #define VCH2CLK_MASK		(BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
 #define VCH2CLK_SYSCLK8		(BIT(9))
 #define VCH2CLK_AUXCLK		(BIT(9) | BIT(8))
@@ -429,8 +427,6 @@ static struct davinci_i2c_platform_data i2c_pdata = {
 #define TVP5147_CH0		"tvp514x-0"
 #define TVP5147_CH1		"tvp514x-1"
 
-static void __iomem *vpif_vidclkctl_reg;
-static void __iomem *vpif_vsclkdis_reg;
 /* spin lock for updating above registers */
 static spinlock_t vpif_reg_lock;
 
@@ -441,14 +437,14 @@ static int set_vpif_clock(int mux_mode, int hd)
 	int val = 0;
 	int err = 0;
 
-	if (!vpif_vidclkctl_reg || !vpif_vsclkdis_reg || !cpld_client)
+	if (!cpld_client)
 		return -ENXIO;
 
 	/* disable the clock */
 	spin_lock_irqsave(&vpif_reg_lock, flags);
-	value = __raw_readl(vpif_vsclkdis_reg);
+	value = __raw_readl(DAVINCI_SYSMOD_VIRT(SYSMOD_VSCLKDIS));
 	value |= (VIDCH3CLK | VIDCH2CLK);
-	__raw_writel(value, vpif_vsclkdis_reg);
+	__raw_writel(value, DAVINCI_SYSMOD_VIRT(SYSMOD_VSCLKDIS));
 	spin_unlock_irqrestore(&vpif_reg_lock, flags);
 
 	val = i2c_smbus_read_byte(cpld_client);
@@ -464,7 +460,7 @@ static int set_vpif_clock(int mux_mode, int hd)
 	if (err)
 		return err;
 
-	value = __raw_readl(vpif_vidclkctl_reg);
+	value = __raw_readl(DAVINCI_SYSMOD_VIRT(SYSMOD_VIDCLKCTL));
 	value &= ~(VCH2CLK_MASK);
 	value &= ~(VCH3CLK_MASK);
 
@@ -473,13 +469,13 @@ static int set_vpif_clock(int mux_mode, int hd)
 	else
 		value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
 
-	__raw_writel(value, vpif_vidclkctl_reg);
+	__raw_writel(value, DAVINCI_SYSMOD_VIRT(SYSMOD_VIDCLKCTL));
 
 	spin_lock_irqsave(&vpif_reg_lock, flags);
-	value = __raw_readl(vpif_vsclkdis_reg);
+	value = __raw_readl(DAVINCI_SYSMOD_VIRT(SYSMOD_VSCLKDIS));
 	/* enable the clock */
 	value &= ~(VIDCH3CLK | VIDCH2CLK);
-	__raw_writel(value, vpif_vsclkdis_reg);
+	__raw_writel(value, DAVINCI_SYSMOD_VIRT(SYSMOD_VSCLKDIS));
 	spin_unlock_irqrestore(&vpif_reg_lock, flags);
 
 	return 0;
@@ -564,7 +560,7 @@ static int setup_vpif_input_channel_mode(int mux_mode)
 	int val;
 	u32 value;
 
-	if (!vpif_vidclkctl_reg || !cpld_client)
+	if (!cpld_client)
 		return -ENXIO;
 
 	val = i2c_smbus_read_byte(cpld_client);
@@ -572,7 +568,7 @@ static int setup_vpif_input_channel_mode(int mux_mode)
 		return val;
 
 	spin_lock_irqsave(&vpif_reg_lock, flags);
-	value = __raw_readl(vpif_vidclkctl_reg);
+	value = __raw_readl(DAVINCI_SYSMOD_VIRT(SYSMOD_VIDCLKCTL));
 	if (mux_mode) {
 		val &= VPIF_INPUT_TWO_CHANNEL;
 		value |= VIDCH1CLK;
@@ -580,7 +576,7 @@ static int setup_vpif_input_channel_mode(int mux_mode)
 		val |= VPIF_INPUT_ONE_CHANNEL;
 		value &= ~VIDCH1CLK;
 	}
-	__raw_writel(value, vpif_vidclkctl_reg);
+	__raw_writel(value, DAVINCI_SYSMOD_VIRT(SYSMOD_VIDCLKCTL));
 	spin_unlock_irqrestore(&vpif_reg_lock, flags);
 
 	err = i2c_smbus_write_byte(cpld_client, val);
@@ -674,12 +670,6 @@ static struct vpif_capture_config dm646x_vpif_capture_cfg = {
 
 static void __init evm_init_video(void)
 {
-	vpif_vidclkctl_reg = ioremap(VIDCLKCTL_OFFSET, 4);
-	vpif_vsclkdis_reg = ioremap(VSCLKDIS_OFFSET, 4);
-	if (!vpif_vidclkctl_reg || !vpif_vsclkdis_reg) {
-		pr_err("Can't map VPIF VIDCLKCTL or VSCLKDIS registers\n");
-		return;
-	}
 	spin_lock_init(&vpif_reg_lock);
 
 	dm646x_setup_vpif(&dm646x_vpif_display_config,
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 5e4f85e..b1a52fb 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -25,10 +25,21 @@
 
 #include <mach/asp.h>
 #include <mach/keyscan.h>
+#include <mach/hardware.h>
 
 #include <media/davinci/vpfe_capture.h>
 #include <media/davinci/vpif_types.h>
 
+#define DAVINCI_SYSTEM_MODULE_BASE	0x01c40000
+#define SYSMOD_VIDCLKCTL		0x38
+#define SYSMOD_VDD3P3VPWDN		0x48
+#define SYSMOD_VSCLKDIS			0x6c
+#define SYSMOD_PUPDCTL1			0x7c
+
+extern void __iomem *davinci_sysmod_base;
+#define DAVINCI_SYSMOD_VIRT(x)	(davinci_sysmod_base + (x))
+void davinci_map_sysmod(void);
+
 /* DM355 base addresses */
 #define DM355_ASYNC_EMIF_CONTROL_BASE	0x01e10000
 #define DM355_ASYNC_EMIF_DATA_CE0_BASE	0x02000000
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 50c0156..d2f9666 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -23,6 +23,7 @@
 #include <mach/mmc.h>
 #include <mach/time.h>
 
+#include "davinci.h"
 #include "clock.h"
 
 #define DAVINCI_I2C_BASE	     0x01C21000
@@ -33,8 +34,19 @@
 #define DM365_MMCSD0_BASE	     0x01D11000
 #define DM365_MMCSD1_BASE	     0x01D00000
 
-/* System control register offsets */
-#define DM64XX_VDD3P3V_PWDN	0x48
+void __iomem  *davinci_sysmod_base;
+
+void davinci_map_sysmod(void)
+{
+	davinci_sysmod_base = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE,
+					      0x800);
+	/*
+	 * Throw a bug since a lot of board initialization code depends
+	 * on system module availability. ioremap() failing this early
+	 * need careful looking into anyway.
+	 */
+	BUG_ON(!davinci_sysmod_base);
+}
 
 static struct resource i2c_resources[] = {
 	{
@@ -212,12 +224,12 @@ void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config)
 			davinci_cfg_reg(DM355_SD1_DATA2);
 			davinci_cfg_reg(DM355_SD1_DATA3);
 		} else if (cpu_is_davinci_dm365()) {
-			void __iomem *pupdctl1 =
-				IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c);
-
 			/* Configure pull down control */
-			__raw_writel((__raw_readl(pupdctl1) & ~0xfc0),
-					pupdctl1);
+			unsigned v;
+
+			v = __raw_readl(DAVINCI_SYSMOD_VIRT(SYSMOD_PUPDCTL1));
+			__raw_writel(v & ~0xfc0,
+					DAVINCI_SYSMOD_VIRT(SYSMOD_PUPDCTL1));
 
 			mmcsd1_resources[0].start = DM365_MMCSD1_BASE;
 			mmcsd1_resources[0].end = DM365_MMCSD1_BASE +
@@ -246,11 +258,9 @@ void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config)
 			mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
 		} else if (cpu_is_davinci_dm644x()) {
 			/* REVISIT: should this be in board-init code? */
-			void __iomem *base =
-				IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
-
 			/* Power-on 3.3V IO cells */
-			__raw_writel(0, base + DM64XX_VDD3P3V_PWDN);
+			__raw_writel(0,
+				DAVINCI_SYSMOD_VIRT(SYSMOD_VDD3P3VPWDN));
 			/*Set up the pull regiter for MMC */
 			davinci_cfg_reg(DM644X_MSTK);
 		}
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 0b0d41c..fd3d09a 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -871,6 +871,7 @@ void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata)
 void __init dm355_init(void)
 {
 	davinci_common_init(&davinci_soc_info_dm355);
+	davinci_map_sysmod();
 }
 
 static int __init dm355_init_devices(void)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index d831d94..1a2e953 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1138,6 +1138,7 @@ void __init dm365_init_rtc(void)
 void __init dm365_init(void)
 {
 	davinci_common_init(&davinci_soc_info_dm365);
+	davinci_map_sysmod();
 }
 
 static struct resource dm365_vpss_resources[] = {
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index c6f47c6..bf14ec0 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -786,6 +786,7 @@ void __init dm644x_init_asp(struct snd_platform_data *pdata)
 void __init dm644x_init(void)
 {
 	davinci_common_init(&davinci_soc_info_dm644x);
+	davinci_map_sysmod();
 }
 
 static int __init dm644x_init_devices(void)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 3b84195..9eb87c1 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -32,8 +32,6 @@
 #include "mux.h"
 
 #define DAVINCI_VPIF_BASE       (0x01C12000)
-#define VDD3P3V_PWDN_OFFSET	(0x48)
-#define VSCLKDIS_OFFSET		(0x6C)
 
 #define VDD3P3V_VID_MASK	(BIT_MASK(3) | BIT_MASK(2) | BIT_MASK(1) |\
 					BIT_MASK(0))
@@ -880,15 +878,14 @@ void dm646x_setup_vpif(struct vpif_display_config *display_config,
 		       struct vpif_capture_config *capture_config)
 {
 	unsigned int value;
-	void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
 
-	value = __raw_readl(base + VSCLKDIS_OFFSET);
+	value = __raw_readl(DAVINCI_SYSMOD_VIRT(SYSMOD_VSCLKDIS));
 	value &= ~VSCLKDIS_MASK;
-	__raw_writel(value, base + VSCLKDIS_OFFSET);
+	__raw_writel(value, DAVINCI_SYSMOD_VIRT(SYSMOD_VSCLKDIS));
 
-	value = __raw_readl(base + VDD3P3V_PWDN_OFFSET);
+	value = __raw_readl(DAVINCI_SYSMOD_VIRT(SYSMOD_VDD3P3VPWDN));
 	value &= ~VDD3P3V_VID_MASK;
-	__raw_writel(value, base + VDD3P3V_PWDN_OFFSET);
+	__raw_writel(value, DAVINCI_SYSMOD_VIRT(SYSMOD_VDD3P3VPWDN));
 
 	davinci_cfg_reg(DM646X_STSOMUX_DISABLE);
 	davinci_cfg_reg(DM646X_STSIMUX_DISABLE);
@@ -912,6 +909,7 @@ int __init dm646x_init_edma(struct edma_rsv_info *rsv)
 void __init dm646x_init(void)
 {
 	davinci_common_init(&davinci_soc_info_dm646x);
+	davinci_map_sysmod();
 }
 
 static int __init dm646x_init_devices(void)
diff --git a/arch/arm/mach-davinci/include/mach/hardware.h b/arch/arm/mach-davinci/include/mach/hardware.h
index 414e0b9..0209b1f 100644
--- a/arch/arm/mach-davinci/include/mach/hardware.h
+++ b/arch/arm/mach-davinci/include/mach/hardware.h
@@ -19,8 +19,6 @@
  * and the chip/board init code should then explicitly include
  * <chipname>.h
  */
-#define DAVINCI_SYSTEM_MODULE_BASE        0x01C40000
-
 /*
  * I/O mapping
  */

From nsekhar at ti.com  Mon Feb 20 08:29:47 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 20 Feb 2012 14:29:47 +0000
Subject: [PATCH v7 4/8] davinci: dm644x: Replace register base value
	with a defined macro
In-Reply-To: <1324475021-32509-5-git-send-email-manjunath.hadli@ti.com>
References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com>
	<1324475021-32509-5-git-send-email-manjunath.hadli@ti.com>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317C79D5@DBDE01.ent.ti.com>

Hi Manju,

On Wed, Dec 21, 2011 at 19:13:37, Hadli, Manjunath wrote:
> Replace hard coded value of vpss register base to a define macro
> DM644X_VPSS_BASE for proper readability
> 
> Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>
> Acked-by: Sekhar Nori <nsekhar at ti.com>

The subject line does not follow the format we have in place now.
Also in the subject, the term "defined macro" is odd. You have
fixed some indentation issues with earlier code in this patch.
That should find a mention too. I made these (and some other minor) 
improvements to the patch text while committing.

Please have a look and take care next time onward. Here is the
new text:

    ARM: davinci: dm644x: improve readability using macro

    Replace the VPSS base address "magic number" with the
    define "DM644X_VPSS_BASE" to improve readability.

    While at it, fix the indentation done using spaces in
    this part of code.

    Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>
    Signed-off-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar

From nsekhar at ti.com  Mon Feb 20 12:33:04 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 20 Feb 2012 18:33:04 +0000
Subject: [PATCH v7 5/8] davinci: dm644x: change vpfe capture structure
	variables for consistency
In-Reply-To: <1324475021-32509-6-git-send-email-manjunath.hadli@ti.com>
References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com>
	<1324475021-32509-6-git-send-email-manjunath.hadli@ti.com>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317C7DB4@DBDE01.ent.ti.com>

Hi Manju,

On Wed, Dec 21, 2011 at 19:13:38, Hadli, Manjunath wrote:
> Add SoC and board prefixes to variable names so that it is
> consistent with the rest of the file.
> 
> Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>
> Acked-by: Sekhar Nori <nsekhar at ti.com>

Again the subject line was not following the conventions
currently in place. I am pretty sure they were in place
at the time you submitted the patch too. Please take care
next time onwards. For now, I have fixed it while committing.

While I was at it, I also modified the subject line to make
it less verbose. Here is what I committed:

    ARM: davinci: dm644x: fix inconsistent variable naming

    Add dm644x_ prefix to names of v4l2 variables in dm644x.c
    Add dm644xevm_ prefix to names of v4l2 variables in board-dm644x-evm.c.

    This makes the code consistent with rest of these files.

    Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>
    Signed-off-by: Sekhar Nori <nsekhar at ti.com>

Thanks,
Sekhar

From nsekhar at ti.com  Mon Feb 20 13:15:05 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 20 Feb 2012 19:15:05 +0000
Subject: [PATCH v7 6/8] davinci: dm644x: move vpfe init from soc to
	board	specific files
In-Reply-To: <1324475021-32509-7-git-send-email-manjunath.hadli@ti.com>
References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com>
	<1324475021-32509-7-git-send-email-manjunath.hadli@ti.com>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317C7F07@DBDE01.ent.ti.com>

Hi Manju,

On Wed, Dec 21, 2011 at 19:13:39, Hadli, Manjunath wrote:
> Move all vpfe platform device registrations to the board specific
> file like the rest of the devices, and have all of them together.

I dropped this line from commit text since EMAC and MDIO still
seem to be registered all the time so the "like the rest of the
devices" part isn't really true.

> 
> This would remove the  restriction of inclusion and registration of
> vpfe platform devices for non-vpfe boards.

I don't think the term "non-vpfe board" is in the right sense.
So, I replace this with the expanded form: "boards which do not use vpfe".

Apart from this, I also added the "ARM: " prefix to subject.

> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
> index 7d940f5..71aae93 100644
> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c

> +static struct platform_device *dm644x_video_devices[] __initdata = {
> +	&dm644x_vpss_device,
> +	&dm644x_ccdc_dev,
> +	&dm644x_vpfe_dev,
> +};

You add this array here and remove it in the very next patch. That's
not the right way of doing things. I dropped this array when committing
this patch.

Thanks,
Sekhar


From nsekhar at ti.com  Mon Feb 20 13:26:42 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 20 Feb 2012 19:26:42 +0000
Subject: DM355/DM365/DM368 suspend support
In-Reply-To: <4F419F64.6070601@bluewatersys.com>
References: <4F419F64.6070601@bluewatersys.com>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317C7F40@DBDE01.ent.ti.com>

Hi Andre,

On Mon, Feb 20, 2012 at 06:48:28, Andre Renaud wrote:
> Hello,
> Can anyone tell me the status of the DM36X suspend support in Linux at
> the moment? From what I can see detailed at
> http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Power_Management
> and from the Linux kernel code, it would appear that there is currently
> only support for the DA850 and OMAP-L138.

That's right, DM355/DM365 hardware has suspend capability, but that's not
available in kernel yet.

> 
> Is anyone working on this, or any out-of-tree patches available to test
> this functionality?

I am not aware of anyone working on this. None of the TI releases support
this feature too. So nothing useful I can suggest to you at the moment.
Sorry about that.

Thanks,
Sekhar


From nsekhar at ti.com  Mon Feb 20 14:23:12 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Mon, 20 Feb 2012 20:23:12 +0000
Subject: [PATCH v7 7/8] davinci: dm644x: add support for v4l2 video display
In-Reply-To: <1324475021-32509-8-git-send-email-manjunath.hadli@ti.com>
References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com>
	<1324475021-32509-8-git-send-email-manjunath.hadli@ti.com>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317C8008@DBDE01.ent.ti.com>

Hi Manju,

On Wed, Dec 21, 2011 at 19:13:40, Hadli, Manjunath wrote:
> Create platform devices for various video modules like venc,osd,
> vpbe and v4l2 driver for dm644x. Change the dm644x_init_video to
> make room for display config, and register the vpfe or vpbe devices
> based on the config pointer validity to make sure boards without vpfe
> or vpbe can be built with minimal changes.

> Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>
> +static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type,
> +				   unsigned int mode)
> +{
> +	int ret = 0;
> +	void __iomem *vpss_clkctl_reg;
> +
> +	vpss_clkctl_reg = DAVINCI_SYSMODULE_VIRT(0x44);

Please define a macro for the register offset in davinci.h
and use it here. You can also get rid of the variable.

> +
> +	switch (type) {
> +	case VPBE_ENC_STD:
> +		writel(0x18, vpss_clkctl_reg);

Can you please use some masks to clarify how this and other such magic
numbers below (0x19, 0xa) are arrived at?

I would have made this change myself as I was doing it for rest
of the patches so far, but I cant seem to find the register definition
in any of the documentation I have looked at so far!

I have pushed patches 3-6 into 'v3.4/cleanup' branch of my tree[1].
Can you re-submit the remaining to patches after rebasing to
this branch? I have very little time left before I plan to send
the first sent of v3.4 changes to Arnd/Olof so please get back
quickly. Thanks for the help here.

You need to pull 'v3.4/cleanup' after the 'dependencies' branch to take care 
of some build dependencies.

Thanks,
Sekhar

[1] git://gitorious.org/linux-davinci/linux-davinci.git


From andre at bluewatersys.com  Mon Feb 20 18:36:16 2012
From: andre at bluewatersys.com (Andre Renaud)
Date: Tue, 21 Feb 2012 13:36:16 +1300
Subject: DM355/DM365/DM368 suspend support
In-Reply-To: <DF0F476B391FA8409C78302C7BA518B6317C7F40@DBDE01.ent.ti.com>
References: <4F419F64.6070601@bluewatersys.com>
	<DF0F476B391FA8409C78302C7BA518B6317C7F40@DBDE01.ent.ti.com>
Message-ID: <4F42E700.9000201@bluewatersys.com>

Hi Sekhar,

On 21/02/12 08:26, Nori, Sekhar wrote:
> Hi Andre,
> 
> On Mon, Feb 20, 2012 at 06:48:28, Andre Renaud wrote:
>> Hello,
>> Can anyone tell me the status of the DM36X suspend support in Linux at
>> the moment? From what I can see detailed at
>> http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Power_Management
>> and from the Linux kernel code, it would appear that there is currently
>> only support for the DA850 and OMAP-L138.
> 
> That's right, DM355/DM365 hardware has suspend capability, but that's not
> available in kernel yet.
> 
>>
>> Is anyone working on this, or any out-of-tree patches available to test
>> this functionality?
> 
> I am not aware of anyone working on this. None of the TI releases support
> this feature too. So nothing useful I can suggest to you at the moment.
> Sorry about that.

Do you know if there is any intention by TI to look at adding this
support in the future? If not, do you know of any reference/example that
might be useful if I do have to develop this from scratch?

Regards,
Andre

From nsekhar at ti.com  Mon Feb 20 23:37:05 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 21 Feb 2012 05:37:05 +0000
Subject: DM355/DM365/DM368 suspend support
In-Reply-To: <4F42E700.9000201@bluewatersys.com>
References: <4F419F64.6070601@bluewatersys.com>
	<DF0F476B391FA8409C78302C7BA518B6317C7F40@DBDE01.ent.ti.com>
	<4F42E700.9000201@bluewatersys.com>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317C8400@DBDE01.ent.ti.com>

Hi Andre,

On Tue, Feb 21, 2012 at 06:06:16, Andre Renaud wrote:
> Hi Sekhar,
> 
> On 21/02/12 08:26, Nori, Sekhar wrote:
> > Hi Andre,
> > 
> > On Mon, Feb 20, 2012 at 06:48:28, Andre Renaud wrote:
> >> Hello,
> >> Can anyone tell me the status of the DM36X suspend support in Linux at
> >> the moment? From what I can see detailed at
> >> http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Power_Management
> >> and from the Linux kernel code, it would appear that there is currently
> >> only support for the DA850 and OMAP-L138.
> > 
> > That's right, DM355/DM365 hardware has suspend capability, but that's not
> > available in kernel yet.
> > 
> >>
> >> Is anyone working on this, or any out-of-tree patches available to test
> >> this functionality?
> > 
> > I am not aware of anyone working on this. None of the TI releases support
> > this feature too. So nothing useful I can suggest to you at the moment.
> > Sorry about that.
> 
> Do you know if there is any intention by TI to look at adding this
> support in the future? If not, do you know of any reference/example that
> might be useful if I do have to develop this from scratch?

No, there are no known plans from TI to support this. The best starting
point is the existing sleep code for DA850. Both DA850 and DM365 use
the "Deep Sleep" feature. I have not done a study of the differences
myself, but I suspect they wont be too different.

Thanks,
Sekhar

From prakash.pm at ti.com  Tue Feb 21 00:24:56 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 21 Feb 2012 06:24:56 +0000
Subject: [PATCH v4 0/3] Moving EMIF driver to MFD framework
In-Reply-To: <1328771908-32527-1-git-send-email-prakash.pm@ti.com>
References: <1328771908-32527-1-git-send-email-prakash.pm@ti.com>
Message-ID: <A73F36158E33644199EB82C5EC81C7BC31769AF1@DBDE01.ent.ti.com>

Hi,

I do not see any comments on this series. Can it be applied?

Thanks,
Prakash

On Thu, Feb 09, 2012 at 12:48:25, Manjunathappa, Prakash wrote:
> Patch series are based on the discussion and concerns expressed in
> davinci-linux-open-source community. Here is the link for the same:
> http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-tt7059739.html#none
> 
> Manjunathappa, Prakash (3):
>   arm:davinci: prepare to move aemif driver to drivers/mfd
>   arm:davinci: move emif driver to drivers/mfd from mach-davinci folder
>   arm:davinci: move NAND and NOR devices as aemif MFD slaves
> 
>  arch/arm/Kconfig                                   |    1 +
>  arch/arm/mach-davinci/Makefile                     |    2 +-
>  arch/arm/mach-davinci/aemif.c                      |  133 -------------
>  arch/arm/mach-davinci/board-da830-evm.c            |   33 +++-
>  arch/arm/mach-davinci/board-da850-evm.c            |   56 +++---
>  arch/arm/mach-davinci/board-dm355-evm.c            |   33 +++-
>  arch/arm/mach-davinci/board-dm355-leopard.c        |   35 +++-
>  arch/arm/mach-davinci/board-dm365-evm.c            |   34 +++-
>  arch/arm/mach-davinci/board-dm644x-evm.c           |  175 ++++++++++-------
>  arch/arm/mach-davinci/board-dm646x-evm.c           |   32 +++-
>  arch/arm/mach-davinci/board-mityomapl138.c         |   34 +++-
>  arch/arm/mach-davinci/board-neuros-osd2.c          |    1 +
>  arch/arm/mach-davinci/board-sffsdr.c               |   34 +++-
>  drivers/mfd/Makefile                               |    1 +
>  drivers/mfd/davinci_aemif.c                        |  206 ++++++++++++++++++++
>  drivers/mtd/nand/davinci_nand.c                    |    2 +-
>  .../aemif.h => include/linux/mfd/davinci_aemif.h   |   14 ++
>  17 files changed, 527 insertions(+), 299 deletions(-)
>  delete mode 100644 arch/arm/mach-davinci/aemif.c
>  create mode 100644 drivers/mfd/davinci_aemif.c
>  rename arch/arm/mach-davinci/include/mach/aemif.h => include/linux/mfd/davinci_aemif.h (74%)
> 
> 


From nsekhar at ti.com  Tue Feb 21 10:43:00 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 21 Feb 2012 16:43:00 +0000
Subject: [PATCH v4 0/3] Moving EMIF driver to MFD framework
In-Reply-To: <A73F36158E33644199EB82C5EC81C7BC31769AF1@DBDE01.ent.ti.com>
References: <1328771908-32527-1-git-send-email-prakash.pm@ti.com>
	<A73F36158E33644199EB82C5EC81C7BC31769AF1@DBDE01.ent.ti.com>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317C9199@DBDE01.ent.ti.com>

Hi Prakash,

On Tue, Feb 21, 2012 at 11:54:56, Manjunathappa, Prakash wrote:
> Hi,
> 
> I do not see any comments on this series. Can it be applied?

I have not yet gotten to reviewing the davinci parts of this series.
I have a backlog and am clearing it oldest first. Hope to get to this
by this week or early next week.

Thanks,
Sekhar


From hs at denx.de  Wed Feb 22 00:50:06 2012
From: hs at denx.de (Heiko Schocher)
Date: Wed, 22 Feb 2012 07:50:06 +0100
Subject: [PATCH v2 3/7] ARM: davinci: mux: add OF support
In-Reply-To: <1329893410-24413-1-git-send-email-hs@denx.de>
References: <1329893410-24413-1-git-send-email-hs@denx.de>
Message-ID: <1329893410-24413-4-git-send-email-hs@denx.de>

add support for configuring the pinmux on davinci SoC
through OF.

Signed-off-by: Heiko Schocher <hs at denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Wolfgang Denk <wd at denx.de>

---
This patch is just a RFC, as I want to get rid of the pin
setup code in board code ... This patch introduces a
davinci_cfg_reg_of() function, which davinci drivers can call,
if they found a pinmux-handle, so used in the following
drivers in this patchserie:

drivers/net/ethernet/ti/davinci_emac
drivers/i2c/busses/i2c-davinci.c
drivers/mtd/nand/davinci_nand.c

Comments are welcome.

 .../devicetree/bindings/arm/davinci/mux.txt        |   40 +++++++++++
 arch/arm/mach-davinci/include/mach/mux.h           |    2 +
 arch/arm/mach-davinci/mux.c                        |   73 +++++++++++++++++++-
 3 files changed, 114 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/mux.txt

diff --git a/Documentation/devicetree/bindings/arm/davinci/mux.txt b/Documentation/devicetree/bindings/arm/davinci/mux.txt
new file mode 100644
index 0000000..ecb026a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/mux.txt
@@ -0,0 +1,40 @@
+* Texas Instruments Davinci pinmux
+
+This file provides information, what the device node for the
+davinci pinmux interface contain.
+
+Required properties:
+- compatible: "ti,davinci-pinmux";
+- pins : contains a table with the following colums:
+   mux register: pinmux register
+   register offset: offset in register, which to change
+   mode mask: mode mask
+   mode value: mode value
+
+Optional properties:
+- none
+
+Example (enbw_cmc board):
+	emac_pins: pinmux at 1c14120 {
+		compatible = "ti,davinci-pinmux";
+		reg = <0x14120 0x1000>;
+		pins = < /*	muxreg	maskoff	modemsk muxmode */
+				2	4	15	8 /* MII TXEN */
+				2	8	15	8 /* MII TXCLK */
+				2	12	15	8 /* MII COL */
+				2	16	15	8 /* MII TXD_3 */
+				2	20	15	8 /* MII TXD_2 */
+				2	24	15	8 /* MII TXD_1 */
+				2	28	15	8 /* MII TXD_0 */
+				3	8	15	8 /* MII RXER */
+				3	12	15	8 /* MII CRS */
+				3	0	15	8 /* MII RXCLK */
+				3	4	15	8 /* MII RXDV */
+				3	16	15	8 /* MII RXD_3 */
+				3	20	15	8 /* MII RXD_2 */
+				3	24	15	8 /* MII RXD_1 */
+				3	28	15	8 /* MII RXD_0 */
+				4	0	15	8 /* MDIO CLK */
+				4	4	15	8 /* MDIO D */
+			>;
+	};
diff --git a/arch/arm/mach-davinci/include/mach/mux.h b/arch/arm/mach-davinci/include/mach/mux.h
index a7e92fc..3a62857 100644
--- a/arch/arm/mach-davinci/include/mach/mux.h
+++ b/arch/arm/mach-davinci/include/mach/mux.h
@@ -1205,6 +1205,7 @@ enum davinci_tnetv107x_index {
 /* setup pin muxing */
 extern int davinci_cfg_reg(unsigned long reg_cfg);
 extern int davinci_cfg_reg_list(const short pins[]);
+extern int davinci_cfg_reg_of(struct device_node *);
 #else
 /* boot loader does it all (no warnings from CONFIG_DAVINCI_MUX_WARNINGS) */
 static inline int davinci_cfg_reg(unsigned long reg_cfg) { return 0; }
@@ -1212,6 +1213,7 @@ static inline int davinci_cfg_reg_list(const short pins[])
 {
 	return 0;
 }
+static int davinci_cfg_reg_of(struct device_node *) { return 0; };
 #endif
 
 #endif /* __INC_MACH_MUX_H */
diff --git a/arch/arm/mach-davinci/mux.c b/arch/arm/mach-davinci/mux.c
index f34a8dc..6b38072 100644
--- a/arch/arm/mach-davinci/mux.c
+++ b/arch/arm/mach-davinci/mux.c
@@ -18,18 +18,21 @@
 #include <linux/io.h>
 #include <linux/module.h>
 #include <linux/spinlock.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
 
 #include <mach/mux.h>
 #include <mach/common.h>
 
 static void __iomem *pinmux_base;
+static DEFINE_SPINLOCK(mux_spin_lock);
 
 /*
  * Sets the DAVINCI MUX register based on the table
  */
 int __init_or_module davinci_cfg_reg(const unsigned long index)
 {
-	static DEFINE_SPINLOCK(mux_spin_lock);
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
 	unsigned long flags;
 	const struct mux_config *cfg;
@@ -98,6 +101,74 @@ int __init_or_module davinci_cfg_reg(const unsigned long index)
 }
 EXPORT_SYMBOL(davinci_cfg_reg);
 
+#ifdef CONFIG_OF
+int davinci_cfg_reg_of(struct device_node *np)
+{
+	unsigned long flags;
+	int pinmux_map_len;
+	const unsigned int *pinmux_map;
+	u32 muxreg, maskoff, modemsk, muxmode;
+	unsigned int reg_orig = 0, reg = 0;
+	unsigned int mask, warn = 0;
+
+	pinmux_map = of_get_property(np, "pins", &pinmux_map_len);
+	if (pinmux_map == NULL) {
+		printk(KERN_ERR "pins is not set!\n");
+		return -EINVAL;
+	}
+
+	pinmux_map_len /= sizeof(unsigned int);
+	if ((pinmux_map_len % 4) != 0) {
+		printk(KERN_ERR "pins format wrong!\n");
+		return -EINVAL;
+	}
+
+	if (!pinmux_base) {
+		pinmux_base = of_iomap(np, 0);
+		if (WARN_ON(!pinmux_base))
+			return -ENOMEM;
+	}
+
+	while (pinmux_map_len > 0) {
+		muxreg = be32_to_cpu(pinmux_map[0]);
+		maskoff = be32_to_cpu(pinmux_map[1]);
+		modemsk = be32_to_cpu(pinmux_map[2]);
+		muxmode = be32_to_cpu(pinmux_map[3]);
+
+		/* Update the mux register in question */
+		if (modemsk) {
+			unsigned	tmp1, tmp2;
+
+			spin_lock_irqsave(&mux_spin_lock, flags);
+			reg_orig = __raw_readl(pinmux_base + muxreg);
+
+			mask = (modemsk << maskoff);
+			tmp1 = reg_orig & mask;
+			reg = reg_orig & ~mask;
+
+			tmp2 = (muxmode << maskoff);
+			reg |= tmp2;
+
+			if (tmp1 != tmp2)
+				warn = 1;
+
+			__raw_writel(reg, pinmux_base + muxreg);
+			spin_unlock_irqrestore(&mux_spin_lock, flags);
+		}
+		pinmux_map += 4;
+		pinmux_map_len -= 4;
+	}
+
+	return 0;
+}
+#else
+int davinci_cfg_reg_of(struct device_node *np)
+{
+	return 0;
+}
+#endif
+EXPORT_SYMBOL(davinci_cfg_reg_of);
+
 int __init_or_module davinci_cfg_reg_list(const short pins[])
 {
 	int i, error = -EINVAL;
-- 
1.7.7.6


From hs at denx.de  Wed Feb 22 00:50:04 2012
From: hs at denx.de (Heiko Schocher)
Date: Wed, 22 Feb 2012 07:50:04 +0100
Subject: [PATCH v2 1/7] ARM: davinci,
	intc: Add OF support for TI interrupt controller
In-Reply-To: <1329893410-24413-1-git-send-email-hs@denx.de>
References: <1329893410-24413-1-git-send-email-hs@denx.de>
Message-ID: <1329893410-24413-2-git-send-email-hs@denx.de>

Add a function to initialize the davinci interrupt controller (INTC)
using a device tree node.

Signed-off-by: Heiko Schocher <hs at denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Wolfgang Denk <wd at denx.de>

---
- changes for v2:
- add comment from Grant Likely:
  - migrate the whole interrupt controller to natively use an
    irq_domain. Rebased complete patchserie to:
    http://git.secretlab.ca/?p=linux-2.6.git;a=shortlog;h=refs/heads/irqdomain/next

    commit 2462bacd0334d918f9fcd79fc59c403b76b36f8a
    Author: Grant Likely <grant.likely at secretlab.ca>
    Date:   Thu Jan 26 14:10:13 2012 -0700

    irq_domain/microblaze: Convert microblaze to use irq_domains

 .../devicetree/bindings/arm/davinci/intc.txt       |   26 ++++
 arch/arm/mach-davinci/cp_intc.c                    |  133 ++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/cp_intc.h       |    1 +
 3 files changed, 160 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt

diff --git a/Documentation/devicetree/bindings/arm/davinci/intc.txt b/Documentation/devicetree/bindings/arm/davinci/intc.txt
new file mode 100644
index 0000000..dac2f69
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/intc.txt
@@ -0,0 +1,26 @@
+* TI Davinci Interrupt Controller
+
+davinci are using a TI interrupt controller that can support several
+configurable number of interrupts.
+
+Main node required properties:
+
+- compatible : should be:
+	"ti,davinci-intc"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The type shall be a <u32> and the value shall be 1.
+
+  The cell contains the interrupt number in the range [0-128].
+- ti,intc-size: Number of interrupts handled by the interrupt controller.
+- reg: physical base address and size of the intc registers map.
+
+Example:
+
+	intc: interrupt-controller at 1 {
+		compatible = "ti,davinci-intc";
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		ti,intc-size = <101>;
+		reg = <0xfffee000 0x2000>;
+	};
diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
index f83152d..6f11daf 100644
--- a/arch/arm/mach-davinci/cp_intc.c
+++ b/arch/arm/mach-davinci/cp_intc.c
@@ -9,9 +9,14 @@
  * kind, whether express or implied.
  */
 
+#include <linux/export.h>
 #include <linux/init.h>
 #include <linux/irq.h>
+#include <linux/irqdomain.h>
 #include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
 
 #include <mach/common.h>
 #include <mach/cp_intc.h>
@@ -175,3 +180,131 @@ void __init cp_intc_init(void)
 	/* Enable global interrupt */
 	cp_intc_write(1, CP_INTC_GLOBAL_ENABLE);
 }
+
+#ifdef CONFIG_OF
+static struct irq_domain *cp_intc_domain;
+
+static int cp_intc_host_map(struct irq_domain *h, unsigned int virq,
+			  irq_hw_number_t hw)
+{
+	pr_debug("cp_intc_host_map(%d, 0x%lx)\n", virq, hw);
+
+	irq_set_chip(virq, &cp_intc_irq_chip);
+	set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
+	irq_set_handler(virq, handle_edge_irq);
+	return 0;
+}
+
+static const struct irq_domain_ops cp_intc_host_ops = {
+	.map = cp_intc_host_map,
+	.xlate = irq_domain_xlate_onetwocell,
+};
+
+int __init cp_intc_domain_init(struct device_node *node,
+		struct device_node *parent)
+{
+	u32 num_irq;
+	u8 *irq_prio		= davinci_soc_info.intc_irq_prios;
+	u32 *host_map		= davinci_soc_info.intc_host_map;
+	unsigned num_reg;
+	int i, irq_base;
+
+	davinci_intc_type = DAVINCI_INTC_TYPE_CP_INTC;
+	davinci_intc_base = of_iomap(node, 0);
+	if (WARN_ON(!davinci_intc_base))
+		return -EINVAL;
+
+	if (of_property_read_u32(node, "ti,intc-size", &num_irq)) {
+		WARN(1, "unable to get intc-size\n");
+		return -EINVAL;
+	}
+	num_reg	= BITS_TO_LONGS(num_irq);
+
+	cp_intc_write(0, CP_INTC_GLOBAL_ENABLE);
+
+	/* Disable all host interrupts */
+	cp_intc_write(0, CP_INTC_HOST_ENABLE(0));
+
+	/* Disable system interrupts */
+	for (i = 0; i < num_reg; i++)
+		cp_intc_write(~0, CP_INTC_SYS_ENABLE_CLR(i));
+
+	/* Set to normal mode, no nesting, no priority hold */
+	cp_intc_write(0, CP_INTC_CTRL);
+	cp_intc_write(0, CP_INTC_HOST_CTRL);
+
+	/* Clear system interrupt status */
+	for (i = 0; i < num_reg; i++)
+		cp_intc_write(~0, CP_INTC_SYS_STAT_CLR(i));
+
+	/* Enable nIRQ (what about nFIQ?) */
+	cp_intc_write(1, CP_INTC_HOST_ENABLE_IDX_SET);
+
+	/*
+	 * Priority is determined by host channel: lower channel number has
+	 * higher priority i.e. channel 0 has highest priority and channel 31
+	 * had the lowest priority.
+	 */
+	num_reg = (num_irq + 3) >> 2;	/* 4 channels per register */
+	if (irq_prio) {
+		unsigned j, k;
+		u32 val;
+
+		for (k = i = 0; i < num_reg; i++) {
+			for (val = j = 0; j < 4; j++, k++) {
+				val >>= 8;
+				if (k < num_irq)
+					val |= irq_prio[k] << 24;
+			}
+
+			cp_intc_write(val, CP_INTC_CHAN_MAP(i));
+		}
+	} else	{
+		/*
+		 * Default everything to channel 15 if priority not specified.
+		 * Note that channel 0-1 are mapped to nFIQ and channels 2-31
+		 * are mapped to nIRQ.
+		 */
+		for (i = 0; i < num_reg; i++)
+			cp_intc_write(0x0f0f0f0f, CP_INTC_CHAN_MAP(i));
+	}
+
+	if (host_map)
+		for (i = 0; host_map[i] != -1; i++)
+			cp_intc_write(host_map[i], CP_INTC_HOST_MAP(i));
+
+	irq_base = irq_alloc_descs(-1, 0, nr_irqs, 0);
+	if (irq_base < 0) {
+		pr_warn("Couldn't allocate IRQ numbers\n");
+		irq_base = 0;
+	}
+
+	/* create a legacy host */
+	cp_intc_domain = irq_domain_add_legacy(node, num_irq, irq_base, 0,
+				&cp_intc_host_ops, NULL);
+	if (cp_intc_domain == NULL) {
+		printk(KERN_ERR "CP INTC: failed to allocate irq host!\n");
+		return -EINVAL;
+	}
+
+	/* Enable global interrupt */
+	cp_intc_write(1, CP_INTC_GLOBAL_ENABLE);
+
+	return 0;
+}
+
+static struct of_device_id irq_match[] __initdata = {
+	{ .compatible = "ti,davinci-intc", .data = cp_intc_domain_init, },
+	{ }
+};
+
+void __init davinci_init_irq(void)
+{
+	of_irq_init(irq_match);
+}
+#else
+void __init davinci_init_irq(void)
+{
+	cp_intc_init();
+}
+#endif
diff --git a/arch/arm/mach-davinci/include/mach/cp_intc.h b/arch/arm/mach-davinci/include/mach/cp_intc.h
index 4e8190e..d674b95 100644
--- a/arch/arm/mach-davinci/include/mach/cp_intc.h
+++ b/arch/arm/mach-davinci/include/mach/cp_intc.h
@@ -52,5 +52,6 @@
 #define CP_INTC_VECTOR_ADDR(n)		(0x2000 + (n << 2))
 
 void __init cp_intc_init(void);
+void __init davinci_init_irq(void);
 
 #endif	/* __ASM_HARDWARE_CP_INTC_H */
-- 
1.7.7.6


From hs at denx.de  Wed Feb 22 00:50:03 2012
From: hs at denx.de (Heiko Schocher)
Date: Wed, 22 Feb 2012 07:50:03 +0100
Subject: [PATCH v2 0/7] ARM: davinci: add support for the am1808 based
	enbw_cmc board
Message-ID: <1329893410-24413-1-git-send-email-hs@denx.de>

This patchserie adds support for the davinci am1808 based
enbw_cmc board.

Post this patchserie now as v2, as reworked in the
comments I got for the RFC serie.

Important: I rebased this patchserie against the irqdomain/next
branch from grant likely, as he suggested to rework the OF
intcontroller changes to the irqdomain work, branch found here:

http://git.secretlab.ca/?p=linux-2.6.git;a=shortlog;h=refs/heads/irqdomain/next

commit 2462bacd0334d918f9fcd79fc59c403b76b36f8a
Author: Grant Likely <grant.likely at secretlab.ca>
Date:   Thu Jan 26 14:10:13 2012 -0700

    irq_domain/microblaze: Convert microblaze to use irq_domains

Got no comments to the following points, I noted in the
RFC series, so posting this patchseries with them:

- ARM: davinci: configure davinci aemif chipselects through OF
  not moved to mfd, as mentioned in this discussion:
  http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-td7059739.html
  instead use a phandle in the DTS, so drivers which
  uses the davinci aemif, can call davinci_aemif_setup_timing_of()

  This is just thought as an RFC ... The enbw_cmc board
  support not really need to setup this bus timings, as
  they are setup in U-Boot ... but I want to post this,
  as I think, it is a nice to have, and I am not really
  sure, if this has to be a MFD device (If so, all bus
  interfaces for other SoCs should be converted also to
  MFD devices) ... as an example how this can be used
  I add this to the davinci nand controller OF support
  patch, in this patchserie.

- ARM: davinci: mux: add OF support
  I want to get rid of the pin setup code in board code ...
  This patch introduces a davinci_cfg_reg_of() function,
  which davinci drivers can call, if they found a
  "pinmux-handle", so used in the following drivers in
  this patchserie:

  drivers/net/ethernet/ti/davinci_emac
  drivers/i2c/busses/i2c-davinci.c
  drivers/mtd/nand/davinci_nand.c

- post this board support with USB support, even though
  USB is only working with the 10 ms "workaround", posted here:
  http://comments.gmane.org/gmane.linux.usb.general/54505
  I see this issue also on the AM1808 TMDXEXP1808L evalboard.

- MMC and USB are not using OF support yet, ideas how to port
  this are welcome. I need for USB and MMC board specific
  callbacks, how to solve this with OF support?

Signed-off-by: Heiko Schocher <hs at denx.de>
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-mtd at lists.infradead.org
Cc: linux-i2c at vger.kernel.org
Cc: netdev at vger.kernel.org
Cc: David Woodhouse <dwmw2 at infradead.org>
Cc: Ben Dooks <ben-linux at fluff.org>
Cc: Wolfram Sang <w.sang at pengutronix.de>
Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Kevin Hilman <khilman at ti.com>
Cc: Wolfgang Denk <wd at denx.de>

Heiko Schocher (7):
  ARM: davinci, intc: Add OF support for TI interrupt controller
  ARM: davinci: configure davinci aemif chipselects through OF
  ARM: davinci: mux: add OF support
  ARM: davinci: net: davinci_emac: add OF support
  ARM: davinci: i2c: add OF support
  ARM: mtd: nand: davinci: add OF support for davinci nand controller
  ARM: davinci: add support for the am1808 based enbw_cmc board

 .../devicetree/bindings/arm/davinci/aemif.txt      |  119 ++++++
 .../bindings/arm/davinci/davinci_emac.txt          |   43 +++
 .../devicetree/bindings/arm/davinci/i2c.txt        |   33 ++
 .../devicetree/bindings/arm/davinci/intc.txt       |   26 ++
 .../devicetree/bindings/arm/davinci/mux.txt        |   40 ++
 .../devicetree/bindings/arm/davinci/nand.txt       |   74 ++++
 arch/arm/boot/dts/enbw_cmc.dts                     |  268 ++++++++++++++
 arch/arm/configs/enbw_cmc_defconfig                |  123 +++++++
 arch/arm/mach-davinci/Kconfig                      |    9 +
 arch/arm/mach-davinci/Makefile                     |    1 +
 arch/arm/mach-davinci/aemif.c                      |   86 +++++-
 arch/arm/mach-davinci/board-enbw-cmc.c             |  380 ++++++++++++++++++++
 arch/arm/mach-davinci/cp_intc.c                    |  133 +++++++
 arch/arm/mach-davinci/include/mach/aemif.h         |    1 +
 arch/arm/mach-davinci/include/mach/cp_intc.h       |    1 +
 arch/arm/mach-davinci/include/mach/mux.h           |    2 +
 arch/arm/mach-davinci/include/mach/uncompress.h    |    1 +
 arch/arm/mach-davinci/mux.c                        |   73 ++++-
 drivers/i2c/busses/i2c-davinci.c                   |   37 ++
 drivers/mtd/nand/davinci_nand.c                    |   85 +++++-
 drivers/net/ethernet/ti/davinci_emac.c             |   94 +++++-
 21 files changed, 1625 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/intc.txt
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/mux.txt
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt
 create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
 create mode 100644 arch/arm/configs/enbw_cmc_defconfig
 create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c

-- 
1.7.7.6


From hs at denx.de  Wed Feb 22 00:50:08 2012
From: hs at denx.de (Heiko Schocher)
Date: Wed, 22 Feb 2012 07:50:08 +0100
Subject: [PATCH v2 5/7] ARM: davinci: i2c: add OF support
In-Reply-To: <1329893410-24413-1-git-send-email-hs@denx.de>
References: <1329893410-24413-1-git-send-email-hs@denx.de>
Message-ID: <1329893410-24413-6-git-send-email-hs@denx.de>

add of support for the davinci i2c driver.

Signed-off-by: Heiko Schocher <hs at denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-i2c at vger.kernel.org
Cc: Ben Dooks <ben-linux at fluff.org>
Cc: Wolfram Sang <w.sang at pengutronix.de>
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Wolfgang Denk <wd at denx.de>
Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>

---
- changes for v2:
- add comments from Sylwester Nawrocki <s.nawrocki at samsung.com>:
  - use "cell-index" instead "id"
  - OF_DEV_AUXDATA in the machine code, instead pre-define platform
    device name
- add comment from Grant Likely:
  - removed "id" resp. "cell-index" completely
  - fixed documentation
  - use of_match_ptr()
  - use devm_kzalloc() for allocating plattform data mem
  - fixed a whitespace issue

 .../devicetree/bindings/arm/davinci/i2c.txt        |   33 +++++++++++++++++
 drivers/i2c/busses/i2c-davinci.c                   |   37 ++++++++++++++++++++
 2 files changed, 70 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt

diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
new file mode 100644
index 0000000..ba00d7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
@@ -0,0 +1,33 @@
+* Texas Instruments Davinci I2C
+
+This file provides information, what the device node for the
+davinci i2c interface contain.
+
+Required properties:
+- compatible: "ti,davinci-i2c";
+- reg : Offset and length of the register set for the device
+
+Recommended properties :
+- interrupts : <a> standard interrupt property.
+- clock-frequency : desired I2C bus clock frequency in Hz.
+
+Optional properties:
+- bus-delay: bus delay in usec
+- pinmux-handle: Contains a handle to configure the pinmux settings.
+
+Example (enbw_cmc board):
+	i2c at 1c22000 {
+		compatible = "ti,davinci-i2c";
+		reg = <0x22000 0x1000>;
+		clock-frequency = <100000>;
+		interrupts = <15>;
+		interrupt-parent = <&intc>;
+		pinmux-handle = <&i2c1_pins>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		dtt at 48 {
+				compatible = "national,lm75";
+				reg = <0x48>;
+			};
+	};
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index a76d85f..0d07d02 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -38,9 +38,12 @@
 #include <linux/slab.h>
 #include <linux/cpufreq.h>
 #include <linux/gpio.h>
+#include <linux/of_i2c.h>
+#include <linux/of_device.h>
 
 #include <mach/hardware.h>
 #include <mach/i2c.h>
+#include <mach/mux.h>
 
 /* ----- global defines ----------------------------------------------- */
 
@@ -635,6 +638,12 @@ static struct i2c_algorithm i2c_davinci_algo = {
 	.functionality	= i2c_davinci_func,
 };
 
+static const struct of_device_id davinci_i2c_of_match[] = {
+	{.compatible = "ti,davinci-i2c", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
+
 static int davinci_i2c_probe(struct platform_device *pdev)
 {
 	struct davinci_i2c_dev *dev;
@@ -676,6 +685,31 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 	dev->irq = irq->start;
 	platform_set_drvdata(pdev, dev);
 
+	if ((dev->dev->platform_data == NULL) &&
+		(pdev->dev.of_node)) {
+		struct device_node *pinmux_np;
+		struct davinci_i2c_platform_data *pdata;
+		u32 prop;
+
+		pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+		if (!pdata) {
+			r = -ENOMEM;
+			goto err_free_mem;
+		}
+		memcpy(pdata, &davinci_i2c_platform_data_default,
+			sizeof(*pdata));
+		dev->dev->platform_data = pdata;
+		if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
+			&prop))
+			pdata->bus_freq = prop / 1000;
+		if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
+			&prop))
+			pdata->bus_delay = prop;
+		pinmux_np = of_parse_phandle(pdev->dev.of_node,
+				"pinmux-handle", 0);
+		if (pinmux_np)
+			davinci_cfg_reg_of(pinmux_np);
+	}
 	dev->clk = clk_get(&pdev->dev, NULL);
 	if (IS_ERR(dev->clk)) {
 		r = -ENODEV;
@@ -711,6 +745,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 	adap->algo = &i2c_davinci_algo;
 	adap->dev.parent = &pdev->dev;
 	adap->timeout = DAVINCI_I2C_TIMEOUT;
+	adap->dev.of_node = pdev->dev.of_node;
 
 	adap->nr = pdev->id;
 	r = i2c_add_numbered_adapter(adap);
@@ -718,6 +753,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "failure adding adapter\n");
 		goto err_free_irq;
 	}
+	of_i2c_register_devices(adap);
 
 	return 0;
 
@@ -809,6 +845,7 @@ static struct platform_driver davinci_i2c_driver = {
 		.name	= "i2c_davinci",
 		.owner	= THIS_MODULE,
 		.pm	= davinci_i2c_pm_ops,
+		.of_match_table = of_match_ptr(davinci_i2c_of_match),
 	},
 };
 
-- 
1.7.7.6


From hs at denx.de  Wed Feb 22 00:50:05 2012
From: hs at denx.de (Heiko Schocher)
Date: Wed, 22 Feb 2012 07:50:05 +0100
Subject: [PATCH v2 2/7] ARM: davinci: configure davinci aemif chipselects
	through OF
In-Reply-To: <1329893410-24413-1-git-send-email-hs@denx.de>
References: <1329893410-24413-1-git-send-email-hs@denx.de>
Message-ID: <1329893410-24413-3-git-send-email-hs@denx.de>

Add support for configuring the aemif timing registers
through device tree. Introduce new compatible property
"ti,davinci-cs", see full description in
Documentation/devicetree/bindings/arm/davinci/aemif.txt

Signed-off-by: Heiko Schocher <hs at denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Kevin Hilman <khilman at ti.com>
Cc: Wolfgang Denk <wd at denx.de>
Cc: Sergei Shtylyov <sshtylyov at mvista.com>

---
- changes for v2
  - add comment from Sergei Shtylyov:
    - use of_property_read_u32()
    - Conding Style changes
  - add comment from Sekhar Nori:
    - add patch description
    - use davinci_aemif_setup_timing
    - change compatible node to "ti,davinci-aemif"

  - not moved to mfd, as mentioned in this discussion:
    http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-td7059739.html
    instead use a phandle in the DTS, so drivers which
    uses the davinci aemif, can call davinci_aemif_setup_timing_of()

    This is just thought as an RFC ... The enbw_cmc board
    support not really need to setup this bus timings, as
    they are setup in U-Boot ... but I want to post this,
    as I think, it is a nice to have ... as an example used
    in the davinci nand controller OF support patch, in this
    patchserie.

 .../devicetree/bindings/arm/davinci/aemif.txt      |  119 ++++++++++++++++++++
 arch/arm/mach-davinci/aemif.c                      |   86 ++++++++++++++-
 arch/arm/mach-davinci/include/mach/aemif.h         |    1 +
 3 files changed, 205 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt

diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt b/Documentation/devicetree/bindings/arm/davinci/aemif.txt
new file mode 100644
index 0000000..0dbb842
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt
@@ -0,0 +1,119 @@
+* Texas Instruments Davinci AEMIF
+
+This file provides information, what the device node for the
+davinci aemif interface contain.
+
+Required properties:
+- compatible: "ti,davinci-aemif";
+- #address-cells : Should be either two or three.  The first cell is the
+                   chipselect number, and the remaining cells are the
+                   offset into the chipselect.
+- #size-cells : Either one or two, depending on how large each chipselect
+                can be.
+- ranges : Each range corresponds to a single chipselect, and cover
+           the entire access window as configured.
+
+Optional properties:
+- none
+
+Optional subnodes:
+- Chipselect setup:
+	- compatible: "ti,davinci-cs";
+	- #address-cells = <1>;
+	- #size-cells = <1>;
+
+    Timing setup, all timings in nanoseconds
+	- cs:		chipselect (value 2,3,4 or 5)
+	- asize:	Asynchronous Data Bus Width.
+			value:
+			0: 8 bit
+			1: 16 bit
+	- ta:		Minimum Turn-Around time.
+	- rhold:	Read hold width
+	- rstrobe:	Read strobe width
+	- rsetup:	Read setup width
+	- whold:	Write hold width
+	- wstrobe:	Write strobe width
+	- wsetup:	Write setup width
+	- ew:		Extend Wait bit
+			value:
+			0: Extended wait cycles disabled.
+			1: Extended wait cycles enabled.
+	- ss:		Select Strobe bit.
+			value:
+			0: Normal Mode enabled.
+			1: Select Strobe Mode enabled.
+- CFI driver:
+  see: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+
+Example (enbw_cmc board):
+	aemif at 60000000 {
+		compatible = "ti,davinci-aemif";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		reg = <0x68000000 0x80000>;
+		ranges = <2 0 0x60000000 0x02000000
+			  3 0 0x62000000 0x02000000
+			  4 0 0x64000000 0x02000000
+			  5 0 0x66000000 0x02000000
+			  6 0 0x68000000 0x02000000>;
+		cs2 at 68000000 {
+			compatible = "ti,davinci-cs";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			/* all timings in nanoseconds */
+			cs = <2>;
+			asize = <1>;
+			ta = <0>;
+			rhold = <7>;
+			rstrobe = <42>;
+			rsetup = <14>;
+			whold = <7>;
+			wstrobe = <42>;
+			wsetup = <14>;
+			ew = <0>;
+			ss = <0>;
+		};
+		flash at 2,0 {
+			compatible = "cfi-flash";
+			reg = <2 0x0 0x400000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			bank-width = <2>;
+			device-width = <2>;
+		};
+		nand_cs: cs3 at 68000000 {
+			compatible = "ti,davinci-cs";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			/* all timings in nanoseconds */
+			cs = <3>;
+			asize = <0>;
+			ta = <0>;
+			rhold = <7>;
+			rstrobe = <42>;
+			rsetup = <7>;
+			whold = <7>;
+			wstrobe = <14>;
+			wsetup = <7>;
+			ew = <0>;
+			ss = <0>;
+		};
+		nandflash at 3,0 {
+			compatible = "ti,davinci-nand";
+			reg = <3 0x0 0x807ff
+				6 0x0 0x8000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			mask_ale = <0>;
+			mask_cle = <0>;
+			mask_chipsel = <0>;
+			ecc_mode = <2>;
+			ecc_bits = <4>;
+			options = <0>;
+			bbt_options = <0x20000>;
+			pinmux-handle = <&nand_pins>;
+			timing-handle = <&nand_cs>;
+		};
+
+	};
diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
index 1ce70a9..e3d94a5 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/arch/arm/mach-davinci/aemif.c
@@ -13,12 +13,14 @@
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/time.h>
 
 #include <mach/aemif.h>
 
 /* Timing value configuration */
-
+#define ASIZE(x)	(x)
 #define TA(x)		((x) << 2)
 #define RHOLD(x)	((x) << 4)
 #define RSTROBE(x)	((x) << 7)
@@ -26,7 +28,10 @@
 #define WHOLD(x)	((x) << 17)
 #define WSTROBE(x)	((x) << 20)
 #define WSETUP(x)	((x) << 26)
+#define EW(x)		((x) << 30)
+#define SS(x)		((x) << 31)
 
+#define ASIZE_MAX	0x1
 #define TA_MAX		0x3
 #define RHOLD_MAX	0x7
 #define RSTROBE_MAX	0x3f
@@ -34,6 +39,8 @@
 #define WHOLD_MAX	0x7
 #define WSTROBE_MAX	0x3f
 #define WSETUP_MAX	0xf
+#define EW_MAX		0x1
+#define SS_MAX		0x1
 
 #define TIMING_MASK	(TA(TA_MAX) | \
 				RHOLD(RHOLD_MAX) | \
@@ -131,3 +138,80 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
 	return 0;
 }
 EXPORT_SYMBOL(davinci_aemif_setup_timing);
+
+#if defined(CONFIG_OF)
+static int dv_get_value(struct device_node *np, const char *name)
+{
+	u32 data;
+	int ret;
+
+	ret = of_property_read_u32(np, name, &data);
+	if (ret != 0)
+		return ret;
+
+	return data;
+}
+
+int davinci_aemif_setup_timing_of(struct device_node *np)
+{
+	struct device_node *parent;
+	struct davinci_aemif_timing t;
+	void __iomem *base;
+	unsigned val;
+	int asize, ew, ss;
+	int cs;
+	unsigned offset;
+	int ret;
+
+	if (!np)
+		return -ENODEV;
+
+	parent = np->parent;
+	if (!np)
+		return -ENODEV;
+
+	base = of_iomap(parent, 0);
+	if (!base)
+		return -EINVAL;
+
+	cs = dv_get_value(np, "cs");
+	if (cs < 2)
+		return -EINVAL;
+
+	t.ta		= dv_get_value(np, "ta");
+	t.rhold		= dv_get_value(np, "rhold");
+	t.rstrobe	= dv_get_value(np, "rstrobe");
+	t.rsetup	= dv_get_value(np, "rsetup");
+	t.whold		= dv_get_value(np, "whold");
+	t.wstrobe	= dv_get_value(np, "wstrobe");
+	t.wsetup	= dv_get_value(np, "wsetup");
+
+	ret = davinci_aemif_setup_timing(&t, base, cs);
+	if (ret != 0)
+		return ret;
+
+	/* setup none timing paramters */
+	offset = A1CR_OFFSET + cs * 4;
+	asize = dv_get_value(np, "asize");
+	ew = dv_get_value(np, "ew");
+	ss = dv_get_value(np, "ss");
+	val = __raw_readl(base + offset);
+	val &= TIMING_MASK;
+	val |= (asize & ACR_ASIZE_MASK);
+	if (ew)
+		val |= ACR_EW_MASK;
+	if (ss)
+		val |= ACR_SS_MASK;
+
+	__raw_writel(val, base + offset);
+
+	iounmap(base);
+	return 0;
+}
+#else
+int davinci_aemif_setup_timing_of(struct device_node *np)
+{
+	return 0;
+}
+#endif
+EXPORT_SYMBOL(davinci_aemif_setup_timing_of);
diff --git a/arch/arm/mach-davinci/include/mach/aemif.h b/arch/arm/mach-davinci/include/mach/aemif.h
index 05b2934..f3bbec6 100644
--- a/arch/arm/mach-davinci/include/mach/aemif.h
+++ b/arch/arm/mach-davinci/include/mach/aemif.h
@@ -33,4 +33,5 @@ struct davinci_aemif_timing {
 
 int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
 					void __iomem *base, unsigned cs);
+int davinci_aemif_setup_timing_of(struct device_node *np);
 #endif
-- 
1.7.7.6


From hs at denx.de  Wed Feb 22 00:50:07 2012
From: hs at denx.de (Heiko Schocher)
Date: Wed, 22 Feb 2012 07:50:07 +0100
Subject: [PATCH v2 4/7] ARM: davinci: net: davinci_emac: add OF support
In-Reply-To: <1329893410-24413-1-git-send-email-hs@denx.de>
References: <1329893410-24413-1-git-send-email-hs@denx.de>
Message-ID: <1329893410-24413-5-git-send-email-hs@denx.de>

add of support for the davinci_emac driver.

Signed-off-by: Heiko Schocher <hs at denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: netdev at vger.kernel.org
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Wolfgang Denk <wd at denx.de>
Cc: Anatoly Sivov <mm05 at mail.ru>

---
- changes for v2:
  - add comment from Anatoly Sivov
    - fix typo in davinci_emac.txt
  - add comment from Grant Likely:
    - add prefix "ti,davinci-" to davinci specific property names
    - remove version property
    - use compatible name "ti,davinci-dm6460-emac"
    - use devm_kzalloc()
    - use of_match_ptr()
    - document all new properties
    - remove of_address_to_resource() and do not overwrite
      resource table
    - whitespace fixes
    - remove hw_ram_addr as it is not used in current
      board code

Signed-off-by: Heiko Schocher <hs at denx.de>

 .../bindings/arm/davinci/davinci_emac.txt          |   43 +++++++++
 drivers/net/ethernet/ti/davinci_emac.c             |   94 +++++++++++++++++++-
 2 files changed, 136 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt

diff --git a/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
new file mode 100644
index 0000000..a7b0911
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
@@ -0,0 +1,43 @@
+* Texas Instruments Davinci EMAC
+
+This file provides information, what the device node
+for the davinci_emac interface contain.
+
+Required properties:
+- compatible: "ti,davinci-dm6460-emac";
+- reg: Offset and length of the register set for the device
+- ti,davinci-ctrl-reg-offset: offset to control register
+- ti,davinci-ctrl-mod-reg-offset: offset to control module register
+- ti,davinci-ctrl-ram-offset: offset to control module ram
+- ti,davinci-ctrl-ram-size: size of control module ram
+- ti,davinci-rmii-en: use RMII
+- ti,davinci-no-bd-ram: has the emac controller BD RAM
+- phy-handle: Contains a phandle to an Ethernet PHY.
+              if not, davinci_emac driver defaults to 100/FULL
+- interrupts: interrupt mapping for the davinci emac interrupts sources:
+              4 sources: <Receive Threshold Interrupt
+			  Receive Interrupt
+			  Transmit Interrupt
+			  Miscellaneous Interrupt>
+- pinmux-handle: Contains a handle to configure the pinmux settings.
+
+Optional properties:
+- local-mac-address : 6 bytes, mac address
+
+Example (enbw_cmc board):
+	eth0: emac at 1e20000 {
+		compatible = "ti,davinci-dm6460-emac";
+		reg = <0x220000 0x4000>;
+		ti,davinci-ctrl-reg-offset = <0x3000>;
+		ti,davinci-ctrl-mod-reg-offset = <0x2000>;
+		ti,davinci-ctrl-ram-offset = <0>;
+		ti,davinci-ctrl-ram-size = <0x2000>;
+		local-mac-address = [ 00 00 00 00 00 00 ];
+		interrupts = <33
+				34
+				35
+				36
+				>;
+		interrupt-parent = <&intc>;
+		pinmux-handle = <&emac_pins>;
+	};
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 4fa0bcb..56e1c35 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -58,6 +58,12 @@
 #include <linux/io.h>
 #include <linux/uaccess.h>
 #include <linux/davinci_emac.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_net.h>
+
+#include <mach/mux.h>
 
 #include <asm/irq.h>
 #include <asm/page.h>
@@ -339,6 +345,9 @@ struct emac_priv {
 	u32 rx_addr_type;
 	atomic_t cur_tx;
 	const char *phy_id;
+#ifdef CONFIG_OF
+	struct device_node *phy_node;
+#endif
 	struct phy_device *phydev;
 	spinlock_t lock;
 	/*platform specific members*/
@@ -1760,6 +1769,82 @@ static const struct net_device_ops emac_netdev_ops = {
 #endif
 };
 
+#ifdef CONFIG_OF
+static struct emac_platform_data
+	*davinci_emac_of_get_pdata(struct platform_device *pdev,
+	struct emac_priv *priv)
+{
+	struct device_node *np;
+	struct device_node *pinmux_np;
+	struct emac_platform_data *pdata = NULL;
+	const u8 *mac_addr;
+	u32 data;
+	int ret;
+	int version;
+
+	np = pdev->dev.of_node;
+	if (!np)
+		goto nodata;
+	else
+		version = EMAC_VERSION_2;
+
+	pdata = pdev->dev.platform_data;
+	if (!pdata) {
+		pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+		if (!pdata)
+			goto nodata;
+	}
+	pdata->version = version;
+
+	mac_addr = of_get_mac_address(np);
+	if (mac_addr)
+		memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
+
+	ret = of_property_read_u32(np, "ti,davinci-ctrl-reg-offset", &data);
+	if (!ret)
+		pdata->ctrl_reg_offset = data;
+
+	ret = of_property_read_u32(np, "ti,davinci-ctrl-mod-reg-offset",
+		&data);
+	if (!ret)
+		pdata->ctrl_mod_reg_offset = data;
+
+	ret = of_property_read_u32(np, "ti,davinci-ctrl-ram-offset", &data);
+	if (!ret)
+		pdata->ctrl_ram_offset = data;
+
+	ret = of_property_read_u32(np, "ti,davinci-ctrl-ram-size", &data);
+	if (!ret)
+		pdata->ctrl_ram_size = data;
+
+	ret = of_property_read_u32(np, "ti,davinci-rmii-en", &data);
+	if (!ret)
+		pdata->rmii_en = data;
+
+	ret = of_property_read_u32(np, "ti,davinci-no-bd-ram", &data);
+	if (!ret)
+		pdata->no_bd_ram = data;
+
+	priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
+	if (!priv->phy_node)
+		pdata->phy_id = "";
+
+	pinmux_np = of_parse_phandle(np, "pinmux-handle", 0);
+	if (pinmux_np)
+		davinci_cfg_reg_of(pinmux_np);
+
+	pdev->dev.platform_data = pdata;
+nodata:
+	return  pdata;
+}
+#else
+static struct emac_platform_data
+	*davinci_emac_of_get_pdata(struct platform_device *pdev,
+	struct emac_priv *priv)
+{
+	return  pdev->dev.platform_data;
+}
+#endif
 /**
  * davinci_emac_probe: EMAC device probe
  * @pdev: The DaVinci EMAC device that we are removing
@@ -1803,7 +1888,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
 
 	spin_lock_init(&priv->lock);
 
-	pdata = pdev->dev.platform_data;
+	pdata = davinci_emac_of_get_pdata(pdev, priv);
 	if (!pdata) {
 		dev_err(&pdev->dev, "no platform data\n");
 		rc = -ENODEV;
@@ -2013,6 +2098,12 @@ static const struct dev_pm_ops davinci_emac_pm_ops = {
 	.resume		= davinci_emac_resume,
 };
 
+static const struct of_device_id davinci_emac_of_match[] = {
+	{.compatible = "ti,davinci-dm6460-emac", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, davinci_emac_of_match);
+
 /**
  * davinci_emac_driver: EMAC platform driver structure
  */
@@ -2021,6 +2112,7 @@ static struct platform_driver davinci_emac_driver = {
 		.name	 = "davinci_emac",
 		.owner	 = THIS_MODULE,
 		.pm	 = &davinci_emac_pm_ops,
+		.of_match_table = of_match_ptr(davinci_emac_of_match),
 	},
 	.probe = davinci_emac_probe,
 	.remove = __devexit_p(davinci_emac_remove),
-- 
1.7.7.6


From hs at denx.de  Wed Feb 22 00:50:09 2012
From: hs at denx.de (Heiko Schocher)
Date: Wed, 22 Feb 2012 07:50:09 +0100
Subject: [PATCH v2 6/7] ARM: mtd: nand: davinci: add OF support for davinci
	nand controller
In-Reply-To: <1329893410-24413-1-git-send-email-hs@denx.de>
References: <1329893410-24413-1-git-send-email-hs@denx.de>
Message-ID: <1329893410-24413-7-git-send-email-hs@denx.de>

add OF support for the davinci nand controller.

Signed-off-by: Heiko Schocher <hs at denx.de>
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-mtd at lists.infradead.org
Cc: David Woodhouse <dwmw2 at infradead.org>
Cc: Grant Likely <grant.likely at secretlab.ca>
Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Wolfgang Denk <wd at denx.de>
Cc: Scott Wood <scottwood at freescale.com>

---
- changes for v2:
  - add comments from Scott Wood:
    - add "ti,davinci-" prefix
    - Dashes are preferred to underscores
    - rename "nandflash" to "nand"
    - introduce new "ti,davinci" specific properties for setting
      up ecc_mode, ecc_bits, options and bbt options, instead
      using linux defines
    - readme fixes

 .../devicetree/bindings/arm/davinci/nand.txt       |   74 +++++++++++++++++
 drivers/mtd/nand/davinci_nand.c                    |   85 +++++++++++++++++++-
 2 files changed, 158 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt

diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt
new file mode 100644
index 0000000..e02874a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
@@ -0,0 +1,74 @@
+* Texas Instruments Davinci NAND
+
+This file provides information, what the device node for the
+davinci nand interface contain.
+
+Required properties:
+- compatible: "ti,davinci-nand";
+- reg : contain 2 offset/length values:
+        - offset and length for the access window
+        - offset and length for accessing the aemif control registers
+- ti,davinci-chipselect: Indicates on the davinci_nand driver which
+                         chipselect is used for accessing the nand.
+
+Recommended properties :
+- ti,davinci-mask-ale: mask for ale
+- ti,davinci-mask-cle: mask for cle
+- ti,davinci-mask-chipsel: mask for chipselect
+- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
+		- "none"
+		- "soft"
+		- "hw"
+- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
+- ti,davinci-nand-buswidth: buswidth 8 or 16
+- ti,davinci-nand-use-bbt: use flash based bad block table support.
+
+Optional properties:
+- pinmux-handle: contains a handle to configure the pinmux settings.
+- timing-handle: contains a handle to setup aemif timing.
+
+Example (enbw_cmc board):
+aemif at 60000000 {
+	compatible = "ti,davinci-aemif";
+	#address-cells = <2>;
+	#size-cells = <1>;
+	reg = <0x68000000 0x80000>;
+	ranges = <2 0 0x60000000 0x02000000
+		  3 0 0x62000000 0x02000000
+		  4 0 0x64000000 0x02000000
+		  5 0 0x66000000 0x02000000
+		  6 0 0x68000000 0x02000000>;
+	nand_cs: cs3 at 68000000 {
+		compatible = "ti,davinci-cs";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		/* all timings in nanoseconds */
+		cs = <3>;
+		asize = <0>;
+		ta = <0>;
+		rhold = <7>;
+		rstrobe = <42>;
+		rsetup = <7>;
+		whold = <7>;
+		wstrobe = <14>;
+		wsetup = <7>;
+		ew = <0>;
+		ss = <0>;
+	};
+	nand at 3,0 {
+		compatible = "ti,davinci-nand";
+		reg = <3 0x0 0x807ff
+			6 0x0 0x8000>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ti,davinci-chipselect = <1>;
+		ti,davinci-mask-ale = <0>;
+		ti,davinci-mask-cle = <0>;
+		ti,davinci-mask-chipsel = <0>;
+		ti,davinci-ecc-mode = "hw";
+		ti,davinci-ecc-bits = <4>;
+		ti,davinci-nand-use-bbt;
+		pinmux-handle = <&nand_pins>;
+		timing-handle = <&nand_cs>;
+	};
+};
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 6e56615..bdd6edc 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -33,9 +33,12 @@
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
 #include <linux/slab.h>
+#include <linux/of_i2c.h>
+#include <linux/of_device.h>
 
 #include <mach/nand.h>
 #include <mach/aemif.h>
+#include <mach/mux.h>
 
 /*
  * This is a device driver for the NAND flash controller found on the
@@ -518,9 +521,86 @@ static struct nand_ecclayout hwecc4_2048 __initconst = {
 	},
 };
 
+#if defined(CONFIG_OF)
+static const struct of_device_id davinci_nand_of_match[] = {
+	{.compatible = "ti,davinci-nand", },
+	{},
+}
+MODULE_DEVICE_TABLE(of, davinci_nand_of_match);
+
+static struct davinci_nand_pdata
+	*nand_davinci_get_pdata(struct platform_device *pdev)
+{
+	if ((pdev->dev.platform_data == NULL) &&
+		(pdev->dev.of_node)) {
+		struct device_node *tmp_np;
+		struct davinci_nand_pdata *pdata;
+		const char *mode;
+		u32 prop;
+		int len;
+
+		pdata =  kzalloc(sizeof(struct davinci_nand_pdata),
+				GFP_KERNEL);
+		pdev->dev.platform_data = pdata;
+		if (!pdata)
+			return NULL;
+		if (!of_property_read_u32(pdev->dev.of_node,
+			"ti,davinci-chipselect", &prop))
+			pdev->id = prop;
+		if (!of_property_read_u32(pdev->dev.of_node,
+			"ti,davinci-mask-ale", &prop))
+			pdata->mask_ale = prop;
+		if (!of_property_read_u32(pdev->dev.of_node,
+			"ti,davinci-mask-cle", &prop))
+			pdata->mask_cle = prop;
+		if (!of_property_read_u32(pdev->dev.of_node,
+			"ti,davinci-mask-chipsel", &prop))
+			pdata->mask_chipsel = prop;
+		if (!of_property_read_string(pdev->dev.of_node,
+			"ti,davinci-ecc-mode", &mode)) {
+			if (!strncmp("none", mode, 4))
+				pdata->ecc_mode = NAND_ECC_NONE;
+			if (!strncmp("soft", mode, 4))
+				pdata->ecc_mode = NAND_ECC_SOFT;
+			if (!strncmp("hw", mode, 2))
+				pdata->ecc_mode = NAND_ECC_HW;
+		}
+		if (!of_property_read_u32(pdev->dev.of_node,
+			"ti,davinci-ecc-bits", &prop))
+			pdata->ecc_bits = prop;
+		if (!of_property_read_u32(pdev->dev.of_node,
+			"ti,davinci-nand-buswidth", &prop))
+			if (prop == 16)
+				pdata->options |= NAND_BUSWIDTH_16;
+		if (of_find_property(pdev->dev.of_node,
+			"ti,davinci-nand-use-bbt", &len))
+			pdata->bbt_options = NAND_BBT_USE_FLASH;
+
+		tmp_np = of_parse_phandle(pdev->dev.of_node,
+				"pinmux-handle", 0);
+		if (tmp_np)
+			davinci_cfg_reg_of(tmp_np);
+
+		tmp_np = of_parse_phandle(pdev->dev.of_node,
+				"timing-handle", 0);
+		if (tmp_np)
+			davinci_aemif_setup_timing_of(tmp_np);
+	}
+
+	return pdev->dev.platform_data;
+}
+#else
+#define davinci_nand_of_match NULL
+static struct davinci_nand_pdata
+	*nand_davinci_get_pdata(struct platform_device *pdev)
+{
+	return pdev->dev.platform_data;
+}
+#endif
+
 static int __init nand_davinci_probe(struct platform_device *pdev)
 {
-	struct davinci_nand_pdata	*pdata = pdev->dev.platform_data;
+	struct davinci_nand_pdata	*pdata;
 	struct davinci_nand_info	*info;
 	struct resource			*res1;
 	struct resource			*res2;
@@ -530,6 +610,7 @@ static int __init nand_davinci_probe(struct platform_device *pdev)
 	uint32_t			val;
 	nand_ecc_modes_t		ecc_mode;
 
+	pdata = nand_davinci_get_pdata(pdev);
 	/* insist on board-specific configuration */
 	if (!pdata)
 		return -ENODEV;
@@ -815,6 +896,8 @@ static struct platform_driver nand_davinci_driver = {
 	.remove		= __exit_p(nand_davinci_remove),
 	.driver		= {
 		.name	= "davinci_nand",
+		.owner	= THIS_MODULE,
+		.of_match_table = davinci_nand_of_match,
 	},
 };
 MODULE_ALIAS("platform:davinci_nand");
-- 
1.7.7.6


From hs at denx.de  Wed Feb 22 00:50:10 2012
From: hs at denx.de (Heiko Schocher)
Date: Wed, 22 Feb 2012 07:50:10 +0100
Subject: [PATCH v2 7/7] ARM: davinci: add support for the am1808 based
	enbw_cmc board
In-Reply-To: <1329893410-24413-1-git-send-email-hs@denx.de>
References: <1329893410-24413-1-git-send-email-hs@denx.de>
Message-ID: <1329893410-24413-8-git-send-email-hs@denx.de>

- AM1808 based board
- 64 MiB DDR ram
- 2 MiB Nor flash
- 128 MiB NAND flash
- use internal RTC
- I2C support
- hwmon lm75 support
- UBI/UBIFS support
- MMC support
- USB OTG support

Signed-off-by: Heiko Schocher <hs at denx.de>
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree-discuss at lists.ozlabs.org
Cc: davinci-linux-open-source at linux.davincidsp.com
Cc: linux-mtd at lists.infradead.org
Cc: linux-i2c at vger.kernel.org
Cc: netdev at vger.kernel.org
Cc: David Woodhouse <dwmw2 at infradead.org>
Cc: Ben Dooks <ben-linux at fluff.org>
Cc: Wolfram Sang <w.sang at pengutronix.de>
Cc: Sekhar Nori <nsekhar at ti.com>
Cc: Kevin Hilman <khilman at ti.com>
Cc: Wolfgang Denk <wd at denx.de>
Cc: Scott Wood <scottwood at freescale.com>
Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>

---
- post this board support with USB support, even though
  USB is only working with the 10 ms "workaround", posted here:
  http://comments.gmane.org/gmane.linux.usb.general/54505
  I see this issue also on the AM1808 TMDXEXP1808L evalboard.
- MMC and USB are not using OF support yet, ideas how to port
  this are welcome. I need for USB and MMC boards board
  specific callbacks, how to solve this with OF support?

- changes for v2:
  - changes in the nand node due to comments from Scott Wood:
    - add "ti,davinci-" prefix
    - Dashes are preferred to underscores
    - rename "nandflash" to "nand"
    - introduce new "ti,davinci" specific properties for setting
      up ecc_mode, ecc_bits, options and bbt options, instead
      using linux defines
  - changes for i2c due to comments from Sylwester Nawrocki:
    - use "cell-index" instead "id"
    - OF_DEV_AUXDATA in the machine code, instead pre-define
      platform device name
  - add comment from Grant Likely for i2c:
    - removed "id" resp. "cell-index" completely
    - fixed documentation
    - use of_match_ptr()
    - use devm_kzalloc() for allocating plattform data mem
    - fixed a whitespace issue
  - add net comments from Grant Likely:
    - add prefix "ti,davinci-" to davinci specific property names
    - remove version property
    - use compatible name "ti,davinci-dm6460-emac"
  - add comment from Grant Likely:
    - rename compatible node
    - do not use cell-index
    - CONFIG_OF required for this board
    TODO:
    - create a generic board support file, as I got no
      answer to my ping to grant, maybe this could be done
      in a second step?

 arch/arm/boot/dts/enbw_cmc.dts                  |  268 ++++++++++++++++
 arch/arm/configs/enbw_cmc_defconfig             |  123 ++++++++
 arch/arm/mach-davinci/Kconfig                   |    9 +
 arch/arm/mach-davinci/Makefile                  |    1 +
 arch/arm/mach-davinci/board-enbw-cmc.c          |  380 +++++++++++++++++++++++
 arch/arm/mach-davinci/include/mach/uncompress.h |    1 +
 6 files changed, 782 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
 create mode 100644 arch/arm/configs/enbw_cmc_defconfig
 create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c

diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts
new file mode 100644
index 0000000..df41f85
--- /dev/null
+++ b/arch/arm/boot/dts/enbw_cmc.dts
@@ -0,0 +1,268 @@
+/*
+ * Device Tree for the EnBW CMC plattform
+ *
+ * Copyright 2011 DENX Software Engineering GmbH
+ * Heiko Schocher <hs at denx.de>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "EnBW CMC";
+	compatible = "enbw,cmc";
+
+	aliases {
+		ethernet0 = &eth0;
+	};
+
+	arm {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0xfffee000 0x00020000>;
+		intc: interrupt-controller at 1 {
+			compatible = "ti,davinci-intc";
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			ti,intc-size = <101>;
+			reg = <0x0 0x2000>;
+		};
+	};
+	soc at 1c00000 {
+		compatible = "ti,da850";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x01c00000 0x400000>;
+
+		serial0: serial at 1c42000 {
+			compatible = "ti,da850", "ns16550a";
+			reg = <0x42000 0x100>;
+			clock-frequency = <150000000>;
+			reg-shift = <2>;
+			interrupts = <25>;
+			interrupt-parent = <&intc>;
+		};
+		serial1: serial at 1d0c000 {
+			compatible = "ti,da850", "ns16550a";
+			reg = <0x10c000 0x100>;
+			clock-frequency = <150000000>;
+			reg-shift = <2>;
+			interrupts = <53>;
+			interrupt-parent = <&intc>;
+		};
+		serial2: serial at 1d0d000 {
+			compatible = "ti,da850", "ns16550a";
+			reg = <0x10d000 0x100>;
+			clock-frequency = <150000000>;
+			reg-shift = <2>;
+			interrupts = <61>;
+			interrupt-parent = <&intc>;
+		};
+
+		nor_pins: nor_pinmux at 1c14120 {
+			compatible = "ti,davinci-pinmux";
+			reg = <0x14120 0x1000>;
+			pins = < /*	muxreg	maskoff	modemsk muxmode */
+					5	24	15	1 /* EMA_BA_1 */
+					6	0	15	1 /* EMA CLK */
+					6	24	15	1 /* EMA_WAIT_1 */
+					7	0	15	1 /* NEMA_CS_2 */
+					7	16	15	1 /* NEMA_WE */
+					7	20	15	1 /* NEMA_OE */
+					9	28	15	1 /* EMA_D_0 */
+					9	24	15	1 /* EMA_D_1 */
+					9	20	15	1 /* EMA_D_2 */
+					9	16	15	1 /* EMA_D_3 */
+					9	12	15	1 /* EMA_D_4 */
+					9	8	15	1 /* EMA_D_5 */
+					9	4	15	1 /* EMA_D_6 */
+					9	0	15	1 /* EMA_D_7 */
+					8	28	15	1 /* EMA_D_8 */
+					8	24	15	1 /* EMA_D_9 */
+					8	20	15	1 /* EMA_D_10 */
+					8	16	15	1 /* EMA_D_11 */
+					8	12	15	1 /* EMA_D_12 */
+					8	8	15	1 /* EMA_D_13 */
+					8	4	15	1 /* EMA_D_14 */
+					8	0	15	1 /* EMA_D_15 */
+					12	28	15	1 /* EMA_A_0 */
+					12	24	15	1 /* EMA_A_1 */
+					12	20	15	1 /* EMA_A_2 */
+					12	16	15	1 /* EMA_A_3 */
+					12	12	15	1 /* EMA_A_4 */
+					12	8	15	1 /* EMA_A_5 */
+					12	4	15	1 /* EMA_A_6 */
+					12	0	15	1 /* EMA_A_7 */
+					11	28	15	1 /* EMA_A_8 */
+					11	24	15	1 /* EMA_A_9 */
+					11	20	15	1 /* EMA_A_10 */
+					11	16	15	1 /* EMA_A_11 */
+					11	12	15	1 /* EMA_A_12 */
+					11	8	15	1 /* EMA_A_13 */
+					11	4	15	1 /* EMA_A_14 */
+					11	0	15	1 /* EMA_A_15 */
+					10	28	15	1 /* EMA_A_16 */
+					10	24	15	1 /* EMA_A_17 */
+					10	20	15	1 /* EMA_A_18 */
+					10	16	15	1 /* EMA_A_19 */
+					10	12	15	1 /* EMA_A_20 */
+					10	8	15	1 /* EMA_A_21 */
+					10	4	15	1 /* EMA_A_22 */
+					10	0	15	1 /* EMA_A_23 */
+				>;
+		};
+		nand_pins: nand_pinmux at 1c14120 {
+			compatible = "ti,davinci-pinmux";
+			reg = <0x14120 0x1000>;
+			pins = < /*	muxreg	maskoff	modemsk muxmode */
+					7	4	15	1 /* NEMA_CS_3 */
+				>;
+		};
+
+		emac_pins: pinmux at 1c14120 {
+			compatible = "ti,davinci-pinmux";
+			reg = <0x14120 0x1000>;
+			pins = < /*	muxreg	maskoff	modemsk muxmode */
+					2	4	15	8 /* MII TXEN */
+					2	8	15	8 /* MII TXCLK */
+					2	12	15	8 /* MII COL */
+					2	16	15	8 /* MII TXD_3 */
+					2	20	15	8 /* MII TXD_2 */
+					2	24	15	8 /* MII TXD_1 */
+					2	28	15	8 /* MII TXD_0 */
+					3	8	15	8 /* MII RXER */
+					3	12	15	8 /* MII CRS */
+					3	0	15	8 /* MII RXCLK */
+					3	4	15	8 /* MII RXDV */
+					3	16	15	8 /* MII RXD_3 */
+					3	20	15	8 /* MII RXD_2 */
+					3	24	15	8 /* MII RXD_1 */
+					3	28	15	8 /* MII RXD_0 */
+					4	0	15	8 /* MDIO CLK */
+					4	4	15	8 /* MDIO D */
+				>;
+		};
+
+		i2c1_pins: i2c_pinmux at 1c14120 {
+			compatible = "ti,davinci-pinmux";
+			reg = <0x14120 0x1000>;
+			pins = < /*	muxreg	maskoff	modemsk muxmode */
+					4	12	15	2 /* I2C0 SDA */
+					4	8	15	2 /* I2C0 SCL */
+				>;
+		};
+
+		eth0: emac at 1e20000 {
+			compatible = "ti,davinci-dm6460-emac";
+			reg = <0x220000 0x4000>;
+			ti,davinci-ctrl-reg-offset = <0x3000>;
+			ti,davinci-ctrl-mod-reg-offset = <0x2000>;
+			ti,davinci-ctrl-ram-offset = <0>;
+			ti,davinci-ctrl-ram-size = <0x2000>;
+			local-mac-address = [ 00 00 00 00 00 00 ];
+			interrupts = <33
+					34
+					35
+					36
+					>;
+			interrupt-parent = <&intc>;
+			pinmux-handle = <&emac_pins>;
+		};
+
+		i2c at 1c22000 {
+			compatible = "ti,davinci-i2c";
+			reg = <0x22000 0x1000>;
+			clock-frequency = <100000>;
+			interrupts = <15>;
+			interrupt-parent = <&intc>;
+			pinmux-handle = <&i2c1_pins>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			dtt at 48 {
+				compatible = "national,lm75";
+				reg = <0x48>;
+			};
+		};
+	};
+	onchipram at 8000000 {
+		compatible = "ti,davinci-onchipram";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x80000000 0x20000>;
+	};
+	aemif at 60000000 {
+		compatible = "ti,davinci-aemif";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		reg = <0x68000000 0x80000>;
+		ranges = <2 0 0x60000000 0x02000000
+			  3 0 0x62000000 0x02000000
+			  4 0 0x64000000 0x02000000
+			  5 0 0x66000000 0x02000000
+			  6 0 0x68000000 0x02000000>;
+		cs2 at 68000000 {
+			compatible = "ti,davinci-cs";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			/* all timings in nanoseconds */
+			cs = <2>;
+			asize = <1>;
+			ta = <0>;
+			rhold = <7>;
+			rstrobe = <42>;
+			rsetup = <14>;
+			whold = <7>;
+			wstrobe = <42>;
+			wsetup = <14>;
+			ew = <0>;
+			ss = <0>;
+		};
+		flash at 2,0 {
+			compatible = "cfi-flash";
+			reg = <2 0x0 0x400000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			bank-width = <2>;
+			device-width = <2>;
+		};
+		nand_cs: cs3 at 68000000 {
+			compatible = "ti,davinci-cs";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			/* all timings in nanoseconds */
+			cs = <3>;
+			asize = <0>;
+			ta = <0>;
+			rhold = <7>;
+			rstrobe = <42>;
+			rsetup = <7>;
+			whold = <7>;
+			wstrobe = <14>;
+			wsetup = <7>;
+			ew = <0>;
+			ss = <0>;
+		};
+		nand at 3,0 {
+			compatible = "ti,davinci-nand";
+			reg = <3 0x0 0x807ff
+				6 0x0 0x8000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ti,davinci-chipselect = <1>;
+			ti,davinci-mask-ale = <0>;
+			ti,davinci-mask-cle = <0>;
+			ti,davinci-mask-chipsel = <0>;
+			ti,davinci-ecc-mode = "hw";
+			ti,davinci-ecc-bits = <4>;
+			ti,davinci-nand-use-bbt;
+			pinmux-handle = <&nand_pins>;
+			timing-handle = <&nand_cs>;
+		};
+
+	};
+};
diff --git a/arch/arm/configs/enbw_cmc_defconfig b/arch/arm/configs/enbw_cmc_defconfig
new file mode 100644
index 0000000..9d98e7f
--- /dev/null
+++ b/arch/arm/configs/enbw_cmc_defconfig
@@ -0,0 +1,123 @@
+CONFIG_EXPERIMENTAL=y
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_EXPERT=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_DAVINCI=y
+CONFIG_ARCH_DAVINCI_DA850=y
+# CONFIG_MACH_DAVINCI_DA850_EVM is not set
+CONFIG_GPIO_PCA953X=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+# CONFIG_OABI_COMPAT is not set
+CONFIG_USE_OF=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_LRO is not set
+CONFIG_IPV6=y
+CONFIG_NETFILTER=y
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+# CONFIG_FW_LOADER is not set
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_DAVINCI=y
+CONFIG_MTD_UBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=1
+CONFIG_BLK_DEV_RAM_SIZE=32768
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_NETDEVICES=y
+CONFIG_MII=y
+CONFIG_TI_DAVINCI_EMAC=y
+# CONFIG_WLAN is not set
+CONFIG_INPUT_POLLDEV=y
+# CONFIG_INPUT_MOUSEDEV is not set
+CONFIG_INPUT_EVDEV=y
+CONFIG_INPUT_EVBUG=y
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=3
+CONFIG_SERIAL_8250_RUNTIME_UARTS=3
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_HW_RANDOM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_DAVINCI=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_PCF857X=y
+CONFIG_SENSORS_LM75=y
+CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+CONFIG_DAVINCI_WATCHDOG=y
+# CONFIG_HID_SUPPORT is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_MUSB_HDRC=y
+CONFIG_USB_MUSB_DA8XX=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_UAS=y
+CONFIG_USB_LIBUSUAL=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_FUSB300=y
+CONFIG_USB_ETH=y
+CONFIG_MMC=y
+CONFIG_MMC_DAVINCI=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_OMAP=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+CONFIG_AUTOFS4_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_UBIFS_FS=y
+CONFIG_CRAMFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_DEBUG_FS=y
+CONFIG_TIMER_STATS=y
+CONFIG_DEBUG_RT_MUTEXES=y
+CONFIG_DEBUG_MUTEXES=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+# CONFIG_CRYPTO_HW is not set
+CONFIG_CRC_CCITT=m
+CONFIG_CRC_T10DIF=m
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 32d837d..4cb0469 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -202,6 +202,15 @@ config DA850_WL12XX
 	  Say Y if you want to use a wl1271 expansion card connected to the
 	  AM18x EVM.
 
+config MACH_ENBW_CMC
+	bool "EnBW Communication Module Compact"
+	default ARCH_DAVINCI_DA850
+	depends on ARCH_DAVINCI_DA850
+	select OF
+	help
+	  Say Y here to select the EnBW Communication Module Compact
+	  board.
+
 config GPIO_PCA953X
 	default MACH_DAVINCI_DA850_EVM
 
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 2db78bd..12f3166 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_MACH_DAVINCI_DA850_EVM)	+= board-da850-evm.o
 obj-$(CONFIG_MACH_TNETV107X)		+= board-tnetv107x-evm.o
 obj-$(CONFIG_MACH_MITYOMAPL138)		+= board-mityomapl138.o
 obj-$(CONFIG_MACH_OMAPL138_HAWKBOARD)	+= board-omapl138-hawk.o
+obj-$(CONFIG_MACH_ENBW_CMC)		+= board-enbw-cmc.o
 
 # Power Management
 obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o
diff --git a/arch/arm/mach-davinci/board-enbw-cmc.c b/arch/arm/mach-davinci/board-enbw-cmc.c
new file mode 100644
index 0000000..c2fc4c9
--- /dev/null
+++ b/arch/arm/mach-davinci/board-enbw-cmc.c
@@ -0,0 +1,380 @@
+/*
+ * EnBW Communication Module Compact board
+ * Copyright 2011 DENX Software Engineering GmbH
+ * Author: Heiko Schocher <hs at denx.de>
+ *
+ * based on:
+ * TI DA850/OMAP-L138 EVM board
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Derived from: arch/arm/mach-davinci/board-da850-evm.c
+ * Original Copyrights follow:
+ *
+ * 2007, 2009 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#include <linux/console.h>
+#include <linux/gpio.h>
+#include <linux/gpio_keys.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/physmap.h>
+#include <linux/of.h>
+#include <linux/of_net.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/phy.h>
+#include <linux/phy_fixed.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/aemif.h>
+#include <mach/cp_intc.h>
+#include <mach/da8xx.h>
+#include <mach/mux.h>
+#include <mach/nand.h>
+#include <mach/spi.h>
+
+#define ENBW_CMC_MMCSD_CD_PIN          GPIO_TO_PIN(3, 13)
+
+/*
+ * USB1 VBUS is controlled by GPIO7[12], over-current is reported on GPIO7[8].
+ */
+#define DA850_USB_VBUS_PIN	GPIO_TO_PIN(7, 12)
+#define ON_BD_USB_OVC		GPIO_TO_PIN(7, 8)
+
+#if defined(CONFIG_USB_OHCI_HCD)
+static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id);
+static da8xx_ocic_handler_t enbw_cmc_usb_ocic_handler;
+
+static int enbw_cmc_usb_set_power(unsigned port, int on)
+{
+	gpio_set_value(DA850_USB_VBUS_PIN, on);
+	return 0;
+}
+
+static int enbw_cmc_usb_get_power(unsigned port)
+{
+	return gpio_get_value(DA850_USB_VBUS_PIN);
+}
+
+static int enbw_cmc_usb_get_oci(unsigned port)
+{
+	return !gpio_get_value(ON_BD_USB_OVC);
+}
+
+static irqreturn_t enbw_cmc_usb_ocic_irq(int, void *);
+
+static int enbw_cmc_usb_ocic_notify(da8xx_ocic_handler_t handler)
+{
+	int irq         = gpio_to_irq(ON_BD_USB_OVC);
+	int error       = 0;
+
+	if (handler != NULL) {
+		enbw_cmc_usb_ocic_handler = handler;
+
+		error = request_irq(irq, enbw_cmc_usb_ocic_irq,
+					IRQF_DISABLED | IRQF_TRIGGER_RISING |
+					IRQF_TRIGGER_FALLING,
+					"OHCI over-current indicator", NULL);
+		if (error)
+			pr_err("%s: could not request IRQ to watch "
+				"over-current indicator changes\n", __func__);
+	} else {
+		free_irq(irq, NULL);
+	}
+	return error;
+}
+
+static struct da8xx_ohci_root_hub enbw_cmc_usb11_pdata = {
+	.set_power      = enbw_cmc_usb_set_power,
+	.get_power      = enbw_cmc_usb_get_power,
+	.get_oci        = enbw_cmc_usb_get_oci,
+	.ocic_notify    = enbw_cmc_usb_ocic_notify,
+	.potpgt         = (10 + 1) / 2,  /* 10 ms max */
+};
+
+static irqreturn_t enbw_cmc_usb_ocic_irq(int irq, void *dev_id)
+{
+	enbw_cmc_usb_ocic_handler(&enbw_cmc_usb11_pdata, 1);
+	return IRQ_HANDLED;
+}
+#endif
+
+static __init void enbw_cmc_usb_init(void)
+{
+	int ret;
+	u32 cfgchip2;
+
+	/* Set up USB clock/mode in the CFGCHIP2 register. */
+	cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+	/* USB2.0 PHY reference clock is AUXCLK with 24MHz */
+	cfgchip2 &= ~CFGCHIP2_REFFREQ;
+	cfgchip2 |=  CFGCHIP2_REFFREQ_24MHZ;
+
+	/*
+	 * Select internal reference clock for USB 2.0 PHY
+	 * and use it as a clock source for USB 1.1 PHY
+	 * (this is the default setting anyway).
+	 */
+	cfgchip2 &= ~CFGCHIP2_USB1PHYCLKMUX;
+	cfgchip2 |=  CFGCHIP2_USB2PHYCLKMUX;
+
+	cfgchip2 &= ~CFGCHIP2_OTGMODE;
+	cfgchip2 |=  CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
+
+	__raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
+
+	ret = davinci_cfg_reg(DA830_USB0_DRVVBUS);
+	if (ret)
+		pr_warning("%s: USB 2.0 PinMux setup failed: %d\n",
+			   __func__, ret);
+	else {
+		/*
+		 * SP2525A @ 5V supplies 500mA,
+		 * with the power on to power good time of 10 ms.
+		 */
+		ret = da8xx_register_usb20(500, 10);
+		if (ret)
+			pr_warning("%s: USB 2.0 registration failed: %d\n",
+				   __func__, ret);
+	}
+
+#if defined(CONFIG_USB_OHCI_HCD)
+	ret = gpio_request_one(DA850_USB_VBUS_PIN,
+			GPIOF_DIR_OUT, "USB 1.1 VBUS");
+	if (ret < 0) {
+		pr_err("%s: failed to request GPIO for USB 1.1 port "
+			"power control: %d\n", __func__, ret);
+		return;
+	}
+	gpio_direction_input(DA850_USB_VBUS_PIN);
+
+	ret = gpio_request(ON_BD_USB_OVC, "ON_BD_USB_OVC");
+	if (ret) {
+		printk(KERN_ERR "%s: failed to request GPIO for USB 1.1 port "
+		       "over-current indicator: %d\n", __func__, ret);
+		gpio_free(DA850_USB_VBUS_PIN);
+		return;
+	}
+	gpio_direction_input(ON_BD_USB_OVC);
+
+	ret = da8xx_register_usb11(&enbw_cmc_usb11_pdata);
+	if (ret) {
+		pr_warning("%s: USB 1.1 registration failed: %d\n",
+			   __func__, ret);
+		gpio_free(ON_BD_USB_OVC);
+		gpio_free(DA850_USB_VBUS_PIN);
+	}
+#endif
+
+	return;
+}
+
+static int enbw_cmc_mmc_get_ro(int index)
+{
+	return 0;
+}
+
+static int enbw_cmc_mmc_get_cd(int index)
+{
+	return gpio_get_value(ENBW_CMC_MMCSD_CD_PIN) ? 1 : 0;
+}
+
+static struct davinci_mmc_config enbw_cmc_mmc_config = {
+	.get_ro		= enbw_cmc_mmc_get_ro,
+	.get_cd		= enbw_cmc_mmc_get_cd,
+	.wires		= 4,
+	.max_freq	= 50000000,
+	.caps		= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
+	.version	= MMC_CTLR_VERSION_2,
+};
+
+static int __init enbw_cmc_config_emac(void)
+{
+	void __iomem *cfg_chip3_base;
+	u32 val;
+	struct davinci_soc_info *soc_info = &davinci_soc_info;
+
+	if (!machine_is_enbw_cmc())
+		return 0;
+
+	cfg_chip3_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP3_REG);
+	val = __raw_readl(cfg_chip3_base);
+	val &= ~BIT(8);
+	pr_info("EMAC: MII PHY configured, RMII PHY will not be"
+						" functional\n");
+
+	/* configure the CFGCHIP3 register for MII */
+	__raw_writel(val, cfg_chip3_base);
+
+	/* use complete info from OF */
+	soc_info->emac_pdata = NULL;
+
+	return 0;
+}
+device_initcall(enbw_cmc_config_emac);
+
+static const s16 da850_dma0_rsv_chans[][2] = {
+	/* (offset, number) */
+	{-1, -1}
+};
+
+static const s16 da850_dma0_rsv_slots[][2] = {
+	/* (offset, number) */
+	{-1, -1}
+};
+
+static const s16 da850_dma1_rsv_chans[][2] = {
+	/* (offset, number) */
+	{-1, -1}
+};
+
+static const s16 da850_dma1_rsv_slots[][2] = {
+	/* (offset, number) */
+	{-1, -1}
+};
+
+static struct edma_rsv_info da850_edma_cc0_rsv = {
+	.rsv_chans	= da850_dma0_rsv_chans,
+	.rsv_slots	= da850_dma0_rsv_slots,
+};
+
+static struct edma_rsv_info da850_edma_cc1_rsv = {
+	.rsv_chans	= da850_dma1_rsv_chans,
+	.rsv_slots	= da850_dma1_rsv_slots,
+};
+
+static struct edma_rsv_info *da850_edma_rsv[2] = {
+	&da850_edma_cc0_rsv,
+	&da850_edma_cc1_rsv,
+};
+
+#ifdef CONFIG_CPU_FREQ
+static __init int da850_evm_init_cpufreq(void)
+{
+	switch (system_rev & 0xF) {
+	case 3:
+		da850_max_speed = 456000;
+		break;
+	case 2:
+		da850_max_speed = 408000;
+		break;
+	case 1:
+		da850_max_speed = 372000;
+		break;
+	}
+
+	return da850_register_cpufreq("pll0_sysclk3");
+}
+#else
+static __init int da850_evm_init_cpufreq(void) { return 0; }
+#endif
+
+struct of_dev_auxdata enbw_cmc_auxdata_lookup[] __initdata = {
+	OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "ti,davinci-wdt", NULL),
+	OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
+	OF_DEV_AUXDATA("ti,davinci-i2c", 0x01e28000, "i2c_davinci.2", NULL),
+	OF_DEV_AUXDATA("ti,davinci-dm6460-emac", 0x01e20000, "davinci_emac.1",
+			NULL),
+	{}
+};
+
+const struct of_device_id enbw_cmc_bus_match_table[] = {
+	{ .compatible = "simple-bus", },
+	{ .compatible = "ti,da850", },
+	{ .compatible = "ti,davinci-onchipram", },
+	{ .compatible = "ti,davinci-aemif", },
+	{} /* Empty terminated list */
+};
+
+static __init void enbw_cmc_init(void)
+{
+	int ret;
+
+	of_platform_populate(NULL, enbw_cmc_bus_match_table,
+		enbw_cmc_auxdata_lookup, NULL);
+
+	ret = da8xx_register_watchdog();
+	if (ret)
+		pr_warning("da830_evm_init: watchdog registration failed: %d\n",
+				ret);
+
+	ret = da850_register_edma(da850_edma_rsv);
+	if (ret)
+		pr_warning("enbw_cmc_init: edma registration failed: %d\n",
+				ret);
+
+	/*
+	 * shut down uart 0 this port is not used on the board
+	 */
+	__raw_writel(0, IO_ADDRESS(DA8XX_UART0_BASE) + 0x30);
+
+	ret = da8xx_register_rtc();
+	if (ret)
+		pr_warning("enbw_cmc_init: rtc setup failed: %d\n", ret);
+
+	ret = da850_evm_init_cpufreq();
+	if (ret)
+		pr_warning("enbw_cmc_init: cpufreq registration failed: %d\n",
+				ret);
+
+	ret = da8xx_register_cpuidle();
+	if (ret)
+		pr_warning("enbw_cmc_init: cpuidle registration failed: %d\n",
+				ret);
+
+	ret = gpio_request(ENBW_CMC_MMCSD_CD_PIN, "MMC CD\n");
+	if (ret)
+		pr_warning("enbw_cmc_init: can not open GPIO %d\n",
+				ENBW_CMC_MMCSD_CD_PIN);
+	gpio_direction_input(ENBW_CMC_MMCSD_CD_PIN);
+
+	ret = da850_register_mmcsd1(&enbw_cmc_mmc_config);
+	if (ret)
+		pr_warning("enbw_cmc_init: mmcsd1 registration failed:"
+				" %d\n", ret);
+
+	enbw_cmc_usb_init();
+}
+
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+static int __init enbw_cmc_console_init(void)
+{
+	if (!machine_is_enbw_cmc())
+		return 0;
+
+	return add_preferred_console("ttyS", 2, "115200");
+}
+console_initcall(enbw_cmc_console_init);
+#endif
+
+static void __init enbw_cmc_map_io(void)
+{
+	da850_init();
+}
+
+static const char *enbw_cmc_board_compat[] __initconst = {
+	"enbw,cmc",
+	NULL
+};
+
+MACHINE_START(ENBW_CMC, "EnBW CMC")
+	.map_io		= enbw_cmc_map_io,
+	.init_irq	= davinci_init_irq,
+	.timer		= &davinci_timer,
+	.init_machine	= enbw_cmc_init,
+	.dt_compat	= enbw_cmc_board_compat,
+	.dma_zone_size	= SZ_128M,
+	.restart	= da8xx_restart,
+MACHINE_END
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h b/arch/arm/mach-davinci/include/mach/uncompress.h
index 9dc7cf9..2f21384 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -96,6 +96,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id)
 		DEBUG_LL_DA8XX(davinci_da850_evm,	2);
 		DEBUG_LL_DA8XX(mityomapl138,		1);
 		DEBUG_LL_DA8XX(omapl138_hawkboard,	2);
+		DEBUG_LL_DA8XX(enbw_cmc,		2);
 
 		/* TNETV107x boards */
 		DEBUG_LL_TNETV107X(tnetv107x,		1);
-- 
1.7.7.6


From sshtylyov at mvista.com  Wed Feb 22 06:23:00 2012
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 22 Feb 2012 16:23:00 +0400
Subject: [PATCH v2 1/7] ARM: davinci, intc: Add OF support for TI interrupt
	controller
In-Reply-To: <1329893410-24413-2-git-send-email-hs@denx.de>
References: <1329893410-24413-1-git-send-email-hs@denx.de>
	<1329893410-24413-2-git-send-email-hs@denx.de>
Message-ID: <4F44DE24.30606@mvista.com>

Hello.

On 22-02-2012 10:50, Heiko Schocher wrote:

> Add a function to initialize the davinci interrupt controller (INTC)
> using a device tree node.

    cp_intc is not DaVinci interrupt controller, it's only used in OMAP-L1x 
SoCs. cp_intc stands for Common Platform Interrupt Controller. I don't see 
where you are initializiing the DaVinci interrupt controller itself. You 
should understand that there are two disctinct types of interrupt controllers 
used in the SoCs supported by arch/arm/mach-davinci/.

> Signed-off-by: Heiko Schocher<hs at denx.de>
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: Grant Likely<grant.likely at secretlab.ca>
> Cc: Sekhar Nori<nsekhar at ti.com>
> Cc: Wolfgang Denk<wd at denx.de>

[...]

> diff --git a/Documentation/devicetree/bindings/arm/davinci/intc.txt b/Documentation/devicetree/bindings/arm/davinci/intc.txt
> new file mode 100644
> index 0000000..dac2f69
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/intc.txt
> @@ -0,0 +1,26 @@
> +* TI Davinci Interrupt Controller
> +
> +davinci are using a TI interrupt controller that can support several
> +configurable number of interrupts.
> +
> +Main node required properties:
> +
> +- compatible : should be:
> +	"ti,davinci-intc"

    The right "compatible" prop would be "ti,cp_intc" in this case.

WBR, Sergei

From nsekhar at ti.com  Wed Feb 22 09:40:01 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Wed, 22 Feb 2012 15:40:01 +0000
Subject: [PATCH 4/4] davinci: da850: add build configuration for vpif
	drivers
In-Reply-To: <1327503934-28186-5-git-send-email-manjunath.hadli@ti.com>
References: <1327503934-28186-1-git-send-email-manjunath.hadli@ti.com>
	<1327503934-28186-5-git-send-email-manjunath.hadli@ti.com>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317CA28E@DBDE01.ent.ti.com>

Hi Manju,

On Wed, Jan 25, 2012 at 20:35:34, Hadli, Manjunath wrote:
> add build configuration for da850/omapl-138 for vpif
> capture and display drivers.
> 
> Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>
> ---
>  drivers/media/video/davinci/Kconfig  |   26 +++++++++++++++++++++++++-
>  drivers/media/video/davinci/Makefile |    5 +++++
>  2 files changed, 30 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig
> index 60a456e..a0b0fb3 100644
> --- a/drivers/media/video/davinci/Kconfig
> +++ b/drivers/media/video/davinci/Kconfig
> @@ -22,9 +22,33 @@ config CAPTURE_DAVINCI_DM646X_EVM
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called vpif_capture.
>  
> +config DISPLAY_DAVINCI_DA850_EVM
> +	tristate "DA850/OMAPL138 EVM Video Display"
> +	depends on DA850_UI_SD_VIDEO_PORT && VIDEO_DEV && MACH_DAVINCI_DA850_EVM
> +	select VIDEOBUF_DMA_CONTIG
> +	select VIDEO_DAVINCI_VPIF
> +	select VIDEO_ADV7343
> +	select VIDEO_THS7303

Selecting these helper chips should be conditional on
VIDEO_HELPER_CHIPS_AUTO. This is what I gather looking
at existing Kconfig files like drivers/media/video/em28xx/Kconfig.

This issue exists with existing code too, so that should
be addressed separately.

> +	help
> +	  Support for DA850/OMAP-L138/AM18xx  based display device.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called vpif_display.
> +
> +config CAPTURE_DAVINCI_DA850_EVM
> +	tristate "DA850/OMAPL138 EVM Video Capture"
> +	depends on DA850_UI_SD_VIDEO_PORT && VIDEO_DEV && MACH_DAVINCI_DA850_EVM
> +	select VIDEOBUF_DMA_CONTIG
> +	select VIDEO_DAVINCI_VPIF
> +	help
> +	  Support for DA850/OMAP-L138/AM18xx  based capture device.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called vpif_capture.
> +
>  config VIDEO_DAVINCI_VPIF
>  	tristate "DaVinci VPIF Driver"
> -	depends on DISPLAY_DAVINCI_DM646X_EVM
> +	depends on DISPLAY_DAVINCI_DM646X_EVM || DISPLAY_DAVINCI_DA850_EVM
>  	help
>  	  Support for DaVinci VPIF Driver.
>  
> diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile
> index ae7dafb..2c7cfb0 100644
> --- a/drivers/media/video/davinci/Makefile
> +++ b/drivers/media/video/davinci/Makefile
> @@ -10,6 +10,11 @@ obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o
>  #DM646x EVM Capture driver
>  obj-$(CONFIG_CAPTURE_DAVINCI_DM646X_EVM) += vpif_capture.o
>  
> +#DA850 EVM Display driver
> +obj-$(CONFIG_DISPLAY_DAVINCI_DA850_EVM) += vpif_display.o
> +#DA850 EVM Capture driver
> +obj-$(CONFIG_CAPTURE_DAVINCI_DA850_EVM) += vpif_capture.o

Repeating these lines in the makefile for every board that
gets VPIF support seems certainly excessive. Instead why not
convert the existing DM646x specific config variables to
generic VPIF display and capture config variables and select
these generic variables when someone chooses DA850 support.

Thanks,
Sekhar


From christian.riesch at omicron.at  Wed Feb 22 10:26:51 2012
From: christian.riesch at omicron.at (Christian Riesch)
Date: Wed, 22 Feb 2012 17:26:51 +0100
Subject: [RFC PATCH] davinci_emac: Do not accidentally free all rx dma
	descriptors during init
Message-ID: <1329928011-32746-1-git-send-email-christian.riesch@omicron.at>

This patch fixes a regression that was introduced by

commit 0a5f38467765ee15478db90d81e40c269c8dda20
davinci_emac: Add Carrier Link OK check in Davinci RX Handler

Said commit adds a check whether the carrier link is ok. If the link is
not ok, the skb is freed and no new dma descriptor added to the rx dma
channel. This causes trouble during initialization when the carrier
status has not yet been updated. If a lot of packets are received while
netif_carrier_ok returns false, all dma descriptors are freed and the
rx dma transfer is stopped.

To reproduce the bug, flood ping the davinci board while doing
ifconfig eth0 down
ifconfig eth0 up
on the board.

After that, the rx path stops working and the overrun value reported
by ifconfig is counting up.

This patch reverts commit 0a5f38467765ee15478db90d81e40c269c8dda20
and instead issues warnings only if cpdma_chan_submit returns -ENOMEM.

Signed-off-by: Christian Riesch <christian.riesch at omicron.at>
Cc: Hegde, Vinay <vinay.hegde at ti.com>
Cc: Cyril Chemparathy <cyril at ti.com>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
---

Hi,
This patch fixes the initialization problem that I described. However
I am not sure if it correctly fixes the problem that was addressed
by the original patch, 0a5f38467765ee15478db90d81e40c269c8dda20.
Thanks for your comments!
Regards, Christian

 drivers/net/ethernet/ti/davinci_emac.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 4fa0bcb..4b2f545 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1009,7 +1009,7 @@ static void emac_rx_handler(void *token, int len, int status)
 	int			ret;
 
 	/* free and bail if we are shutting down */
-	if (unlikely(!netif_running(ndev) || !netif_carrier_ok(ndev))) {
+	if (unlikely(!netif_running(ndev))) {
 		dev_kfree_skb_any(skb);
 		return;
 	}
@@ -1038,7 +1038,9 @@ static void emac_rx_handler(void *token, int len, int status)
 recycle:
 	ret = cpdma_chan_submit(priv->rxchan, skb, skb->data,
 			skb_tailroom(skb), GFP_KERNEL);
-	if (WARN_ON(ret < 0))
+
+	WARN_ON(ret == -ENOMEM);
+	if (unlikely(ret < 0))
 		dev_kfree_skb_any(skb);
 }
 
-- 
1.7.0.4


From prakash.pm at ti.com  Wed Feb 22 23:39:11 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 23 Feb 2012 05:39:11 +0000
Subject: [PATCH v4 2/3] arm:davinci: move emif driver to drivers/mfd
	from mach-davinci folder
In-Reply-To: <1328771908-32527-3-git-send-email-prakash.pm@ti.com>
References: <1328771908-32527-1-git-send-email-prakash.pm@ti.com>
	<1328771908-32527-3-git-send-email-prakash.pm@ti.com>
Message-ID: <A73F36158E33644199EB82C5EC81C7BC3176A846@DBDE01.ent.ti.com>

Hi,

On Thu, Feb 09, 2012 at 12:48:27, Manjunathappa, Prakash wrote:
> Move aemif kernel module from arch/arm/mach-davinci/ to multi functional
> devices frame work. "davinci_aemif" MFD driver adds "davinci_nand" and
> "physmap-flash" slave devices.
> 
> Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
> ---
> Since v3:
> No change. Resending as 3/3 in patch changed.
> Since v2:
> Modified emif MFD driver to load multiple instance of NAND/NOR devices.
> Since v1:
> Patch generated using -M option.
> 
>  arch/arm/Kconfig                                   |    1 +
>  arch/arm/mach-davinci/Makefile                     |    2 +-
>  drivers/mfd/Makefile                               |    1 +
>  .../aemif.c => drivers/mfd/davinci_aemif.c         |   75 +++++++++++++++++++-
>  include/linux/mfd/davinci_aemif.h                  |   14 ++++
>  5 files changed, 91 insertions(+), 2 deletions(-)
>  rename arch/arm/mach-davinci/aemif.c => drivers/mfd/davinci_aemif.c (66%)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index a48aecc..09dcb94 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -934,6 +934,7 @@ config ARCH_DAVINCI
>  	select GENERIC_ALLOCATOR
>  	select GENERIC_IRQ_CHIP
>  	select ARCH_HAS_HOLES_MEMORYMODEL
> +	select MFD_CORE
>  	help
>  	  Support for TI's DaVinci platform.
>  
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index 2db78bd..8bab47c 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -5,7 +5,7 @@
>  
>  # Common objects
>  obj-y 			:= time.o clock.o serial.o psc.o \
> -			   dma.o usb.o common.o sram.o aemif.o
> +			   dma.o usb.o common.o sram.o
>  
>  obj-$(CONFIG_DAVINCI_MUX)		+= mux.o
>  
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index b953bab..54fc267 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_HTC_EGPIO)		+= htc-egpio.o
>  obj-$(CONFIG_HTC_PASIC3)	+= htc-pasic3.o
>  obj-$(CONFIG_HTC_I2CPLD)	+= htc-i2cpld.o
>  
> +obj-${CONFIG_ARCH_DAVINCI}	+= davinci_aemif.o
>  obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)	+= davinci_voicecodec.o
>  obj-$(CONFIG_MFD_DM355EVM_MSP)	+= dm355evm_msp.o
>  obj-$(CONFIG_MFD_TI_SSP)	+= ti-ssp.o
> diff --git a/arch/arm/mach-davinci/aemif.c b/drivers/mfd/davinci_aemif.c
> similarity index 66%
> rename from arch/arm/mach-davinci/aemif.c
> rename to drivers/mfd/davinci_aemif.c
> index b67c115..5fb490d 100644
> --- a/arch/arm/mach-davinci/aemif.c
> +++ b/drivers/mfd/davinci_aemif.c
> @@ -14,8 +14,13 @@
>  #include <linux/clk.h>
>  #include <linux/module.h>
>  #include <linux/time.h>
> -
>  #include <linux/mfd/davinci_aemif.h>
> +#include <linux/mtd/physmap.h>
> +#include <linux/slab.h>
> +#include <mach/nand.h>
> +
> +static char *name[] = {"davinci_nand", "physmap-flash",};
> +#define MAX ARRAY_SIZE(name)
>  
>  /* Timing value configuration */
>  
> @@ -131,3 +136,71 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
>  	return 0;
>  }
>  EXPORT_SYMBOL(davinci_aemif_setup_timing);
> +
> +static int __init davinci_aemif_probe(struct platform_device *pdev)
> +{
> +	struct davinci_aemif_devices *davinci_aemif_devices =
> +		pdev->dev.platform_data;
> +	struct platform_device *devices;
> +	struct mfd_cell *cells;
> +	int ret, i, j, count;
> +
> +	devices = davinci_aemif_devices->devices;
> +
> +	cells = kzalloc(sizeof(struct mfd_cell) *
> +			davinci_aemif_devices->num_devices, GFP_KERNEL);
> +
> +	for (j = 0, count = 0; j < MAX; j++) {
> +		for (i = 0; i < davinci_aemif_devices->num_devices; i++) {
> +			if (strcmp(devices[i].name, name[j]))
> +				continue;
> +			cells[count].name = name[j];
> +			cells[count].platform_data =
> +				devices[i].dev.platform_data;
> +			cells[count].pdata_size =
> +				sizeof(struct davinci_nand_pdata);

Doesnot take care of updating nor platform data size, I will fix this send out next version.

Thanks,
Prakash

> +			cells[count].id = devices[i].id;
> +			cells[count].resources = devices[i].resource;
> +			cells[count].num_resources = devices[i].num_resources;
> +			count++;
> +		}
> +	}
> +
> +	ret = mfd_add_devices(&pdev->dev, 0, cells,
> +			      count, NULL, 0);
> +	if (ret != 0)
> +		dev_err(&pdev->dev, "fail to register client devices\n");
> +
> +	return 0;
> +}
> +
> +static int __devexit davinci_aemif_remove(struct platform_device *pdev)
> +{
> +	mfd_remove_devices(&pdev->dev);
> +	return 0;
> +}
> +
> +static struct platform_driver davinci_aemif_driver = {
> +	.driver	= {
> +		.name = "davinci_aemif",
> +		.owner = THIS_MODULE,
> +	},
> +	.remove	= __devexit_p(davinci_aemif_remove),
> +};
> +
> +static int __init davinci_aemif_init(void)
> +{
> +	return platform_driver_probe(&davinci_aemif_driver,
> +			davinci_aemif_probe);
> +}
> +module_init(davinci_aemif_init);
> +
> +static void __exit davinci_aemif_exit(void)
> +{
> +	platform_driver_unregister(&davinci_aemif_driver);
> +}
> +module_exit(davinci_aemif_exit);
> +
> +MODULE_AUTHOR("Prakash Manjunathappa");
> +MODULE_DESCRIPTION("Texas Instruments AEMIF Interface");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/davinci_aemif.h b/include/linux/mfd/davinci_aemif.h
> index 05b2934..18650c3 100644
> --- a/include/linux/mfd/davinci_aemif.h
> +++ b/include/linux/mfd/davinci_aemif.h
> @@ -10,6 +10,10 @@
>  #ifndef _MACH_DAVINCI_AEMIF_H
>  #define _MACH_DAVINCI_AEMIF_H
>  
> +#include <linux/kernel.h>
> +#include <linux/platform_device.h>
> +#include <linux/mfd/core.h>
> +
>  #define NRCSR_OFFSET		0x00
>  #define AWCCR_OFFSET		0x04
>  #define A1CR_OFFSET		0x10
> @@ -18,6 +22,16 @@
>  #define ACR_EW_MASK		BIT(30)
>  #define ACR_SS_MASK		BIT(31)
>  
> +enum davinci_emif_cells {
> +	DAVINCI_NAND_DEVICE_CELL,
> +	DAVINCI_NOR_FLASH_CELL,
> +};
> +
> +struct davinci_aemif_devices {
> +	struct platform_device *devices;
> +	unsigned int num_devices;
> +};
> +
>  /* All timings in nanoseconds */
>  struct davinci_aemif_timing {
>  	u8	wsetup;
> -- 
> 1.7.1
> 
> 


From christian.riesch at omicron.at  Thu Feb 23 01:58:00 2012
From: christian.riesch at omicron.at (Christian Riesch)
Date: Thu, 23 Feb 2012 08:58:00 +0100
Subject: [PATCH] davinci_cpdma: Fix channel number written to teardown
	registers
Message-ID: <1329983880-23921-1-git-send-email-christian.riesch@omicron.at>

chan->chan_num is 0..CPDMA_MAX_CHANNELS-1 for tx channels and
CPDMA_MAX_CHANNELS..2*CPDMA_MAX_CHANNELS-1 for rx channels. However,
the rx and tx teardown registers expect zero based channel numbering.

Since the upper bits of the registers are reserved, the teardown also
worked before, this patch is cleanup only.

Signed-off-by: Christian Riesch <christian.riesch at omicron.at>
---
 drivers/net/ethernet/ti/davinci_cpdma.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index c97d2f5..3455876 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -822,7 +822,7 @@ int cpdma_chan_stop(struct cpdma_chan *chan)
 	dma_reg_write(ctlr, chan->int_clear, chan->mask);
 
 	/* trigger teardown */
-	dma_reg_write(ctlr, chan->td, chan->chan_num);
+	dma_reg_write(ctlr, chan->td, chan_linear(chan));
 
 	/* wait for teardown complete */
 	timeout = jiffies + HZ/10;	/* 100 msec */
-- 
1.7.0.4


From christian.riesch at omicron.at  Thu Feb 23 02:07:58 2012
From: christian.riesch at omicron.at (Christian Riesch)
Date: Thu, 23 Feb 2012 09:07:58 +0100
Subject: [PATCH] davinci_mdio: Correct bitmask for clock divider value
Message-ID: <1329984478-24090-1-git-send-email-christian.riesch@omicron.at>

The CLKDIV bitfield in the MDIO Control Register is a 16 bit field,
therefore the CLKDIV value may range from 0 to 0xffff.

Signed-off-by: Christian Riesch <christian.riesch at omicron.at>
---
 drivers/net/ethernet/ti/davinci_mdio.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index af8b8fc..2757c7d 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -53,7 +53,7 @@ struct davinci_mdio_regs {
 	u32	control;
 #define CONTROL_IDLE		BIT(31)
 #define CONTROL_ENABLE		BIT(30)
-#define CONTROL_MAX_DIV		(0xff)
+#define CONTROL_MAX_DIV		(0xffff)
 
 	u32	alive;
 	u32	link;
-- 
1.7.0.4


From christian.riesch at omicron.at  Thu Feb 23 03:09:49 2012
From: christian.riesch at omicron.at (Christian Riesch)
Date: Thu, 23 Feb 2012 10:09:49 +0100
Subject: davinci_emac/mdio: SOFT_RESET of EMAC module resets MDIO on AM1808
Message-ID: <CABkLObpZ52yVnq-wqnm8nC=bSnzz41RnC=wbQD3U7NRmr2SRBQ@mail.gmail.com>

Hi,
I observed this behavior on a Texas Instruments AM1808 SoC (AM1808
experimenter's kit) running the current mainline kernel:

# ifconfig eth0 down
# ifconfig eth0 up
davinci_mdio davinci_mdio.0: resetting idled controller
net eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=davinci_mdio-0:00)
# PHY: davinci_mdio-0:00 - Link is Up - 100/Full

After each ifconfig eth0 up I get this 'resetting idled controller'
warning. I added a few debug messages to the davinci_mdio driver and
noticed that the MDIO control register was set to its reset value
(clock divider 0xff and MDIO turned off) after an ifconfig eth0 up.
Therefore, this warning is issued and a reconfiguration of the MDIO
controller is done by the driver.

Now the question was: Who is turning off the MDIO controller? After a
bit of debugging I found out that the reset of the MDIO controller
seems to be caused by these lines in the davinci_emac driver in
emac_hw_enable() in drivers/net/ethernet/ti/davinci_emac.c:

emac_write(EMAC_SOFTRESET, 1);
while (emac_read(EMAC_SOFTRESET))
        cpu_relax();

According to the AM1808 Technical Reference Manual (sections 18.2.14.1
and 18.3.3.34 in [1]), writing a 1 to the EMAC_SOFTRESET register
resets the EMAC module, but not the MDIO module. However, when I
comment out the code above, the MDIO control register is not affected
and the warning 'resetting idled controller' disappears.

Is this an error in the documentation? Or in hardware? Or did I miss
something here? I already asked this questions in TI's E2E forum [2]
but did not get an answer yet. I would like to ask all the TI people
out there to help me getting an answer to this question. Thanks you!

Anyway, I think this should be fixed since it's bad when a driver
(davinci_emac) resets another driver's (davinci_mdio's) hardware.

Best regards,
Christian

[1] http://www.ti.com/litv/pdf/spruh82a
[2] http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/164314.aspx

From manjunath.hadli at ti.com  Thu Feb 23 03:47:44 2012
From: manjunath.hadli at ti.com (Manjunath Hadli)
Date: Thu, 23 Feb 2012 15:17:44 +0530
Subject: [PATCH v8 0/2] ARM: davinci: add support for dm644x vpbe display
	driver
Message-ID: <1329990466-6457-1-git-send-email-manjunath.hadli@ti.com>

Re-arrange definitions and remove unnecessary code so that we can
have a common header for all davinci platforms. This will enable
us to share defines and enable common routines to be used without
polluting hardware.h.

This is consistent with Russel's pet peaves notes regarding
non-pollution of include/mach.

Having this as the base, have a common system module
base address (DAVINCI_SYSTEM_MODULE_BASE) and removing IO_ADDRESS
macro,add support for dm644x VPBE display driver.

Changes from last version:
1. Patches 3, 4, 5 and 6 from last set pulled by Sekhar.
2. Added macro for register offset and bit masks appropriately
   wherever required as suggested by Sekhar.

Manjunath Hadli (2):
  ARM: davinci: dm644x: add support for v4l2 video display
  ARM: davinci: dm644x evm: add support for VPBE display

 arch/arm/mach-davinci/board-dm644x-evm.c |  108 +++++++++++++++++++-
 arch/arm/mach-davinci/davinci.h          |    8 ++-
 arch/arm/mach-davinci/dm644x.c           |  166 +++++++++++++++++++++++++++---
 3 files changed, 267 insertions(+), 15 deletions(-)

-- 
1.7.4.1


From manjunath.hadli at ti.com  Thu Feb 23 03:47:46 2012
From: manjunath.hadli at ti.com (Manjunath Hadli)
Date: Thu, 23 Feb 2012 15:17:46 +0530
Subject: [PATCH v8 2/2] ARM: davinci: dm644x evm: add support for VPBE display
In-Reply-To: <1329990466-6457-1-git-send-email-manjunath.hadli@ti.com>
References: <1329990466-6457-1-git-send-email-manjunath.hadli@ti.com>
Message-ID: <1329990466-6457-3-git-send-email-manjunath.hadli@ti.com>

This patch adds support for V4L2 video display to DM6446 EVM.
Support for SD and ED modes is provided, along with Composite
and Component outputs. Also added vpbe_config as a parameter for
dm644x_init_video to allow for registration of vpbe platform devices.

Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>
Acked-by: Sekhar Nori <nsekhar at ti.com>
---
 arch/arm/mach-davinci/board-dm644x-evm.c |  108 +++++++++++++++++++++++++++++-
 1 files changed, 107 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index a61aa8d..b600243 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -613,6 +613,112 @@ static void __init evm_init_i2c(void)
 	i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
 }
 
+#define VENC_STD_ALL	(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* venc standard timings */
+static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[] = {
+	{
+		.name		= "ntsc",
+		.timings_type	= VPBE_ENC_STD,
+		.timings	= {V4L2_STD_525_60},
+		.interlaced	= 1,
+		.xres		= 720,
+		.yres		= 480,
+		.aspect		= {11, 10},
+		.fps		= {30000, 1001},
+		.left_margin	= 0x79,
+		.upper_margin	= 0x10,
+	},
+	{
+		.name		= "pal",
+		.timings_type	= VPBE_ENC_STD,
+		.timings	= {V4L2_STD_625_50},
+		.interlaced	= 1,
+		.xres		= 720,
+		.yres		= 576,
+		.aspect		= {54, 59},
+		.fps		= {25, 1},
+		.left_margin	= 0x7e,
+		.upper_margin	= 0x16,
+	},
+};
+
+/* venc dv preset timings */
+static struct vpbe_enc_mode_info dm644xevm_enc_preset_timing[] = {
+	{
+		.name		= "480p59_94",
+		.timings_type	= VPBE_ENC_DV_PRESET,
+		.timings	= {V4L2_DV_480P59_94},
+		.interlaced	= 0,
+		.xres		= 720,
+		.yres		= 480,
+		.aspect		= {1, 1},
+		.fps		= {5994, 100},
+		.left_margin	= 0x80,
+		.upper_margin	= 0x20,
+	},
+	{
+		.name		= "576p50",
+		.timings_type	= VPBE_ENC_DV_PRESET,
+		.timings	= {V4L2_DV_576P50},
+		.interlaced	= 0,
+		.xres		= 720,
+		.yres		= 576,
+		.aspect		= {1, 1},
+		.fps		= {50, 1},
+		.left_margin	= 0x7e,
+		.upper_margin	= 0x30,
+	},
+};
+
+/*
+ * The outputs available from VPBE + encoders. Keep the order same
+ * as that of encoders. First those from venc followed by that from
+ * encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm644xevm_vpbe_outputs[] = {
+	{
+		.output		= {
+			.index		= 0,
+			.name		= "Composite",
+			.type		= V4L2_OUTPUT_TYPE_ANALOG,
+			.std		= VENC_STD_ALL,
+			.capabilities	= V4L2_OUT_CAP_STD,
+		},
+		.subdev_name	= VPBE_VENC_SUBDEV_NAME,
+		.default_mode	= "ntsc",
+		.num_modes	= ARRAY_SIZE(dm644xevm_enc_std_timing),
+		.modes		= dm644xevm_enc_std_timing,
+	},
+	{
+		.output		= {
+			.index		= 1,
+			.name		= "Component",
+			.type		= V4L2_OUTPUT_TYPE_ANALOG,
+			.capabilities	= V4L2_OUT_CAP_PRESETS,
+		},
+		.subdev_name	= VPBE_VENC_SUBDEV_NAME,
+		.default_mode	= "480p59_94",
+		.num_modes	= ARRAY_SIZE(dm644xevm_enc_preset_timing),
+		.modes		= dm644xevm_enc_preset_timing,
+	},
+};
+
+static struct vpbe_config dm644xevm_display_cfg = {
+	.module_name	= "dm644x-vpbe-display",
+	.i2c_adapter_id	= 1,
+	.osd		= {
+		.module_name	= VPBE_OSD_SUBDEV_NAME,
+	},
+	.venc		= {
+		.module_name	= VPBE_VENC_SUBDEV_NAME,
+	},
+	.num_outputs	= ARRAY_SIZE(dm644xevm_vpbe_outputs),
+	.outputs	= dm644xevm_vpbe_outputs,
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
 	&davinci_fb_device,
 	&rtc_dev,
@@ -696,7 +802,7 @@ static __init void davinci_evm_init(void)
 	evm_init_i2c();
 
 	davinci_setup_mmc(0, &dm6446evm_mmc_config);
-	dm644x_init_video(&dm644xevm_capture_cfg, NULL);
+	dm644x_init_video(&dm644xevm_capture_cfg, &dm644xevm_display_cfg);
 
 	davinci_serial_init(&uart_config);
 	dm644x_init_asp(&dm644x_evm_snd_data);
-- 
1.7.4.1


From manjunath.hadli at ti.com  Thu Feb 23 03:47:45 2012
From: manjunath.hadli at ti.com (Manjunath Hadli)
Date: Thu, 23 Feb 2012 15:17:45 +0530
Subject: [PATCH v8 1/2] ARM: davinci: dm644x: add support for v4l2 video
	display
In-Reply-To: <1329990466-6457-1-git-send-email-manjunath.hadli@ti.com>
References: <1329990466-6457-1-git-send-email-manjunath.hadli@ti.com>
Message-ID: <1329990466-6457-2-git-send-email-manjunath.hadli@ti.com>

Create platform devices for various video modules like venc, osd,
vpbe and v4l2 driver for dm644x. Change the dm644x_init_video to
make room for display config, and register the vpfe or vpbe devices
based on the config pointer validity to make sure boards without vpfe
or vpbe can be built with minimal changes.

Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>
---
 arch/arm/mach-davinci/board-dm644x-evm.c |    2 +-
 arch/arm/mach-davinci/davinci.h          |    8 ++-
 arch/arm/mach-davinci/dm644x.c           |  166 +++++++++++++++++++++++++++---
 3 files changed, 161 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index b89bebe..a61aa8d 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -696,7 +696,7 @@ static __init void davinci_evm_init(void)
 	evm_init_i2c();
 
 	davinci_setup_mmc(0, &dm6446evm_mmc_config);
-	dm644x_init_video(&dm644xevm_capture_cfg);
+	dm644x_init_video(&dm644xevm_capture_cfg, NULL);
 
 	davinci_serial_init(&uart_config);
 	dm644x_init_asp(&dm644x_evm_snd_data);
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 9d70803..3e519da 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -29,9 +29,15 @@
 
 #include <media/davinci/vpfe_capture.h>
 #include <media/davinci/vpif_types.h>
+#include <media/davinci/vpss.h>
+#include <media/davinci/vpbe_types.h>
+#include <media/davinci/vpbe_venc.h>
+#include <media/davinci/vpbe.h>
+#include <media/davinci/vpbe_osd.h>
 
 #define DAVINCI_SYSTEM_MODULE_BASE	0x01c40000
 #define SYSMOD_VIDCLKCTL		0x38
+#define SYSMOD_VPSS_CLKCTL		0x44
 #define SYSMOD_VDD3P3VPWDN		0x48
 #define SYSMOD_VSCLKDIS			0x6c
 #define SYSMOD_PUPDCTL1			0x7c
@@ -83,7 +89,7 @@ void dm365_set_vpfe_config(struct vpfe_config *cfg);
 /* DM644x function declarations */
 void __init dm644x_init(void);
 void __init dm644x_init_asp(struct snd_platform_data *pdata);
-int __init dm644x_init_video(struct vpfe_config *);
+int __init dm644x_init_video(struct vpfe_config *, struct vpbe_config *);
 
 /* DM646x function declarations */
 void __init dm646x_init(void);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 23e81ca..5042a93 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -627,7 +627,7 @@ static struct resource dm644x_vpfe_resources[] = {
 	},
 };
 
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static u64 dm644x_video_dma_mask = DMA_BIT_MASK(32);
 static struct resource dm644x_ccdc_resource[] = {
 	/* CCDC Base address */
 	{
@@ -643,7 +643,7 @@ static struct platform_device dm644x_ccdc_dev = {
 	.num_resources  = ARRAY_SIZE(dm644x_ccdc_resource),
 	.resource       = dm644x_ccdc_resource,
 	.dev = {
-		.dma_mask               = &vpfe_capture_dma_mask,
+		.dma_mask               = &dm644x_video_dma_mask,
 		.coherent_dma_mask      = DMA_BIT_MASK(32),
 	},
 };
@@ -654,7 +654,134 @@ static struct platform_device dm644x_vpfe_dev = {
 	.num_resources	= ARRAY_SIZE(dm644x_vpfe_resources),
 	.resource	= dm644x_vpfe_resources,
 	.dev = {
-		.dma_mask		= &vpfe_capture_dma_mask,
+		.dma_mask		= &dm644x_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+#define DM644X_OSD_BASE		0x01c72600
+
+static struct resource dm644x_osd_resources[] = {
+	{
+		.start	= DM644X_OSD_BASE,
+		.end	= DM644X_OSD_BASE + 0x1ff,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct osd_platform_data dm644x_osd_data = {
+	.vpbe_type     = VPBE_VERSION_1,
+};
+
+static struct platform_device dm644x_osd_dev = {
+	.name		= VPBE_OSD_SUBDEV_NAME,
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm644x_osd_resources),
+	.resource	= dm644x_osd_resources,
+	.dev		= {
+		.dma_mask		= &dm644x_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+		.platform_data		= &dm644x_osd_data,
+	},
+};
+
+#define DM644X_VENC_BASE		0x01c72400
+
+static struct resource dm644x_venc_resources[] = {
+	{
+		.start	= DM644X_VENC_BASE,
+		.end	= DM644X_VENC_BASE + 0x17f,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+#define DM644X_VPSS_MUXSEL_PLL2_MODE          BIT(0)
+#define DM644X_VPSS_MUXSEL_VPBECLK_MODE       BIT(1)
+#define DM644X_VPSS_VENCLKEN                  BIT(3)
+#define DM644X_VPSS_DACCLKEN                  BIT(4)
+
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type,
+				   unsigned int mode)
+{
+	int ret = 0;
+	u32 v = DM644X_VPSS_VENCLKEN;
+
+	switch (type) {
+	case VPBE_ENC_STD:
+		v |= DM644X_VPSS_DACCLKEN;
+		writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
+		break;
+	case VPBE_ENC_DV_PRESET:
+		switch (mode) {
+		case V4L2_DV_480P59_94:
+		case V4L2_DV_576P50:
+			v |= DM644X_VPSS_MUXSEL_PLL2_MODE |
+				DM644X_VPSS_DACCLKEN;
+			writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
+			break;
+		case V4L2_DV_720P60:
+		case V4L2_DV_1080I60:
+		case V4L2_DV_1080P30:
+			/*
+			 * For HD, use external clock source since
+			 * HD requires higher clock rate
+			 */
+			v |= DM644X_VPSS_MUXSEL_VPBECLK_MODE;
+			writel(v, DAVINCI_SYSMOD_VIRT(SYSMOD_VPSS_CLKCTL));
+			break;
+		default:
+			ret = -EINVAL;
+			break;
+		}
+		break;
+	default:
+		ret  = -EINVAL;
+	}
+
+	return ret;
+}
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+	{
+		.start	= IRQ_VENCINT,
+		.end	= IRQ_VENCINT,
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device dm644x_vpbe_display = {
+	.name		= "vpbe-v4l2",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm644x_v4l2_disp_resources),
+	.resource	= dm644x_v4l2_disp_resources,
+	.dev		= {
+		.dma_mask		= &dm644x_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+	},
+};
+
+static struct venc_platform_data dm644x_venc_pdata = {
+	.venc_type	= VPBE_VERSION_1,
+	.setup_clock	= dm644x_venc_setup_clock,
+};
+
+static struct platform_device dm644x_venc_dev = {
+	.name		= VPBE_VENC_SUBDEV_NAME,
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(dm644x_venc_resources),
+	.resource	= dm644x_venc_resources,
+	.dev		= {
+		.dma_mask		= &dm644x_video_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+		.platform_data		= &dm644x_venc_pdata,
+	},
+};
+
+static struct platform_device dm644x_vpbe_dev = {
+	.name		= "vpbe_controller",
+	.id		= -1,
+	.dev		= {
+		.dma_mask		= &dm644x_video_dma_mask,
 		.coherent_dma_mask	= DMA_BIT_MASK(32),
 	},
 };
@@ -786,17 +913,30 @@ void __init dm644x_init(void)
 	davinci_map_sysmod();
 }
 
-int __init dm644x_init_video(struct vpfe_config *vpfe_cfg)
+int __init dm644x_init_video(struct vpfe_config *vpfe_cfg,
+				struct vpbe_config *vpbe_cfg)
 {
-	dm644x_vpfe_dev.dev.platform_data = vpfe_cfg;
-
-	/* Add ccdc clock aliases */
-	clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL);
-	clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL);
-
-	platform_device_register(&dm644x_vpss_device);
-	platform_device_register(&dm644x_ccdc_dev);
-	platform_device_register(&dm644x_vpfe_dev);
+	if (vpfe_cfg || vpbe_cfg)
+		platform_device_register(&dm644x_vpss_device);
+
+	if (vpfe_cfg) {
+		dm644x_vpfe_dev.dev.platform_data = vpfe_cfg;
+		platform_device_register(&dm644x_ccdc_dev);
+		platform_device_register(&dm644x_vpfe_dev);
+		/* Add ccdc clock aliases */
+		clk_add_alias("master", dm644x_ccdc_dev.name,
+			      "vpss_master", NULL);
+		clk_add_alias("slave", dm644x_ccdc_dev.name,
+			      "vpss_slave", NULL);
+	}
+
+	if (vpbe_cfg) {
+		dm644x_vpbe_dev.dev.platform_data = vpbe_cfg;
+		platform_device_register(&dm644x_osd_dev);
+		platform_device_register(&dm644x_venc_dev);
+		platform_device_register(&dm644x_vpbe_dev);
+		platform_device_register(&dm644x_vpbe_display);
+	}
 
 	return 0;
 }
-- 
1.7.4.1


From christian.riesch at omicron.at  Thu Feb 23 05:14:17 2012
From: christian.riesch at omicron.at (Christian Riesch)
Date: Thu, 23 Feb 2012 12:14:17 +0100
Subject: [PATCH v2] davinci_emac: Do not free all rx dma descriptors during
	init
Message-ID: <1329995657-7051-1-git-send-email-christian.riesch@omicron.at>

This patch fixes a regression that was introduced by

commit 0a5f38467765ee15478db90d81e40c269c8dda20
davinci_emac: Add Carrier Link OK check in Davinci RX Handler

Said commit adds a check whether the carrier link is ok. If the link is
not ok, the skb is freed and no new dma descriptor added to the rx dma
channel. This causes trouble during initialization when the carrier
status has not yet been updated. If a lot of packets are received while
netif_carrier_ok returns false, all dma descriptors are freed and the
rx dma transfer is stopped.

The bug occurs when the board is connected to a network with lots of
traffic and the ifconfig down/up is done, e.g., when reconfiguring
the interface with DHCP.

The bug can be reproduced by flood pinging the davinci board while doing
ifconfig eth0 down
ifconfig eth0 up
on the board.

After that, the rx path stops working and the overrun value reported
by ifconfig is counting up.

This patch reverts commit 0a5f38467765ee15478db90d81e40c269c8dda20
and instead issues warnings only if cpdma_chan_submit returns -ENOMEM.

Signed-off-by: Christian Riesch <christian.riesch at omicron.at>
Cc: <stable at vger.kernel.org>
Cc: Hegde, Vinay <vinay.hegde at ti.com>
Cc: Cyril Chemparathy <cyril at ti.com>
Cc: Sascha Hauer <s.hauer at pengutronix.de>
---

Hi,
Since my first submission of this patch yesterday I did additional tests
with suspend/rtcwake. My tests confirmed that the solution in this
patch solves the problem that was addressed by commit
0a5f38467765ee15478db90d81e40c269c8dda20 while not destroying the
rx communication channel. 

Changes since v1:
- Removed the 'RFC' from subject line
- Added more information to the commit message
- Added stable tag, I think this patch meets the rules in
  Documentation/stable_kernel_rules.txt

Regards, Christian

 drivers/net/ethernet/ti/davinci_emac.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 4fa0bcb..4b2f545 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1009,7 +1009,7 @@ static void emac_rx_handler(void *token, int len, int status)
 	int			ret;
 
 	/* free and bail if we are shutting down */
-	if (unlikely(!netif_running(ndev) || !netif_carrier_ok(ndev))) {
+	if (unlikely(!netif_running(ndev))) {
 		dev_kfree_skb_any(skb);
 		return;
 	}
@@ -1038,7 +1038,9 @@ static void emac_rx_handler(void *token, int len, int status)
 recycle:
 	ret = cpdma_chan_submit(priv->rxchan, skb, skb->data,
 			skb_tailroom(skb), GFP_KERNEL);
-	if (WARN_ON(ret < 0))
+
+	WARN_ON(ret == -ENOMEM);
+	if (unlikely(ret < 0))
 		dev_kfree_skb_any(skb);
 }
 
-- 
1.7.0.4


From sudhakar.raj at ti.com  Thu Feb 23 06:39:10 2012
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Thu, 23 Feb 2012 12:39:10 +0000
Subject: [PATCH v2] davinci_emac: Do not free all rx dma descriptors
	during	init
In-Reply-To: <1329995657-7051-1-git-send-email-christian.riesch@omicron.at>
References: <1329995657-7051-1-git-send-email-christian.riesch@omicron.at>
Message-ID: <B6A220404B6BFC4BBD2AB91C54D39DF431775769@DBDE01.ent.ti.com>

Hi,

On Thu, Feb 23, 2012 at 16:44:17, Christian Riesch wrote:
> This patch fixes a regression that was introduced by
> 
> commit 0a5f38467765ee15478db90d81e40c269c8dda20
> davinci_emac: Add Carrier Link OK check in Davinci RX Handler
> 
> Said commit adds a check whether the carrier link is ok. If the link is
> not ok, the skb is freed and no new dma descriptor added to the rx dma
> channel. This causes trouble during initialization when the carrier
> status has not yet been updated. If a lot of packets are received while
> netif_carrier_ok returns false, all dma descriptors are freed and the
> rx dma transfer is stopped.
> 
> The bug occurs when the board is connected to a network with lots of
> traffic and the ifconfig down/up is done, e.g., when reconfiguring
> the interface with DHCP.
> 
> The bug can be reproduced by flood pinging the davinci board while doing
> ifconfig eth0 down
> ifconfig eth0 up
> on the board.
> 
> After that, the rx path stops working and the overrun value reported
> by ifconfig is counting up.
> 
> This patch reverts commit 0a5f38467765ee15478db90d81e40c269c8dda20
> and instead issues warnings only if cpdma_chan_submit returns -ENOMEM.
> 
> Signed-off-by: Christian Riesch <christian.riesch at omicron.at>
> Cc: <stable at vger.kernel.org>
> Cc: Hegde, Vinay <vinay.hegde at ti.com>
> Cc: Cyril Chemparathy <cyril at ti.com>
> Cc: Sascha Hauer <s.hauer at pengutronix.de>
> ---
> 
> Hi,
> Since my first submission of this patch yesterday I did additional tests
> with suspend/rtcwake. My tests confirmed that the solution in this
> patch solves the problem that was addressed by commit
> 0a5f38467765ee15478db90d81e40c269c8dda20 while not destroying the
> rx communication channel. 
> 

Tested on DA850 and confirmed that there is no regression.

Tested-by: Rajashekhara, Sudhakar <sudhakar.raj at ti.com>

Regards,
Sudhakar

From prakash.pm at ti.com  Thu Feb 23 07:58:21 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 23 Feb 2012 19:28:21 +0530
Subject: [PATCH v5 0/3]Move davinci emif driver to MFD from platform code
In-Reply-To: <y>
References: <y>
Message-ID: <1330005504-25321-1-git-send-email-prakash.pm@ti.com>

Patch series are based on the discussion and concerns expressed in
davinci-linux-open-source community. Here is the link to the thread:
http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-tt7059739.html#none

Manjunathappa, Prakash (3):
  arm:davinci: prepare to move aemif driver to drivers/mfd
  arm:davinci: move emif driver to mfd framework
  arm:davinci: move NAND and NOR devices as emif MFD slaves

 arch/arm/Kconfig                                   |    1 +
 arch/arm/mach-davinci/Makefile                     |    2 +-
 arch/arm/mach-davinci/aemif.c                      |  133 -------------
 arch/arm/mach-davinci/board-da830-evm.c            |   33 +++-
 arch/arm/mach-davinci/board-da850-evm.c            |   56 +++---
 arch/arm/mach-davinci/board-dm355-evm.c            |   33 +++-
 arch/arm/mach-davinci/board-dm355-leopard.c        |   35 +++-
 arch/arm/mach-davinci/board-dm365-evm.c            |   34 +++-
 arch/arm/mach-davinci/board-dm644x-evm.c           |  175 ++++++++++-------
 arch/arm/mach-davinci/board-dm646x-evm.c           |   32 +++-
 arch/arm/mach-davinci/board-mityomapl138.c         |   34 +++-
 arch/arm/mach-davinci/board-neuros-osd2.c          |    1 +
 arch/arm/mach-davinci/board-sffsdr.c               |   34 +++-
 drivers/mfd/Makefile                               |    1 +
 drivers/mfd/davinci_aemif.c                        |  206 ++++++++++++++++++++
 drivers/mtd/nand/davinci_nand.c                    |    2 +-
 .../aemif.h => include/linux/mfd/davinci_aemif.h   |   14 ++
 17 files changed, 527 insertions(+), 299 deletions(-)
 delete mode 100644 arch/arm/mach-davinci/aemif.c
 create mode 100644 drivers/mfd/davinci_aemif.c
 rename arch/arm/mach-davinci/include/mach/aemif.h => include/linux/mfd/davinci_aemif.h (74%)


From prakash.pm at ti.com  Thu Feb 23 07:58:22 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 23 Feb 2012 19:28:22 +0530
Subject: [PATCH v5 1/3] arm:davinci: prepare to move aemif driver to
	drivers/mfd
In-Reply-To: <y>
References: <y>
Message-ID: <1330005504-25321-2-git-send-email-prakash.pm@ti.com>

Move platform specific header file to mfd specific location.
This is done as a prerequisite for moving emif handling code out
of platform folders.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v4:
No change
Since v3:
No change. Resending as 3/3 in patch changed.
Since v2:
No change.
Since v1:
Patch generated using -M option.

 arch/arm/mach-davinci/aemif.c                      |    2 +-
 arch/arm/mach-davinci/board-da830-evm.c            |    2 +-
 arch/arm/mach-davinci/board-da850-evm.c            |    2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c           |    2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c           |    2 +-
 drivers/mtd/nand/davinci_nand.c                    |    2 +-
 .../aemif.h => include/linux/mfd/davinci_aemif.h   |    0
 7 files changed, 6 insertions(+), 6 deletions(-)
 rename arch/arm/mach-davinci/include/mach/aemif.h => include/linux/mfd/davinci_aemif.h (100%)

diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
index 1ce70a9..b67c115 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/arch/arm/mach-davinci/aemif.c
@@ -15,7 +15,7 @@
 #include <linux/module.h>
 #include <linux/time.h>
 
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 /* Timing value configuration */
 
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index dc1afe5..0b43554 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -31,7 +31,7 @@
 #include <mach/nand.h>
 #include <mach/da8xx.h>
 #include <mach/usb.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 #include <mach/spi.h>
 
 #define DA830_EVM_PHY_ID		""
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index d508890..9f2a544 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -41,7 +41,7 @@
 #include <mach/da8xx.h>
 #include <mach/nand.h>
 #include <mach/mux.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 #include <mach/spi.h>
 
 #define DA850_EVM_PHY_ID		"davinci_mdio-0:00"
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 1247ecd..99a6639 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -38,7 +38,7 @@
 #include <mach/nand.h>
 #include <mach/mmc.h>
 #include <mach/usb.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #define DM644X_EVM_PHY_ID		"davinci_mdio-0:01"
 #define LXT971_PHY_ID	(0x001378e2)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 872ac69..af55a9d 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -43,7 +43,7 @@
 #include <mach/nand.h>
 #include <mach/clock.h>
 #include <mach/cdce949.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include "clock.h"
 
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 6e56615..f19151b 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -35,7 +35,7 @@
 #include <linux/slab.h>
 
 #include <mach/nand.h>
-#include <mach/aemif.h>
+#include <linux/mfd/davinci_aemif.h>
 
 /*
  * This is a device driver for the NAND flash controller found on the
diff --git a/arch/arm/mach-davinci/include/mach/aemif.h b/include/linux/mfd/davinci_aemif.h
similarity index 100%
rename from arch/arm/mach-davinci/include/mach/aemif.h
rename to include/linux/mfd/davinci_aemif.h
-- 
1.7.1


From prakash.pm at ti.com  Thu Feb 23 07:58:23 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 23 Feb 2012 19:28:23 +0530
Subject: [PATCH v5 2/3] arm:davinci: move emif driver to mfd framework
In-Reply-To: <y>
References: <y>
Message-ID: <1330005504-25321-3-git-send-email-prakash.pm@ti.com>

Move emif handling code from platform folder to multi functional
devices frame work. emif MFD driver adds "davinci_nand" and
"physmap-flash" as slave devices.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v4:
Fix updating NAND/NOR platfrom data.
Since v3:
No change. Resending as 3/3 in patch changed.
Since v2:
Modified emif MFD driver to load multiple instance of NAND/NOR devices.
Since v1:
Patch generated using -M option.
 arch/arm/Kconfig                  |    1 +
 arch/arm/mach-davinci/Makefile    |    2 +-
 arch/arm/mach-davinci/aemif.c     |  133 ------------------------
 drivers/mfd/Makefile              |    1 +
 drivers/mfd/davinci_aemif.c       |  206 +++++++++++++++++++++++++++++++++++++
 include/linux/mfd/davinci_aemif.h |   14 +++
 6 files changed, 223 insertions(+), 134 deletions(-)
 delete mode 100644 arch/arm/mach-davinci/aemif.c
 create mode 100644 drivers/mfd/davinci_aemif.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a48aecc..09dcb94 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -934,6 +934,7 @@ config ARCH_DAVINCI
 	select GENERIC_ALLOCATOR
 	select GENERIC_IRQ_CHIP
 	select ARCH_HAS_HOLES_MEMORYMODEL
+	select MFD_CORE
 	help
 	  Support for TI's DaVinci platform.
 
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 2db78bd..8bab47c 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
 
 # Common objects
 obj-y 			:= time.o clock.o serial.o psc.o \
-			   dma.o usb.o common.o sram.o aemif.o
+			   dma.o usb.o common.o sram.o
 
 obj-$(CONFIG_DAVINCI_MUX)		+= mux.o
 
diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
deleted file mode 100644
index b67c115..0000000
--- a/arch/arm/mach-davinci/aemif.c
+++ /dev/null
@@ -1,133 +0,0 @@
-/*
- * AEMIF support for DaVinci SoCs
- *
- * Copyright (C) 2010 Texas Instruments Incorporated. http://www.ti.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.
- */
-
-#include <linux/kernel.h>
-#include <linux/io.h>
-#include <linux/err.h>
-#include <linux/clk.h>
-#include <linux/module.h>
-#include <linux/time.h>
-
-#include <linux/mfd/davinci_aemif.h>
-
-/* Timing value configuration */
-
-#define TA(x)		((x) << 2)
-#define RHOLD(x)	((x) << 4)
-#define RSTROBE(x)	((x) << 7)
-#define RSETUP(x)	((x) << 13)
-#define WHOLD(x)	((x) << 17)
-#define WSTROBE(x)	((x) << 20)
-#define WSETUP(x)	((x) << 26)
-
-#define TA_MAX		0x3
-#define RHOLD_MAX	0x7
-#define RSTROBE_MAX	0x3f
-#define RSETUP_MAX	0xf
-#define WHOLD_MAX	0x7
-#define WSTROBE_MAX	0x3f
-#define WSETUP_MAX	0xf
-
-#define TIMING_MASK	(TA(TA_MAX) | \
-				RHOLD(RHOLD_MAX) | \
-				RSTROBE(RSTROBE_MAX) |	\
-				RSETUP(RSETUP_MAX) | \
-				WHOLD(WHOLD_MAX) | \
-				WSTROBE(WSTROBE_MAX) | \
-				WSETUP(WSETUP_MAX))
-
-/*
- * aemif_calc_rate - calculate timing data.
- * @wanted: The cycle time needed in nanoseconds.
- * @clk: The input clock rate in kHz.
- * @max: The maximum divider value that can be programmed.
- *
- * On success, returns the calculated timing value minus 1 for easy
- * programming into AEMIF timing registers, else negative errno.
- */
-static int aemif_calc_rate(int wanted, unsigned long clk, int max)
-{
-	int result;
-
-	result = DIV_ROUND_UP((wanted * clk), NSEC_PER_MSEC) - 1;
-
-	pr_debug("%s: result %d from %ld, %d\n", __func__, result, clk, wanted);
-
-	/* It is generally OK to have a more relaxed timing than requested... */
-	if (result < 0)
-		result = 0;
-
-	/* ... But configuring tighter timings is not an option. */
-	else if (result > max)
-		result = -EINVAL;
-
-	return result;
-}
-
-/**
- * davinci_aemif_setup_timing - setup timing values for a given AEMIF interface
- * @t: timing values to be progammed
- * @base: The virtual base address of the AEMIF interface
- * @cs: chip-select to program the timing values for
- *
- * This function programs the given timing values (in real clock) into the
- * AEMIF registers taking the AEMIF clock into account.
- *
- * This function does not use any locking while programming the AEMIF
- * because it is expected that there is only one user of a given
- * chip-select.
- *
- * Returns 0 on success, else negative errno.
- */
-int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
-					void __iomem *base, unsigned cs)
-{
-	unsigned set, val;
-	int ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup;
-	unsigned offset = A1CR_OFFSET + cs * 4;
-	struct clk *aemif_clk;
-	unsigned long clkrate;
-
-	if (!t)
-		return 0;	/* Nothing to do */
-
-	aemif_clk = clk_get(NULL, "aemif");
-	if (IS_ERR(aemif_clk))
-		return PTR_ERR(aemif_clk);
-
-	clkrate = clk_get_rate(aemif_clk);
-
-	clkrate /= 1000;	/* turn clock into kHz for ease of use */
-
-	ta	= aemif_calc_rate(t->ta, clkrate, TA_MAX);
-	rhold	= aemif_calc_rate(t->rhold, clkrate, RHOLD_MAX);
-	rstrobe	= aemif_calc_rate(t->rstrobe, clkrate, RSTROBE_MAX);
-	rsetup	= aemif_calc_rate(t->rsetup, clkrate, RSETUP_MAX);
-	whold	= aemif_calc_rate(t->whold, clkrate, WHOLD_MAX);
-	wstrobe	= aemif_calc_rate(t->wstrobe, clkrate, WSTROBE_MAX);
-	wsetup	= aemif_calc_rate(t->wsetup, clkrate, WSETUP_MAX);
-
-	if (ta < 0 || rhold < 0 || rstrobe < 0 || rsetup < 0 ||
-			whold < 0 || wstrobe < 0 || wsetup < 0) {
-		pr_err("%s: cannot get suitable timings\n", __func__);
-		return -EINVAL;
-	}
-
-	set = TA(ta) | RHOLD(rhold) | RSTROBE(rstrobe) | RSETUP(rsetup) |
-		WHOLD(whold) | WSTROBE(wstrobe) | WSETUP(wsetup);
-
-	val = __raw_readl(base + offset);
-	val &= ~TIMING_MASK;
-	val |= set;
-	__raw_writel(val, base + offset);
-
-	return 0;
-}
-EXPORT_SYMBOL(davinci_aemif_setup_timing);
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b953bab..54fc267 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_HTC_EGPIO)		+= htc-egpio.o
 obj-$(CONFIG_HTC_PASIC3)	+= htc-pasic3.o
 obj-$(CONFIG_HTC_I2CPLD)	+= htc-i2cpld.o
 
+obj-${CONFIG_ARCH_DAVINCI}	+= davinci_aemif.o
 obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)	+= davinci_voicecodec.o
 obj-$(CONFIG_MFD_DM355EVM_MSP)	+= dm355evm_msp.o
 obj-$(CONFIG_MFD_TI_SSP)	+= ti-ssp.o
diff --git a/drivers/mfd/davinci_aemif.c b/drivers/mfd/davinci_aemif.c
new file mode 100644
index 0000000..54d3561
--- /dev/null
+++ b/drivers/mfd/davinci_aemif.c
@@ -0,0 +1,206 @@
+/*
+ * AEMIF support for DaVinci SoCs
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated. http://www.ti.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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/time.h>
+#include <linux/mfd/davinci_aemif.h>
+#include <linux/mtd/physmap.h>
+#include <linux/slab.h>
+#include <mach/nand.h>
+
+/* Timing value configuration */
+
+#define TA(x)		((x) << 2)
+#define RHOLD(x)	((x) << 4)
+#define RSTROBE(x)	((x) << 7)
+#define RSETUP(x)	((x) << 13)
+#define WHOLD(x)	((x) << 17)
+#define WSTROBE(x)	((x) << 20)
+#define WSETUP(x)	((x) << 26)
+
+#define TA_MAX		0x3
+#define RHOLD_MAX	0x7
+#define RSTROBE_MAX	0x3f
+#define RSETUP_MAX	0xf
+#define WHOLD_MAX	0x7
+#define WSTROBE_MAX	0x3f
+#define WSETUP_MAX	0xf
+
+#define TIMING_MASK	(TA(TA_MAX) | \
+				RHOLD(RHOLD_MAX) | \
+				RSTROBE(RSTROBE_MAX) |	\
+				RSETUP(RSETUP_MAX) | \
+				WHOLD(WHOLD_MAX) | \
+				WSTROBE(WSTROBE_MAX) | \
+				WSETUP(WSETUP_MAX))
+
+/*
+ * aemif_calc_rate - calculate timing data.
+ * @wanted: The cycle time needed in nanoseconds.
+ * @clk: The input clock rate in kHz.
+ * @max: The maximum divider value that can be programmed.
+ *
+ * On success, returns the calculated timing value minus 1 for easy
+ * programming into AEMIF timing registers, else negative errno.
+ */
+static int aemif_calc_rate(int wanted, unsigned long clk, int max)
+{
+	int result;
+
+	result = DIV_ROUND_UP((wanted * clk), NSEC_PER_MSEC) - 1;
+
+	pr_debug("%s: result %d from %ld, %d\n", __func__, result, clk, wanted);
+
+	/* It is generally OK to have a more relaxed timing than requested... */
+	if (result < 0)
+		result = 0;
+
+	/* ... But configuring tighter timings is not an option. */
+	else if (result > max)
+		result = -EINVAL;
+
+	return result;
+}
+
+/**
+ * davinci_aemif_setup_timing - setup timing values for a given AEMIF interface
+ * @t: timing values to be progammed
+ * @base: The virtual base address of the AEMIF interface
+ * @cs: chip-select to program the timing values for
+ *
+ * This function programs the given timing values (in real clock) into the
+ * AEMIF registers taking the AEMIF clock into account.
+ *
+ * This function does not use any locking while programming the AEMIF
+ * because it is expected that there is only one user of a given
+ * chip-select.
+ *
+ * Returns 0 on success, else negative errno.
+ */
+int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
+					void __iomem *base, unsigned cs)
+{
+	unsigned set, val;
+	int ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup;
+	unsigned offset = A1CR_OFFSET + cs * 4;
+	struct clk *aemif_clk;
+	unsigned long clkrate;
+
+	if (!t)
+		return 0;	/* Nothing to do */
+
+	aemif_clk = clk_get(NULL, "aemif");
+	if (IS_ERR(aemif_clk))
+		return PTR_ERR(aemif_clk);
+
+	clkrate = clk_get_rate(aemif_clk);
+
+	clkrate /= 1000;	/* turn clock into kHz for ease of use */
+
+	ta	= aemif_calc_rate(t->ta, clkrate, TA_MAX);
+	rhold	= aemif_calc_rate(t->rhold, clkrate, RHOLD_MAX);
+	rstrobe	= aemif_calc_rate(t->rstrobe, clkrate, RSTROBE_MAX);
+	rsetup	= aemif_calc_rate(t->rsetup, clkrate, RSETUP_MAX);
+	whold	= aemif_calc_rate(t->whold, clkrate, WHOLD_MAX);
+	wstrobe	= aemif_calc_rate(t->wstrobe, clkrate, WSTROBE_MAX);
+	wsetup	= aemif_calc_rate(t->wsetup, clkrate, WSETUP_MAX);
+
+	if (ta < 0 || rhold < 0 || rstrobe < 0 || rsetup < 0 ||
+			whold < 0 || wstrobe < 0 || wsetup < 0) {
+		pr_err("%s: cannot get suitable timings\n", __func__);
+		return -EINVAL;
+	}
+
+	set = TA(ta) | RHOLD(rhold) | RSTROBE(rstrobe) | RSETUP(rsetup) |
+		WHOLD(whold) | WSTROBE(wstrobe) | WSETUP(wsetup);
+
+	val = __raw_readl(base + offset);
+	val &= ~TIMING_MASK;
+	val |= set;
+	__raw_writel(val, base + offset);
+
+	return 0;
+}
+EXPORT_SYMBOL(davinci_aemif_setup_timing);
+
+static int __init davinci_aemif_probe(struct platform_device *pdev)
+{
+	struct davinci_aemif_devices *davinci_aemif_devices =
+		pdev->dev.platform_data;
+	struct platform_device *devices;
+	struct mfd_cell *cells;
+	int i, ret, count;
+
+	devices = davinci_aemif_devices->devices;
+
+	cells = kzalloc(sizeof(struct mfd_cell) *
+			davinci_aemif_devices->num_devices, GFP_KERNEL);
+
+	for (i = 0, count = 0; i < davinci_aemif_devices->num_devices; i++) {
+		if (!strcmp(devices[i].name, "davinci_nand")) {
+			cells[count].pdata_size =
+				sizeof(struct davinci_nand_pdata);
+		} else if (!strcmp(devices[i].name, "physmap-flash")) {
+			cells[count].pdata_size =
+				sizeof(struct physmap_flash_data);
+		} else
+			continue;
+
+		cells[count].name = devices[i].name;
+		cells[count].platform_data =
+			devices[i].dev.platform_data;
+		cells[count].id = devices[i].id;
+		cells[count].resources = devices[i].resource;
+		cells[count].num_resources = devices[i].num_resources;
+		count++;
+	}
+
+	ret = mfd_add_devices(&pdev->dev, 0, cells,
+			      count, NULL, 0);
+	if (ret != 0)
+		dev_err(&pdev->dev, "fail to register client devices\n");
+
+	return 0;
+}
+
+static int __devexit davinci_aemif_remove(struct platform_device *pdev)
+{
+	mfd_remove_devices(&pdev->dev);
+	return 0;
+}
+
+static struct platform_driver davinci_aemif_driver = {
+	.driver	= {
+		.name = "davinci_aemif",
+		.owner = THIS_MODULE,
+	},
+	.remove	= __devexit_p(davinci_aemif_remove),
+};
+
+static int __init davinci_aemif_init(void)
+{
+	return platform_driver_probe(&davinci_aemif_driver,
+			davinci_aemif_probe);
+}
+module_init(davinci_aemif_init);
+
+static void __exit davinci_aemif_exit(void)
+{
+	platform_driver_unregister(&davinci_aemif_driver);
+}
+module_exit(davinci_aemif_exit);
+
+MODULE_AUTHOR("Prakash Manjunathappa");
+MODULE_DESCRIPTION("Texas Instruments AEMIF Interface");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/davinci_aemif.h b/include/linux/mfd/davinci_aemif.h
index 05b2934..18650c3 100644
--- a/include/linux/mfd/davinci_aemif.h
+++ b/include/linux/mfd/davinci_aemif.h
@@ -10,6 +10,10 @@
 #ifndef _MACH_DAVINCI_AEMIF_H
 #define _MACH_DAVINCI_AEMIF_H
 
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/core.h>
+
 #define NRCSR_OFFSET		0x00
 #define AWCCR_OFFSET		0x04
 #define A1CR_OFFSET		0x10
@@ -18,6 +22,16 @@
 #define ACR_EW_MASK		BIT(30)
 #define ACR_SS_MASK		BIT(31)
 
+enum davinci_emif_cells {
+	DAVINCI_NAND_DEVICE_CELL,
+	DAVINCI_NOR_FLASH_CELL,
+};
+
+struct davinci_aemif_devices {
+	struct platform_device *devices;
+	unsigned int num_devices;
+};
+
 /* All timings in nanoseconds */
 struct davinci_aemif_timing {
 	u8	wsetup;
-- 
1.7.1


From prakash.pm at ti.com  Thu Feb 23 07:58:24 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Thu, 23 Feb 2012 19:28:24 +0530
Subject: [PATCH v5 3/3] arm:davinci: move NAND and NOR devices as emif MFD
	slaves
In-Reply-To: <y>
References: <y>
Message-ID: <1330005504-25321-4-git-send-email-prakash.pm@ti.com>

NAND and NOR device are made as aemif device slaves, hence all DaVinci
board NAND/NOR device registration is achieved via emif MFD driver.

Signed-off-by: Manjunathappa, Prakash <prakash.pm at ti.com>
---
Since v4:
No change.
Since v3:
Changed NAND device id to 1 for board-mityomapl138.
Since v2:
Make changes for all DaVinci boards in single patch.
Since v1:
Patch generated using -M option.

 arch/arm/mach-davinci/board-da830-evm.c     |   31 ++++--
 arch/arm/mach-davinci/board-da850-evm.c     |   54 +++++----
 arch/arm/mach-davinci/board-dm355-evm.c     |   33 ++++--
 arch/arm/mach-davinci/board-dm355-leopard.c |   35 ++++--
 arch/arm/mach-davinci/board-dm365-evm.c     |   34 ++++--
 arch/arm/mach-davinci/board-dm644x-evm.c    |  173 +++++++++++++++------------
 arch/arm/mach-davinci/board-dm646x-evm.c    |   30 ++++--
 arch/arm/mach-davinci/board-mityomapl138.c  |   34 ++++--
 arch/arm/mach-davinci/board-neuros-osd2.c   |    1 +
 arch/arm/mach-davinci/board-sffsdr.c        |   34 ++++--
 10 files changed, 299 insertions(+), 160 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 0b43554..0ad3662 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -396,14 +396,29 @@ static struct resource da830_evm_nand_resources[] = {
 	},
 };
 
-static struct platform_device da830_evm_nand_device = {
-	.name		= "davinci_nand",
-	.id		= 1,
-	.dev		= {
-		.platform_data	= &da830_evm_nand_pdata,
+static struct platform_device da830_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 1,
+		.dev		= {
+			.platform_data	= &da830_evm_nand_pdata,
+		},
+		.num_resources	= ARRAY_SIZE(da830_evm_nand_resources),
+		.resource	= da830_evm_nand_resources,
+	},
+};
+
+static struct davinci_aemif_devices da830_emif_devices = {
+	.devices	= da830_evm_devices,
+	.num_devices	= ARRAY_SIZE(da830_evm_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &da830_emif_devices,
 	},
-	.num_resources	= ARRAY_SIZE(da830_evm_nand_resources),
-	.resource	= da830_evm_nand_resources,
 };
 
 static inline void da830_evm_init_nand(int mux_mode)
@@ -422,7 +437,7 @@ static inline void da830_evm_init_nand(int mux_mode)
 		pr_warning("da830_evm_init: emif25 mux setup failed: %d\n",
 				ret);
 
-	ret = platform_device_register(&da830_evm_nand_device);
+	ret = platform_device_register(&davinci_emif_device);
 	if (ret)
 		pr_warning("da830_evm_init: NAND device not registered.\n");
 
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 9f2a544..49ab16d 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -181,16 +181,6 @@ static struct resource da850_evm_norflash_resource[] = {
 	},
 };
 
-static struct platform_device da850_evm_norflash_device = {
-	.name		= "physmap-flash",
-	.id		= 0,
-	.dev		= {
-		.platform_data  = &da850_evm_norflash_data,
-	},
-	.num_resources	= 1,
-	.resource	= da850_evm_norflash_resource,
-};
-
 static struct davinci_pm_config da850_pm_pdata = {
 	.sleepcount = 128,
 };
@@ -273,19 +263,39 @@ static struct resource da850_evm_nandflash_resource[] = {
 	},
 };
 
-static struct platform_device da850_evm_nandflash_device = {
-	.name		= "davinci_nand",
-	.id		= 1,
-	.dev		= {
-		.platform_data	= &da850_evm_nandflash_data,
+static struct platform_device da850_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 1,
+		.dev		= {
+			.platform_data	= &da850_evm_nandflash_data,
+		},
+		.num_resources	= ARRAY_SIZE(da850_evm_nandflash_resource),
+		.resource	= da850_evm_nandflash_resource,
 	},
-	.num_resources	= ARRAY_SIZE(da850_evm_nandflash_resource),
-	.resource	= da850_evm_nandflash_resource,
+	{
+		.name		= "physmap-flash",
+		.id		= 0,
+		.dev		= {
+			.platform_data  = &da850_evm_norflash_data,
+		},
+		.num_resources	= 1,
+		.resource	= da850_evm_norflash_resource,
+
+	},
+
+};
+static struct davinci_aemif_devices da850_emif_devices = {
+	.devices	= da850_evm_devices,
+	.num_devices	= ARRAY_SIZE(da850_evm_devices),
 };
 
-static struct platform_device *da850_evm_devices[] __initdata = {
-	&da850_evm_nandflash_device,
-	&da850_evm_norflash_device,
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &da850_emif_devices,
+	},
 };
 
 #define DA8XX_AEMIF_CE2CFG_OFFSET	0x10
@@ -352,9 +362,7 @@ static inline void da850_evm_setup_nor_nand(void)
 				ret);
 
 		da850_evm_init_nor();
-
-		platform_add_devices(da850_evm_devices,
-					ARRAY_SIZE(da850_evm_devices));
+		platform_device_register(&davinci_emif_device);
 	}
 }
 
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 275341f..e7359e8 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -22,6 +22,7 @@
 #include <media/tvp514x.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -93,15 +94,16 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
-
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
+static struct platform_device dm355_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
 
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
 	},
 };
 
@@ -241,9 +243,22 @@ static struct vpfe_config vpfe_cfg = {
 	.ccdc = "DM355 CCDC",
 };
 
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm355_evm_devices,
+	.num_devices	= ARRAY_SIZE(dm355_evm_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
 	&dm355evm_dm9000,
-	&davinci_nand_device,
+	&davinci_emif_device,
 };
 
 static struct davinci_uart_config uart_config __initdata = {
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c
index e99db28..ec057b6 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -19,6 +19,7 @@
 #include <linux/clk.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -89,15 +90,16 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
-
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
-
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+static struct platform_device dm355_evm_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
 	},
 };
 
@@ -166,9 +168,22 @@ static struct platform_device dm355leopard_dm9000 = {
 	.num_resources	= ARRAY_SIZE(dm355leopard_dm9000_rsrc),
 };
 
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm355_evm_devices,
+	.num_devices	= ARRAY_SIZE(dm355_evm_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
+};
+
 static struct platform_device *davinci_leopard_devices[] __initdata = {
 	&dm355leopard_dm9000,
-	&davinci_nand_device,
+	&davinci_emif_device,
 };
 
 static struct davinci_uart_config uart_config __initdata = {
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 849311d..f97d67d 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -27,6 +27,7 @@
 #include <linux/input.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/eeprom.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -155,13 +156,16 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+static struct platform_device dm365_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
 	},
 };
 
@@ -379,8 +383,17 @@ static void __init evm_init_i2c(void)
 	i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
 }
 
-static struct platform_device *dm365_evm_nand_devices[] __initdata = {
-	&davinci_nand_device,
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm365_emif_devices,
+	.num_devices	= ARRAY_SIZE(dm365_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
 };
 
 static inline int have_leds(void)
@@ -502,8 +515,7 @@ fail:
 		/* external keypad mux */
 		mux |= BIT(7);
 
-		platform_add_devices(dm365_evm_nand_devices,
-				ARRAY_SIZE(dm365_evm_nand_devices));
+		platform_device_register(&davinci_emif_device);
 	} else {
 		/* no OneNAND support yet */
 	}
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 99a6639..ad4c944 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -44,61 +44,21 @@
 #define LXT971_PHY_ID	(0x001378e2)
 #define LXT971_PHY_MASK	(0xfffffff0)
 
-static struct mtd_partition davinci_evm_norflash_partitions[] = {
-	/* bootloader (UBL, U-Boot, etc) in first 5 sectors */
-	{
-		.name		= "bootloader",
-		.offset		= 0,
-		.size		= 5 * SZ_64K,
-		.mask_flags	= MTD_WRITEABLE, /* force read-only */
-	},
-	/* bootloader params in the next 1 sectors */
-	{
-		.name		= "params",
-		.offset		= MTDPART_OFS_APPEND,
-		.size		= SZ_64K,
-		.mask_flags	= 0,
-	},
-	/* kernel */
-	{
-		.name		= "kernel",
-		.offset		= MTDPART_OFS_APPEND,
-		.size		= SZ_2M,
-		.mask_flags	= 0
-	},
-	/* file system */
-	{
-		.name		= "filesystem",
-		.offset		= MTDPART_OFS_APPEND,
-		.size		= MTDPART_SIZ_FULL,
-		.mask_flags	= 0
-	}
-};
-
-static struct physmap_flash_data davinci_evm_norflash_data = {
-	.width		= 2,
-	.parts		= davinci_evm_norflash_partitions,
-	.nr_parts	= ARRAY_SIZE(davinci_evm_norflash_partitions),
-};
-
-/* NOTE: CFI probe will correctly detect flash part as 32M, but EMIF
- * limits addresses to 16M, so using addresses past 16M will wrap */
-static struct resource davinci_evm_norflash_resource = {
-	.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
-	.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
-	.flags		= IORESOURCE_MEM,
-};
+#if defined(CONFIG_MTD_PHYSMAP) || \
+	defined(CONFIG_MTD_PHYSMAP_MODULE)
+#define HAS_NOR 1
+#else
+#define HAS_NOR 0
+#endif
 
-static struct platform_device davinci_evm_norflash_device = {
-	.name		= "physmap-flash",
-	.id		= 0,
-	.dev		= {
-		.platform_data	= &davinci_evm_norflash_data,
-	},
-	.num_resources	= 1,
-	.resource	= &davinci_evm_norflash_resource,
-};
+#if defined(CONFIG_MTD_NAND_DAVINCI) || \
+	defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
+#define HAS_NAND 1
+#else
+#define HAS_NAND 0
+#endif
 
+#if (HAS_NAND == 1)
 /* DM644x EVM includes a 64 MByte small-page NAND flash (16K blocks).
  * It may used instead of the (default) NOR chip to boot, using TI's
  * tools to install the secondary boot loader (UBL) and U-Boot.
@@ -166,15 +126,79 @@ static struct resource davinci_evm_nandflash_resource[] = {
 		.flags		= IORESOURCE_MEM,
 	},
 };
+#elif (HAS_NOR == 1)
+static struct mtd_partition davinci_evm_norflash_partitions[] = {
+	/* bootloader (UBL, U-Boot, etc) in first 5 sectors */
+	{
+		.name		= "bootloader",
+		.offset		= 0,
+		.size		= 5 * SZ_64K,
+		.mask_flags	= MTD_WRITEABLE, /* force read-only */
+	},
+	/* bootloader params in the next 1 sectors */
+	{
+		.name		= "params",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_64K,
+		.mask_flags	= 0,
+	},
+	/* kernel */
+	{
+		.name		= "kernel",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= SZ_2M,
+		.mask_flags	= 0
+	},
+	/* file system */
+	{
+		.name		= "filesystem",
+		.offset		= MTDPART_OFS_APPEND,
+		.size		= MTDPART_SIZ_FULL,
+		.mask_flags	= 0
+	}
+};
+
+static struct physmap_flash_data davinci_evm_norflash_data = {
+	.width		= 2,
+	.parts		= davinci_evm_norflash_partitions,
+	.nr_parts	= ARRAY_SIZE(davinci_evm_norflash_partitions),
+};
+
+/* NOTE: CFI probe will correctly detect flash part as 32M, but EMIF
+ * limits addresses to 16M, so using addresses past 16M will wrap */
+static struct resource davinci_evm_norflash_resource[] = {
+	{
+		.start		= DM644X_ASYNC_EMIF_DATA_CE0_BASE,
+		.end		= DM644X_ASYNC_EMIF_DATA_CE0_BASE + SZ_16M - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+#endif
 
-static struct platform_device davinci_evm_nandflash_device = {
-	.name		= "davinci_nand",
-	.id		= 0,
-	.dev		= {
-		.platform_data	= &davinci_evm_nandflash_data,
+static struct platform_device dm644x_emif_devices[] __initdata = {
+#if (HAS_NAND == 1)
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+		.resource		= davinci_evm_nandflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(davinci_evm_nandflash_resource),
+		.dev		= {
+			.platform_data	= &davinci_evm_nandflash_data,
+		},
 	},
-	.num_resources	= ARRAY_SIZE(davinci_evm_nandflash_resource),
-	.resource	= davinci_evm_nandflash_resource,
+#elif (HAS_NOR == 1)
+	{
+		.name		= "physmap-flash",
+		.id		= 0,
+		.resource		= davinci_evm_norflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(davinci_evm_norflash_resource),
+		.dev		= {
+			.platform_data	= &davinci_evm_norflash_data,
+		},
+	},
+#endif
 };
 
 static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
@@ -649,19 +673,19 @@ static int davinci_phy_fixup(struct phy_device *phydev)
 #define HAS_ATA 0
 #endif
 
-#if defined(CONFIG_MTD_PHYSMAP) || \
-    defined(CONFIG_MTD_PHYSMAP_MODULE)
-#define HAS_NOR 1
-#else
-#define HAS_NOR 0
-#endif
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm644x_emif_devices,
+	.num_devices	= ARRAY_SIZE(dm644x_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
+	},
+};
 
-#if defined(CONFIG_MTD_NAND_DAVINCI) || \
-    defined(CONFIG_MTD_NAND_DAVINCI_MODULE)
-#define HAS_NAND 1
-#else
-#define HAS_NAND 0
-#endif
 
 static __init void davinci_evm_init(void)
 {
@@ -683,13 +707,12 @@ static __init void davinci_evm_init(void)
 
 		/* only one device will be jumpered and detected */
 		if (HAS_NAND) {
-			platform_device_register(&davinci_evm_nandflash_device);
 			evm_leds[7].default_trigger = "nand-disk";
 			if (HAS_NOR)
 				pr_warning("WARNING: both NAND and NOR flash "
 					"are enabled; disable one of them.\n");
-		} else if (HAS_NOR)
-			platform_device_register(&davinci_evm_norflash_device);
+		}
+		platform_device_register(&davinci_emif_device);
 	}
 
 	platform_add_devices(davinci_evm_devices,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index af55a9d..34bc4af 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -104,15 +104,29 @@ static struct resource davinci_nand_resources[] = {
 	},
 };
 
-static struct platform_device davinci_nand_device = {
-	.name			= "davinci_nand",
-	.id			= 0,
+static struct platform_device dm646x_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_nand_resources,
+		.num_resources		= ARRAY_SIZE(davinci_nand_resources),
+		.dev		= {
+			.platform_data	= &davinci_nand_data,
+		},
+	},
+};
 
-	.num_resources		= ARRAY_SIZE(davinci_nand_resources),
-	.resource		= davinci_nand_resources,
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= dm646x_emif_devices,
+	.num_devices	= ARRAY_SIZE(dm646x_emif_devices),
+};
 
-	.dev			= {
-		.platform_data	= &davinci_nand_data,
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
 	},
 };
 
@@ -782,7 +796,7 @@ static __init void evm_init(void)
 	if (machine_is_davinci_dm6467tevm())
 		davinci_nand_data.timing = &dm6467tevm_nandflash_timing;
 
-	platform_device_register(&davinci_nand_device);
+	platform_device_register(&davinci_emif_device);
 
 	dm646x_init_edma(dm646x_edma_rsv);
 
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 672d820..4e48ade 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -19,6 +19,7 @@
 #include <linux/etherdevice.h>
 #include <linux/spi/spi.h>
 #include <linux/spi/flash.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/io.h>
 #include <asm/mach-types.h>
@@ -414,18 +415,35 @@ static struct resource mityomapl138_nandflash_resource[] = {
 	},
 };
 
-static struct platform_device mityomapl138_nandflash_device = {
-	.name		= "davinci_nand",
-	.id		= 1,
-	.dev		= {
-		.platform_data	= &mityomapl138_nandflash_data,
+static struct platform_device mityomapl138_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 1,
+
+		.resource		= mityomapl138_nandflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(mityomapl138_nandflash_resource),
+		.dev		= {
+			.platform_data	= &mityomapl138_nandflash_data,
+		},
+	},
+};
+
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= mityomapl138_emif_devices,
+	.num_devices	= ARRAY_SIZE(mityomapl138_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
 	},
-	.num_resources	= ARRAY_SIZE(mityomapl138_nandflash_resource),
-	.resource	= mityomapl138_nandflash_resource,
 };
 
 static struct platform_device *mityomapl138_devices[] __initdata = {
-	&mityomapl138_nandflash_device,
+	&davinci_emif_device,
 };
 
 static void __init mityomapl138_setup_nand(void)
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index 8d34f51..c1c6fa1 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -26,6 +26,7 @@
 #include <linux/platform_device.h>
 #include <linux/gpio.h>
 #include <linux/mtd/partitions.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
index 31da3c5..ac36320 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -30,6 +30,7 @@
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/nand.h>
 #include <linux/mtd/partitions.h>
+#include <linux/mfd/davinci_aemif.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -81,14 +82,31 @@ static struct resource davinci_sffsdr_nandflash_resource[] = {
 	},
 };
 
-static struct platform_device davinci_sffsdr_nandflash_device = {
-	.name		= "davinci_nand", /* Name of driver */
-	.id		= 0,
-	.dev		= {
-		.platform_data	= &davinci_sffsdr_nandflash_data,
+static struct platform_device davinci_sffsdr_emif_devices[] __initdata = {
+	{
+		.name		= "davinci_nand",
+		.id		= 0,
+
+		.resource		= davinci_sffsdr_nandflash_resource,
+		.num_resources		=
+			ARRAY_SIZE(davinci_sffsdr_nandflash_resource),
+		.dev		= {
+			.platform_data	= &davinci_sffsdr_nandflash_data,
+		},
+	},
+};
+
+static struct davinci_aemif_devices davinci_emif_devices = {
+	.devices	= davinci_sffsdr_emif_devices,
+	.num_devices	= ARRAY_SIZE(davinci_sffsdr_emif_devices),
+};
+
+static struct platform_device davinci_emif_device = {
+	.name	= "davinci_aemif",
+	.id	= -1,
+	.dev	= {
+		.platform_data	= &davinci_emif_devices,
 	},
-	.num_resources	= ARRAY_SIZE(davinci_sffsdr_nandflash_resource),
-	.resource	= davinci_sffsdr_nandflash_resource,
 };
 
 static struct at24_platform_data eeprom_info = {
@@ -121,7 +139,7 @@ static void __init sffsdr_init_i2c(void)
 }
 
 static struct platform_device *davinci_sffsdr_devices[] __initdata = {
-	&davinci_sffsdr_nandflash_device,
+	&davinci_emif_device,
 };
 
 static struct davinci_uart_config uart_config __initdata = {
-- 
1.7.1


From anantgole at ti.com  Thu Feb 23 10:06:55 2012
From: anantgole at ti.com (Gole, Anant)
Date: Thu, 23 Feb 2012 16:06:55 +0000
Subject: davinci_emac/mdio: SOFT_RESET of EMAC module resets MDIO on AM1808
In-Reply-To: <CABkLObpZ52yVnq-wqnm8nC=bSnzz41RnC=wbQD3U7NRmr2SRBQ@mail.gmail.com>
References: <CABkLObpZ52yVnq-wqnm8nC=bSnzz41RnC=wbQD3U7NRmr2SRBQ@mail.gmail.com>
Message-ID: <3F602CD5BF1C69469B2F060E90850642AD3A85@DQHE01.ent.ti.com>

>Now the question was: Who is turning off the MDIO controller? After a
>bit of debugging I found out that the reset of the MDIO controller
>seems to be caused by these lines in the davinci_emac driver in
>emac_hw_enable() in drivers/net/ethernet/ti/davinci_emac.c:
>
>emac_write(EMAC_SOFTRESET, 1);
>while (emac_read(EMAC_SOFTRESET))
>        cpu_relax();
>
>According to the AM1808 Technical Reference Manual (sections 18.2.14.1
>and 18.3.3.34 in [1]), writing a 1 to the EMAC_SOFTRESET register
>resets the EMAC module, but not the MDIO module. However, when I
>comment out the code above, the MDIO control register is not affected
>and the warning 'resetting idled controller' disappears.
>
>Is this an error in the documentation? Or in hardware? Or did I miss
>something here? I already asked this questions in TI's E2E forum [2]
>but did not get an answer yet. I would like to ask all the TI people
>out there to help me getting an answer to this question. Thanks you!


Christian,
We are looking into this right now. We believe that the mac reset 
should not impact MDIO reset but clearly you are seeing that
behavior and we need to investigate.

>
>Anyway, I think this should be fixed since it's bad when a driver
>(davinci_emac) resets another driver's (davinci_mdio's) hardware.
>
Once we find the root cause of this we would be able to fix this.
right now the EMAC reset code is not incorrect - just need to find
why it shows the wrong behavior with MDIO and if this is seen
only on AM1808 - will update you as soon as we find out.

Regards,
Anant

From davem at davemloft.net  Fri Feb 24 02:23:49 2012
From: davem at davemloft.net (David Miller)
Date: Fri, 24 Feb 2012 03:23:49 -0500 (EST)
Subject: [PATCH] davinci_cpdma: Fix channel number written to teardown
	registers
In-Reply-To: <1329983880-23921-1-git-send-email-christian.riesch@omicron.at>
References: <1329983880-23921-1-git-send-email-christian.riesch@omicron.at>
Message-ID: <20120224.032349.795458855905559116.davem@davemloft.net>

From: Christian Riesch <christian.riesch at omicron.at>
Date: Thu, 23 Feb 2012 08:58:00 +0100

> chan->chan_num is 0..CPDMA_MAX_CHANNELS-1 for tx channels and
> CPDMA_MAX_CHANNELS..2*CPDMA_MAX_CHANNELS-1 for rx channels. However,
> the rx and tx teardown registers expect zero based channel numbering.
> 
> Since the upper bits of the registers are reserved, the teardown also
> worked before, this patch is cleanup only.
> 
> Signed-off-by: Christian Riesch <christian.riesch at omicron.at>

Applied to net-next.

From davem at davemloft.net  Fri Feb 24 02:24:27 2012
From: davem at davemloft.net (David Miller)
Date: Fri, 24 Feb 2012 03:24:27 -0500 (EST)
Subject: [PATCH] davinci_mdio: Correct bitmask for clock divider value
In-Reply-To: <1329984478-24090-1-git-send-email-christian.riesch@omicron.at>
References: <1329984478-24090-1-git-send-email-christian.riesch@omicron.at>
Message-ID: <20120224.032427.261928925990890713.davem@davemloft.net>

From: Christian Riesch <christian.riesch at omicron.at>
Date: Thu, 23 Feb 2012 09:07:58 +0100

> The CLKDIV bitfield in the MDIO Control Register is a 16 bit field,
> therefore the CLKDIV value may range from 0 to 0xffff.
> 
> Signed-off-by: Christian Riesch <christian.riesch at omicron.at>

Also applied to net-next.

From davem at davemloft.net  Fri Feb 24 02:25:31 2012
From: davem at davemloft.net (David Miller)
Date: Fri, 24 Feb 2012 03:25:31 -0500 (EST)
Subject: [PATCH v2] davinci_emac: Do not free all rx dma descriptors
	during init
In-Reply-To: <1329995657-7051-1-git-send-email-christian.riesch@omicron.at>
References: <1329995657-7051-1-git-send-email-christian.riesch@omicron.at>
Message-ID: <20120224.032531.607179170339382701.davem@davemloft.net>

From: Christian Riesch <christian.riesch at omicron.at>
Date: Thu, 23 Feb 2012 12:14:17 +0100

> This patch fixes a regression that was introduced by
> 
> commit 0a5f38467765ee15478db90d81e40c269c8dda20
> davinci_emac: Add Carrier Link OK check in Davinci RX Handler
> 
> Said commit adds a check whether the carrier link is ok. If the link is
> not ok, the skb is freed and no new dma descriptor added to the rx dma
> channel. This causes trouble during initialization when the carrier
> status has not yet been updated. If a lot of packets are received while
> netif_carrier_ok returns false, all dma descriptors are freed and the
> rx dma transfer is stopped.
> 
> The bug occurs when the board is connected to a network with lots of
> traffic and the ifconfig down/up is done, e.g., when reconfiguring
> the interface with DHCP.
> 
> The bug can be reproduced by flood pinging the davinci board while doing
> ifconfig eth0 down
> ifconfig eth0 up
> on the board.
> 
> After that, the rx path stops working and the overrun value reported
> by ifconfig is counting up.
> 
> This patch reverts commit 0a5f38467765ee15478db90d81e40c269c8dda20
> and instead issues warnings only if cpdma_chan_submit returns -ENOMEM.
> 
> Signed-off-by: Christian Riesch <christian.riesch at omicron.at>

Applied to 'net', thanks.

From sudhakar.raj at ti.com  Fri Feb 24 07:02:00 2012
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Fri, 24 Feb 2012 13:02:00 +0000
Subject: davinci_emac/mdio: SOFT_RESET of EMAC module resets MDIO on AM1808
In-Reply-To: <CABkLObpZ52yVnq-wqnm8nC=bSnzz41RnC=wbQD3U7NRmr2SRBQ@mail.gmail.com>
References: <CABkLObpZ52yVnq-wqnm8nC=bSnzz41RnC=wbQD3U7NRmr2SRBQ@mail.gmail.com>
Message-ID: <B6A220404B6BFC4BBD2AB91C54D39DF431775E1B@DBDE01.ent.ti.com>

Hi Christian,

On Thu, Feb 23, 2012 at 14:39:49, Christian Riesch wrote:
> Hi,
> I observed this behavior on a Texas Instruments AM1808 SoC (AM1808
> experimenter's kit) running the current mainline kernel:
> 
> # ifconfig eth0 down
> # ifconfig eth0 up
> davinci_mdio davinci_mdio.0: resetting idled controller
> net eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=davinci_mdio-0:00)
> # PHY: davinci_mdio-0:00 - Link is Up - 100/Full
> 

I also observed this issue with the kernel from linux-davinci tree from
gitorious.

> After each ifconfig eth0 up I get this 'resetting idled controller'
> warning. I added a few debug messages to the davinci_mdio driver and
> noticed that the MDIO control register was set to its reset value
> (clock divider 0xff and MDIO turned off) after an ifconfig eth0 up.
> Therefore, this warning is issued and a reconfiguration of the MDIO
> controller is done by the driver.
> 
> Now the question was: Who is turning off the MDIO controller? After a
> bit of debugging I found out that the reset of the MDIO controller
> seems to be caused by these lines in the davinci_emac driver in
> emac_hw_enable() in drivers/net/ethernet/ti/davinci_emac.c:
> 
> emac_write(EMAC_SOFTRESET, 1);
> while (emac_read(EMAC_SOFTRESET))
>         cpu_relax();
> 
> According to the AM1808 Technical Reference Manual (sections 18.2.14.1
> and 18.3.3.34 in [1]), writing a 1 to the EMAC_SOFTRESET register
> resets the EMAC module, but not the MDIO module. However, when I
> comment out the code above, the MDIO control register is not affected
> and the warning 'resetting idled controller' disappears.
> 

But this was not the case for me. Even after commenting out the above lines,
I could still see that MDIO was getting reset.

During eth0 up, the smsc_phy_config_init() function calls the mdiobus_read()
function. During this sequence if the MDIO state machine is in IDLE state,
then MDIO is reset causing the above warning message to appear.

In summary, EMAC reset is not causing the MDIO reset to happen.

Thanks,
Sudhakar

From christian.riesch at omicron.at  Fri Feb 24 08:15:23 2012
From: christian.riesch at omicron.at (Christian Riesch)
Date: Fri, 24 Feb 2012 15:15:23 +0100
Subject: davinci_emac/mdio: SOFT_RESET of EMAC module resets MDIO on AM1808
In-Reply-To: <B6A220404B6BFC4BBD2AB91C54D39DF431775E1B@DBDE01.ent.ti.com>
References: <B6A220404B6BFC4BBD2AB91C54D39DF431775E1B@DBDE01.ent.ti.com>
Message-ID: <1330092923-10899-1-git-send-email-christian.riesch@omicron.at>

Hello Sudhakar,

On Fri, Feb 24, 2012 at 2:02 PM, Rajashekhara, Sudhakar <sudhakar.raj at ti.com> wrote:
> On Thu, Feb 23, 2012 at 14:39:49, Christian Riesch wrote:
>> Hi,
>> I observed this behavior on a Texas Instruments AM1808 SoC (AM1808
>> experimenter's kit) running the current mainline kernel:
>>
>> # ifconfig eth0 down
>> # ifconfig eth0 up
>> davinci_mdio davinci_mdio.0: resetting idled controller
>> net eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=davinci_mdio-0:00)
>> # PHY: davinci_mdio-0:00 - Link is Up - 100/Full
>>
>
> I also observed this issue with the kernel from linux-davinci tree from
> gitorious.
>
>> After each ifconfig eth0 up I get this 'resetting idled controller'
>> warning. I added a few debug messages to the davinci_mdio driver and
>> noticed that the MDIO control register was set to its reset value
>> (clock divider 0xff and MDIO turned off) after an ifconfig eth0 up.
>> Therefore, this warning is issued and a reconfiguration of the MDIO
>> controller is done by the driver.
>>
>> Now the question was: Who is turning off the MDIO controller? After a
>> bit of debugging I found out that the reset of the MDIO controller
>> seems to be caused by these lines in the davinci_emac driver in
>> emac_hw_enable() in drivers/net/ethernet/ti/davinci_emac.c:
>>
>> emac_write(EMAC_SOFTRESET, 1);
>> while (emac_read(EMAC_SOFTRESET))
>>         cpu_relax();
>>
>> According to the AM1808 Technical Reference Manual (sections 18.2.14.1
>> and 18.3.3.34 in [1]), writing a 1 to the EMAC_SOFTRESET register
>> resets the EMAC module, but not the MDIO module. However, when I
>> comment out the code above, the MDIO control register is not affected
>> and the warning 'resetting idled controller' disappears.
>>
>
> But this was not the case for me. Even after commenting out the above lines,
> I could still see that MDIO was getting reset.

Uh, I am sorry. I forgot to mention that there is a second
emac_write(EMAC_SOFTRESET,1); in emac_dev_stop() in davinci_emac.c. 
This one must also be commented out to make the resetting idled controller 
message go away.

The patch below shows that changes that I did. May I please ask you to try
again with these changes?

Regards, Christian

>
> During eth0 up, the smsc_phy_config_init() function calls the mdiobus_read()
> function. During this sequence if the MDIO state machine is in IDLE state,
> then MDIO is reset causing the above warning message to appear.
>
> In summary, EMAC reset is not causing the MDIO reset to happen.

---
 drivers/net/ethernet/ti/davinci_emac.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 4b2f545..733d538 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1290,10 +1290,10 @@ static int emac_hw_enable(struct emac_priv *priv)
 	u32 val, mbp_enable, mac_control;
 
 	/* Soft reset */
-	emac_write(EMAC_SOFTRESET, 1);
+/*	emac_write(EMAC_SOFTRESET, 1);
 	while (emac_read(EMAC_SOFTRESET))
 		cpu_relax();
-
+*/
 	/* Disable interrupt & Set pacing for more interrupts initially */
 	emac_int_disable(priv);
 
@@ -1672,7 +1672,7 @@ static int emac_dev_stop(struct net_device *ndev)
 	netif_carrier_off(ndev);
 	emac_int_disable(priv);
 	cpdma_ctlr_stop(priv->dma);
-	emac_write(EMAC_SOFTRESET, 1);
+/*	emac_write(EMAC_SOFTRESET, 1);*/
 
 	if (priv->phydev)
 		phy_disconnect(priv->phydev);
-- 
1.7.0.4


From nsekhar at ti.com  Fri Feb 24 15:25:17 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 24 Feb 2012 21:25:17 +0000
Subject: [GIT PULL] DaVinci cleanups for v3.4
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317D2DB9@DBDE01.ent.ti.com>

Hi Arnd, Olof,

Can you please pull these DaVinci clean-up patches for
the v3.4 merge window? I have made sure that these don't
have any conflicts with the rmk/for-armsoc branch of
the arm-soc tree.

These patches need the following two commits from linux-next
(next-20120224) to keep the VPIF and CQ93VC drivers building.

2e932f2  ASoC: CQ93VC: remove machine specific header file inclusion from codec
db38951  [media] davinci: vpif: remove machine specific header file includes

However, there will not be any merge conflicts even if these patches
are not applied.

These patches do generate merge conflicts in latest linux-next
due to a recent DaVinci bug fix. I resolved the conflict in the
following manner:

diff --cc arch/arm/mach-davinci/board-dm644x-evm.c
index 1247ecd,b89bebe..864f676
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@@ -40,7 -39,9 +39,9 @@@
  #include <mach/usb.h>
  #include <mach/aemif.h>
  
+ #include "davinci.h"
+ 
 -#define DM644X_EVM_PHY_ID		"0:01"
 +#define DM644X_EVM_PHY_ID		"davinci_mdio-0:01"
  #define LXT971_PHY_ID	(0x001378e2)
  #define LXT971_PHY_MASK	(0xfffffff0)
  
diff --cc arch/arm/mach-davinci/board-neuros-osd2.c
index 8d34f51,3d12a3a..a772bb4
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@@ -39,7 -38,9 +38,9 @@@
  #include <mach/mmc.h>
  #include <mach/usb.h>
  
+ #include "davinci.h"
+ 
 -#define NEUROS_OSD2_PHY_ID		"0:01"
 +#define NEUROS_OSD2_PHY_ID		"davinci_mdio-0:01"
  #define LXT971_PHY_ID			0x001378e2
  #define LXT971_PHY_MASK			0xfffffff0
  
diff --cc arch/arm/mach-davinci/board-sffsdr.c
index 31da3c5,897cec5..76e67509
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@@ -42,7 -41,9 +41,9 @@@
  #include <mach/mux.h>
  #include <mach/usb.h>
  
+ #include "davinci.h"
+ 
 -#define SFFSDR_PHY_ID		"0:01"
 +#define SFFSDR_PHY_ID		"davinci_mdio-0:01"
  static struct mtd_partition davinci_sffsdr_nandflash_partition[] = {
  	/* U-Boot Environment: Block 0
  	 * UBL:                Block 1

The pull request follows:

The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:
  Linus Torvalds (1):
        Linux 3.3-rc1

are available in the git repository at:

  git://gitorious.org/linux-davinci/linux-davinci.git v3.4/cleanup

Manjunath Hadli (8):
      ARM: davinci: dm644x: move private definitions to C file
      ARM: davinci: dm365: move private definitions to C file
      ARM: davinci: dm646x: move private definitions to C file
      ARM: davinci: create new common platform header for davinci
      ARM: davinci: streamline sysmod access
      ARM: davinci: dm644x: improve readability using macro
      ARM: davinci: dm644x: fix inconsistent variable naming
      ARM: davinci: dm644x: don't force vpfe registeration on all boards

 arch/arm/mach-davinci/board-dm355-evm.c       |    3 +-
 arch/arm/mach-davinci/board-dm355-leopard.c   |    3 +-
 arch/arm/mach-davinci/board-dm365-evm.c       |    3 +-
 arch/arm/mach-davinci/board-dm644x-evm.c      |   28 ++++----
 arch/arm/mach-davinci/board-dm646x-evm.c      |   32 +++------
 arch/arm/mach-davinci/board-neuros-osd2.c     |    3 +-
 arch/arm/mach-davinci/board-sffsdr.c          |    3 +-
 arch/arm/mach-davinci/davinci.h               |   96 +++++++++++++++++++++++++
 arch/arm/mach-davinci/devices.c               |   32 ++++++---
 arch/arm/mach-davinci/dm355.c                 |    3 +-
 arch/arm/mach-davinci/dm365.c                 |   19 +++++-
 arch/arm/mach-davinci/dm644x.c                |   53 +++++++++-----
 arch/arm/mach-davinci/dm646x.c                |   21 ++++--
 arch/arm/mach-davinci/include/mach/dm355.h    |   32 --------
 arch/arm/mach-davinci/include/mach/dm365.h    |   52 -------------
 arch/arm/mach-davinci/include/mach/dm644x.h   |   47 ------------
 arch/arm/mach-davinci/include/mach/dm646x.h   |   41 -----------
 arch/arm/mach-davinci/include/mach/hardware.h |    2 -
 18 files changed, 218 insertions(+), 255 deletions(-)
 create mode 100644 arch/arm/mach-davinci/davinci.h
 delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h
 delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h
 delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h
 delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h

From nsekhar at ti.com  Fri Feb 24 15:45:51 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Fri, 24 Feb 2012 21:45:51 +0000
Subject: [GIT PULL] DaVinci fix for v3.4
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317D2DDA@DBDE01.ent.ti.com>

Hi Arnd, Olof,

Can you please pull the following DaVinci fix for v3.4?
It has no conflicts with rmk/for-armsoc branch of the
arm-soc tree or with latest linux-next.

Thanks,
Sekhar

The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab:
  Linus Torvalds (1):
        Linux 3.3-rc2

are available in the git repository at:

  git://gitorious.org/linux-davinci/linux-davinci.git v3.4/fixes

Heiko Schocher (1):
      ARM: davinci: map default_queue to edma channels

 arch/arm/mach-davinci/dma.c               |    6 +-----
 arch/arm/mach-davinci/include/mach/edma.h |    5 +++++
 2 files changed, 6 insertions(+), 5 deletions(-)

From sudhakar.raj at ti.com  Mon Feb 27 04:15:03 2012
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Mon, 27 Feb 2012 10:15:03 +0000
Subject: davinci_emac/mdio: SOFT_RESET of EMAC module resets MDIO on AM1808
In-Reply-To: <1330092923-10899-1-git-send-email-christian.riesch@omicron.at>
References: <B6A220404B6BFC4BBD2AB91C54D39DF431775E1B@DBDE01.ent.ti.com>
	<1330092923-10899-1-git-send-email-christian.riesch@omicron.at>
Message-ID: <B6A220404B6BFC4BBD2AB91C54D39DF43177683F@DBDE01.ent.ti.com>

Hi Christian,

On Fri, Feb 24, 2012 at 19:45:23, Christian Riesch wrote:
> Hello Sudhakar,
> 
> On Fri, Feb 24, 2012 at 2:02 PM, Rajashekhara, Sudhakar <sudhakar.raj at ti.com> wrote:
> > On Thu, Feb 23, 2012 at 14:39:49, Christian Riesch wrote:
> >> Hi,
> >> I observed this behavior on a Texas Instruments AM1808 SoC (AM1808
> >> experimenter's kit) running the current mainline kernel:
> >>

[snip]

> >>
> >> According to the AM1808 Technical Reference Manual (sections 18.2.14.1
> >> and 18.3.3.34 in [1]), writing a 1 to the EMAC_SOFTRESET register
> >> resets the EMAC module, but not the MDIO module. However, when I
> >> comment out the code above, the MDIO control register is not affected
> >> and the warning 'resetting idled controller' disappears.
> >>
> >
> > But this was not the case for me. Even after commenting out the above lines,
> > I could still see that MDIO was getting reset.
> 
> Uh, I am sorry. I forgot to mention that there is a second
> emac_write(EMAC_SOFTRESET,1); in emac_dev_stop() in davinci_emac.c. 
> This one must also be commented out to make the resetting idled controller 
> message go away.
> 
> The patch below shows that changes that I did. May I please ask you to try
> again with these changes?
> 

I was able to reproduce the issue. I'll debug this further and get back to you.

Regards,
Sudhakar

From sameo at linux.intel.com  Mon Feb 27 08:26:38 2012
From: sameo at linux.intel.com (Samuel Ortiz)
Date: Mon, 27 Feb 2012 15:26:38 +0100
Subject: [PATCH v5 2/3] arm:davinci: move emif driver to mfd framework
In-Reply-To: <1330005504-25321-3-git-send-email-prakash.pm@ti.com>
References: <y>
 <1330005504-25321-3-git-send-email-prakash.pm@ti.com>
Message-ID: <20120227142638.GN27687@sortiz-mobl>

Hi Prakash,

On Thu, Feb 23, 2012 at 07:28:23PM +0530, Manjunathappa, Prakash wrote:
> +static int __init davinci_aemif_probe(struct platform_device *pdev)
> +{
> +	struct davinci_aemif_devices *davinci_aemif_devices =
> +		pdev->dev.platform_data;
> +	struct platform_device *devices;
> +	struct mfd_cell *cells;
> +	int i, ret, count;
> +
> +	devices = davinci_aemif_devices->devices;
> +
> +	cells = kzalloc(sizeof(struct mfd_cell) *
> +			davinci_aemif_devices->num_devices, GFP_KERNEL);
> +
> +	for (i = 0, count = 0; i < davinci_aemif_devices->num_devices; i++) {
> +		if (!strcmp(devices[i].name, "davinci_nand")) {
> +			cells[count].pdata_size =
> +				sizeof(struct davinci_nand_pdata);
> +		} else if (!strcmp(devices[i].name, "physmap-flash")) {
> +			cells[count].pdata_size =
> +				sizeof(struct physmap_flash_data);
> +		} else
> +			continue;
> +
> +		cells[count].name = devices[i].name;
> +		cells[count].platform_data =
> +			devices[i].dev.platform_data;
> +		cells[count].id = devices[i].id;
> +		cells[count].resources = devices[i].resource;
> +		cells[count].num_resources = devices[i].num_resources;
> +		count++;
> +	}
So it seems you're passing a platform devices array through your mfd aemif
platform data pointer. And from what I can see, it's mostly a 1 entry array
(for the NAND case) or a 2 entries array (for the NAND and NOR case).
In that case, adding an MFD driver in the middle brings basically nothing but
confusion and overhead (and 200+ lines of code).
So unless someone explains to me how this is doing any good to the kernel in
general, I'm not going to take this patchset.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

From arnd at arndb.de  Mon Feb 27 08:26:39 2012
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 27 Feb 2012 14:26:39 +0000
Subject: [GIT PULL] DaVinci fix for v3.4
In-Reply-To: <DF0F476B391FA8409C78302C7BA518B6317D2DDA@DBDE01.ent.ti.com>
References: <DF0F476B391FA8409C78302C7BA518B6317D2DDA@DBDE01.ent.ti.com>
Message-ID: <201202271426.39663.arnd@arndb.de>

On Friday 24 February 2012, Nori, Sekhar wrote:
> Can you please pull the following DaVinci fix for v3.4?
> It has no conflicts with rmk/for-armsoc branch of the
> arm-soc tree or with latest linux-next.

Pulled into fixes/non-critical, thanks!

	ARnd

From arnd at arndb.de  Mon Feb 27 08:59:52 2012
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 27 Feb 2012 14:59:52 +0000
Subject: [GIT PULL] DaVinci cleanups for v3.4
In-Reply-To: <DF0F476B391FA8409C78302C7BA518B6317D2DB9@DBDE01.ent.ti.com>
References: <DF0F476B391FA8409C78302C7BA518B6317D2DB9@DBDE01.ent.ti.com>
Message-ID: <201202271459.52216.arnd@arndb.de>

On Friday 24 February 2012, Nori, Sekhar wrote:
> Hi Arnd, Olof,
> 
> Can you please pull these DaVinci clean-up patches for
> the v3.4 merge window? I have made sure that these don't
> have any conflicts with the rmk/for-armsoc branch of
> the arm-soc tree.
> 
> These patches need the following two commits from linux-next
> (next-20120224) to keep the VPIF and CQ93VC drivers building.
> 
> 2e932f2  ASoC: CQ93VC: remove machine specific header file inclusion from codec
> db38951  [media] davinci: vpif: remove machine specific header file includes

In general, don't worry too much about conflicts that are easy to
resolve. However, having these extra dependencies is not good,
because it means that we cannot easily build-test the arm-soc
tree by itself and it breaks bisection through the git history.

In the future, please make sure that dependent commits show up
in the right order. For now, I've added the patch below on top
of your series.

	Arnd

commit 6ea96e111e6a7f06ef62227bf64e8cd65bd705b3
Author: Arnd Bergmann <arnd at arndb.de>
Date:   Mon Feb 27 14:55:22 2012 +0000

    ARM: davinci: add back dummy header files
    
    The mach/dm365.h and mach/dm646xh headers are currently being included
    in some device drivers. The removal of those includes is already merged
    in some subsystem trees, but adding the dummy files ensures that this
    branch can be built standalone.
    
    Signed-off-by: Arnd Bergmann <arnd at arndb.de>

diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
new file mode 100644
index 0000000..b9bf3d6
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -0,0 +1 @@
+/* empty, remove once unused */
diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h
new file mode 100644
index 0000000..b9bf3d6
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -0,0 +1 @@
+/* empty, remove once unused */

From prakash.pm at ti.com  Mon Feb 27 23:44:39 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Tue, 28 Feb 2012 05:44:39 +0000
Subject: [PATCH v5 2/3] arm:davinci: move emif driver to mfd framework
In-Reply-To: <20120227142638.GN27687@sortiz-mobl>
References: <y> <1330005504-25321-3-git-send-email-prakash.pm@ti.com>
	<20120227142638.GN27687@sortiz-mobl>
Message-ID: <A73F36158E33644199EB82C5EC81C7BC3176D103@DBDE01.ent.ti.com>

Hi Samuel,

On Mon, Feb 27, 2012 at 19:56:38, Samuel Ortiz wrote:
[snip]
> So it seems you're passing a platform devices array through your mfd aemif
> platform data pointer. And from what I can see, it's mostly a 1 entry array
> (for the NAND case) or a 2 entries array (for the NAND and NOR case).
> In that case, adding an MFD driver in the middle brings basically nothing but
> confusion and overhead (and 200+ lines of code).
> So unless someone explains to me how this is doing any good to the kernel in
> general, I'm not going to take this patchset.
> 
> Cheers,
> Samuel.
>

In this way we trying to isolate future modification of aemif driver not to depict
as platform code change, the need for this is based on discussion in below thread
http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-tt7059739.html#none

Earlier also concern was expressed to move aemif driver out of arch/arm to drivers folder.
Here is the link for the same: http://lists.infradead.org/pipermail/linux-mtd/2011-August/037308.html
Since aemif driver supports NAND/NOR devices, we feel MFD is the place holder.

Thanks,
Prakash


From sudhakar.raj at ti.com  Mon Feb 27 23:46:08 2012
From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar)
Date: Tue, 28 Feb 2012 05:46:08 +0000
Subject: davinci_emac/mdio: SOFT_RESET of EMAC module resets MDIO on AM1808
References: <B6A220404B6BFC4BBD2AB91C54D39DF431775E1B@DBDE01.ent.ti.com>
	<1330092923-10899-1-git-send-email-christian.riesch@omicron.at> 
Message-ID: <B6A220404B6BFC4BBD2AB91C54D39DF431776D23@DBDE01.ent.ti.com>

Hi Christian,

On Mon, Feb 27, 2012 at 15:44:54, Rajashekhara, Sudhakar wrote:
> Hi Christian,
> 
> On Fri, Feb 24, 2012 at 19:45:23, Christian Riesch wrote:
> > Hello Sudhakar,
> > 
> > On Fri, Feb 24, 2012 at 2:02 PM, Rajashekhara, Sudhakar <sudhakar.raj at ti.com> wrote:
> > > On Thu, Feb 23, 2012 at 14:39:49, Christian Riesch wrote:
> > >> Hi,
> > >> I observed this behavior on a Texas Instruments AM1808 SoC (AM1808
> > >> experimenter's kit) running the current mainline kernel:
> > >>
> 
> [snip]
> 
> > >>
> > >> According to the AM1808 Technical Reference Manual (sections 18.2.14.1
> > >> and 18.3.3.34 in [1]), writing a 1 to the EMAC_SOFTRESET register
> > >> resets the EMAC module, but not the MDIO module. However, when I
> > >> comment out the code above, the MDIO control register is not affected
> > >> and the warning 'resetting idled controller' disappears.
> > >>
> > >
> > > But this was not the case for me. Even after commenting out the above lines,
> > > I could still see that MDIO was getting reset.
> > 
> > Uh, I am sorry. I forgot to mention that there is a second
> > emac_write(EMAC_SOFTRESET,1); in emac_dev_stop() in davinci_emac.c. 
> > This one must also be commented out to make the resetting idled controller 
> > message go away.
> > 
> > The patch below shows that changes that I did. May I please ask you to try
> > again with these changes?
> > 
> 
> I was able to reproduce the issue. I'll debug this further and get back to you.
> 

I was going through the mailing list discussions where a work around for emac
soft-reset tie-up to mdio controller has been proposed. I think this was a known
issue on TI's da8xx family of devices. Please refer to the thread at
http://www.spinics.net/lists/netdev/msg140465.html.

Cyril,
As you have mentioned in your patch, did you get any confirmation from TI designer
regarding emac soft reset behavior? I see that nothing has been mentioned in the
EMAC user guide.

Thanks,
Sudhakar


From nsekhar at ti.com  Tue Feb 28 08:23:14 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 28 Feb 2012 14:23:14 +0000
Subject: [GIT PULL] DaVinci cleanups for v3.4
In-Reply-To: <201202271459.52216.arnd@arndb.de>
References: <DF0F476B391FA8409C78302C7BA518B6317D2DB9@DBDE01.ent.ti.com>
	<201202271459.52216.arnd@arndb.de>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317D6BF8@DBDE01.ent.ti.com>

Hi Arnd,

On Mon, Feb 27, 2012 at 20:29:52, Arnd Bergmann wrote:
> On Friday 24 February 2012, Nori, Sekhar wrote:
> > Hi Arnd, Olof,
> > 
> > Can you please pull these DaVinci clean-up patches for
> > the v3.4 merge window? I have made sure that these don't
> > have any conflicts with the rmk/for-armsoc branch of
> > the arm-soc tree.
> > 
> > These patches need the following two commits from linux-next
> > (next-20120224) to keep the VPIF and CQ93VC drivers building.
> > 
> > 2e932f2  ASoC: CQ93VC: remove machine specific header file inclusion from codec
> > db38951  [media] davinci: vpif: remove machine specific header file includes
> 
> In general, don't worry too much about conflicts that are easy to
> resolve. However, having these extra dependencies is not good,
> because it means that we cannot easily build-test the arm-soc
> tree by itself and it breaks bisection through the git history.
> 
> In the future, please make sure that dependent commits show up
> in the right order. For now, I've added the patch below on top
> of your series.

I guess the cleanest way to do that would have been to let
these patches go through my tree with appropriate maintainer
acks (but that obviously didn't happen - will try and fix
that for future). Per my understanding, it is encouraged that
a patch should get applied only through one tree, so I was
reluctant to apply them to any of the branches I send to you
after they were already in linux-next through other trees.

Thanks,
Sekhar


From nsekhar at ti.com  Tue Feb 28 08:38:31 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 28 Feb 2012 14:38:31 +0000
Subject: [PATCH 1/4] davinci: vpif: add check for genuine interrupts in
	the isr
In-Reply-To: <1327503934-28186-2-git-send-email-manjunath.hadli@ti.com>
References: <1327503934-28186-1-git-send-email-manjunath.hadli@ti.com>
	<1327503934-28186-2-git-send-email-manjunath.hadli@ti.com>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317D6C67@DBDE01.ent.ti.com>

Hi Manju,

On Wed, Jan 25, 2012 at 20:35:31, Hadli, Manjunath wrote:
> add a condition to in the isr to check for interrupt ownership and

"to" is misplaced here?

> channel number to make sure we do not service wrong interrupts.
>
> Signed-off-by: Manjunath Hadli <manjunath.hadli at ti.com>

I think it will be nice to expand on the "why" this patch
is required a little bit.

What is the usage case where you can get wrong interrupts?
What exactly happens if you service wrong interrupts?

Explaining these in the commit message will help the maintainers
take a call on the criticality of this patch (whether it should
be queued in the current -rc cycle or not).

Thanks,
Sekhar


From arnd at arndb.de  Tue Feb 28 09:27:39 2012
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 28 Feb 2012 15:27:39 +0000
Subject: [GIT PULL] DaVinci cleanups for v3.4
In-Reply-To: <DF0F476B391FA8409C78302C7BA518B6317D6BF8@DBDE01.ent.ti.com>
References: <DF0F476B391FA8409C78302C7BA518B6317D2DB9@DBDE01.ent.ti.com>
	<201202271459.52216.arnd@arndb.de>
	<DF0F476B391FA8409C78302C7BA518B6317D6BF8@DBDE01.ent.ti.com>
Message-ID: <201202281527.39302.arnd@arndb.de>

On Tuesday 28 February 2012, Nori, Sekhar wrote:
> I guess the cleanest way to do that would have been to let
> these patches go through my tree with appropriate maintainer
> acks (but that obviously didn't happen - will try and fix
> that for future). Per my understanding, it is encouraged that
> a patch should get applied only through one tree, so I was
> reluctant to apply them to any of the branches I send to you
> after they were already in linux-next through other trees.

That is correct, we generally try to avoid duplicating commits
but instead use branches that are based on a common history
containing whatever is needed in multiple places.

Note that the patch I applied does not duplicate the ones that
went into the other trees, it recreates dummy header files
instead and needs to be reverted at some point in the future
when everything has been merged.

	Arnd

From nsekhar at ti.com  Tue Feb 28 10:50:19 2012
From: nsekhar at ti.com (Nori, Sekhar)
Date: Tue, 28 Feb 2012 16:50:19 +0000
Subject: [GIT PULL] DaVinci cleanups for v3.4
In-Reply-To: <201202281527.39302.arnd@arndb.de>
References: <DF0F476B391FA8409C78302C7BA518B6317D2DB9@DBDE01.ent.ti.com>
	<201202271459.52216.arnd@arndb.de>
	<DF0F476B391FA8409C78302C7BA518B6317D6BF8@DBDE01.ent.ti.com>
	<201202281527.39302.arnd@arndb.de>
Message-ID: <DF0F476B391FA8409C78302C7BA518B6317D6ED7@DBDE01.ent.ti.com>

On Tue, Feb 28, 2012 at 20:57:39, Arnd Bergmann wrote:
> On Tuesday 28 February 2012, Nori, Sekhar wrote:
> > I guess the cleanest way to do that would have been to let
> > these patches go through my tree with appropriate maintainer
> > acks (but that obviously didn't happen - will try and fix
> > that for future). Per my understanding, it is encouraged that
> > a patch should get applied only through one tree, so I was
> > reluctant to apply them to any of the branches I send to you
> > after they were already in linux-next through other trees.
> 
> That is correct, we generally try to avoid duplicating commits
> but instead use branches that are based on a common history
> containing whatever is needed in multiple places.
> 
> Note that the patch I applied does not duplicate the ones that
> went into the other trees, it recreates dummy header files
> instead and needs to be reverted at some point in the future
> when everything has been merged.

Right. Thanks for taking care of this. Will send a revert once
the dependencies are upstream.

Thanks,
Sekhar


From hs at denx.de  Wed Feb 29 00:42:51 2012
From: hs at denx.de (Heiko Schocher)
Date: Wed, 29 Feb 2012 07:42:51 +0100
Subject: [PATCH v2 1/7] ARM: davinci,
	intc: Add OF support for TI interrupt controller
In-Reply-To: <4F44DE24.30606@mvista.com>
References: <1329893410-24413-1-git-send-email-hs@denx.de>
	<1329893410-24413-2-git-send-email-hs@denx.de>
	<4F44DE24.30606@mvista.com>
Message-ID: <4F4DC8EB.7010201@denx.de>

Hello Sergei,

Sergei Shtylyov wrote:
> On 22-02-2012 10:50, Heiko Schocher wrote:
> 
>> Add a function to initialize the davinci interrupt controller (INTC)
>> using a device tree node.
> 
>    cp_intc is not DaVinci interrupt controller, it's only used in
> OMAP-L1x SoCs. cp_intc stands for Common Platform Interrupt Controller.

Ah, Ok! Thanks for the explanation.

> I don't see where you are initializiing the DaVinci interrupt controller
> itself. You should understand that there are two disctinct types of
> interrupt controllers used in the SoCs supported by arch/arm/mach-davinci/.

board code:

MACHINE_START(ENBW_CMC, "EnBW CMC")
[...]
        .init_irq       = davinci_init_irq,

and in arch/arm/mach-davinci/cp_intc.c

for the of case:

void __init davinci_init_irq(void)
{
        of_irq_init(irq_match);
}

in drivers/of/irq.c:

/**
 * of_irq_init - Scan and init matching interrupt controllers in DT
 * @matches: 0 terminated array of nodes to match and init function to call
 *
 * This function scans the device tree for matching interrupt controller nodes,
 * and calls their initialization functions in order with parents first.
 */
void __init of_irq_init(const struct of_device_id *matches)

Ok, the name of davinci_init_irq() is missleading ...

Should I name it "cp_intc_of_init" ?

>> Signed-off-by: Heiko Schocher<hs at denx.de>
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree-discuss at lists.ozlabs.org
>> Cc: Grant Likely<grant.likely at secretlab.ca>
>> Cc: Sekhar Nori<nsekhar at ti.com>
>> Cc: Wolfgang Denk<wd at denx.de>
> 
> [...]
> 
>> diff --git a/Documentation/devicetree/bindings/arm/davinci/intc.txt
>> b/Documentation/devicetree/bindings/arm/davinci/intc.txt
>> new file mode 100644
>> index 0000000..dac2f69
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/davinci/intc.txt
>> @@ -0,0 +1,26 @@
>> +* TI Davinci Interrupt Controller
>> +
>> +davinci are using a TI interrupt controller that can support several
>> +configurable number of interrupts.
>> +
>> +Main node required properties:
>> +
>> +- compatible : should be:
>> +    "ti,davinci-intc"
> 
>    The right "compatible" prop would be "ti,cp_intc" in this case.

Ok, change this.

Thanks for the review!

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

From prakash.pm at ti.com  Wed Feb 29 01:01:52 2012
From: prakash.pm at ti.com (Manjunathappa, Prakash)
Date: Wed, 29 Feb 2012 07:01:52 +0000
Subject: [PATCH v5 2/3] arm:davinci: move emif driver to mfd framework
In-Reply-To: <A73F36158E33644199EB82C5EC81C7BC3176D103@DBDE01.ent.ti.com>
References: <y> <1330005504-25321-3-git-send-email-prakash.pm@ti.com>
	<20120227142638.GN27687@sortiz-mobl>
	<A73F36158E33644199EB82C5EC81C7BC3176D103@DBDE01.ent.ti.com>
Message-ID: <A73F36158E33644199EB82C5EC81C7BC3176D90F@DBDE01.ent.ti.com>

Hi Samuel,

On Tue, Feb 28, 2012 at 11:14:39, Manjunathappa, Prakash wrote:
> Hi Samuel,
> 
> On Mon, Feb 27, 2012 at 19:56:38, Samuel Ortiz wrote:
> [snip]
> > So it seems you're passing a platform devices array through your mfd aemif
> > platform data pointer. And from what I can see, it's mostly a 1 entry array
> > (for the NAND case) or a 2 entries array (for the NAND and NOR case).
> > In that case, adding an MFD driver in the middle brings basically nothing but
> > confusion and overhead (and 200+ lines of code).
> > So unless someone explains to me how this is doing any good to the kernel in
> > general, I'm not going to take this patchset.
> > 
> > Cheers,
> > Samuel.
> >
> 
> In this way we trying to isolate future modification of aemif driver not to depict
> as platform code change, the need for this is based on discussion in below thread
> http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-tt7059739.html#none
> 
> Earlier also concern was expressed to move aemif driver out of arch/arm to drivers folder.
> Here is the link for the same: http://lists.infradead.org/pipermail/linux-mtd/2011-August/037308.html
> Since aemif driver supports NAND/NOR devices, we feel MFD is the place holder.
> 
> Thanks,
> Prakash

Some more information which I missed out earlier:
DaVinci AEMIF is an async memory interface, driver for which was implemented in
arch/arm/mach-davinci/aemif.c. It can be interfaced to NAND, NOR and other
asynchronous memories. Currently it just provides an API for timing value
configuration. The API is invoked by the MTD NAND driver. 

Specification here: http://www.ti.com/lit/ug/sprue20c/sprue20c.pdf

Reason for moving it to MFD frame work:
1) AEMIF is also present on devices belonging to arch-c6x and arch-omap2 architectures.
   So having the driver in architecture neutral place seems to be the way to go.
2) Other than NAND/NOR there are use cases where people are interfacing other devices,
   for eg: FPGAs through UIO framework. So MTD is not the place for AEMIF driver.

Taking above points into consideration Arnd Bergmann suggested to move AEMIF driver to
MFD framework. Here is the link:
http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-December/010295.html

Thanks,
Prakash

From sshtylyov at mvista.com  Wed Feb 29 04:22:27 2012
From: sshtylyov at mvista.com (Sergei Shtylyov)
Date: Wed, 29 Feb 2012 14:22:27 +0400
Subject: [PATCH v2 1/7] ARM: davinci, intc: Add OF support for TI interrupt
	controller
In-Reply-To: <4F4DC8EB.7010201@denx.de>
References: <1329893410-24413-1-git-send-email-hs@denx.de>
	<1329893410-24413-2-git-send-email-hs@denx.de>
	<4F44DE24.30606@mvista.com> <4F4DC8EB.7010201@denx.de>
Message-ID: <4F4DFC63.9060509@mvista.com>

Hello.

On 29-02-2012 10:42, Heiko Schocher wrote:

>>> Add a function to initialize the davinci interrupt controller (INTC)
>>> using a device tree node.

>>     cp_intc is not DaVinci interrupt controller, it's only used in
>> OMAP-L1x SoCs. cp_intc stands for Common Platform Interrupt Controller.

> Ah, Ok! Thanks for the explanation.

>> I don't see where you are initializiing the DaVinci interrupt controller
>> itself. You should understand that there are two disctinct types of
>> interrupt controllers used in the SoCs supported by arch/arm/mach-davinci/.

> board code:

> MACHINE_START(ENBW_CMC, "EnBW CMC")
> [...]
>          .init_irq       = davinci_init_irq,

> and in arch/arm/mach-davinci/cp_intc.c

> for the of case:

> void __init davinci_init_irq(void)
> {
>          of_irq_init(irq_match);
> }

> in drivers/of/irq.c:

> /**
>   * of_irq_init - Scan and init matching interrupt controllers in DT
>   * @matches: 0 terminated array of nodes to match and init function to call
>   *
>   * This function scans the device tree for matching interrupt controller nodes,
>   * and calls their initialization functions in order with parents first.
>   */
> void __init of_irq_init(const struct of_device_id *matches)

> Ok, the name of davinci_init_irq() is missleading ...

> Should I name it "cp_intc_of_init" ?

    Probably. At least something with "cp_intc" in the name...

> bye,
> Heiko

WBR, Sergei